좋은 영상 감사합니다~ 동시성 제어 관련해서 학부 과정에서나 들을 수 있을법한 강의내용이네요! 다만 개인적으로 언급했으면 좋았던 점이 있는데, 충돌 직렬가능성을 컴퓨터가 어떻게 판단하는지에 대한 내용(우선순위그래프, 위상정렬)과, 뷰동등의 정의도 간단히 언급해주셨으면 더 좋았을것 같습니다. 개인적으로 근래에 데이터베이스 시스템에 대해 공부를 하던 와중에 한글로 된 이렇게 양질의 강의를 보게 되어 좋았습니다. 좋은 강의 앞으로도 많이 부탁드립니다~
안녕하세요~! 늘 애청해주셔서 감사합니다 :) isolation level(격리 수준)과 동시성 문제는 아래 영상에서 다루고 있어서 이 영상을 참고해 주시면 좋을 것 같아요 ua-cam.com/video/bLLarZTrebU/v-deo.html 분산 락은 제 채널에서 아직 언급한 적이 없지만 다른 분들도 궁금해 하실 수 있어서 요거는 다음에 기회될 때 영상으로 잘 만들어서 올려볼게요 👍
어우 내용 너무 알차게 잘봤습니다. 마지막에 모든 Transaction에 Serializable 인지 검사하기 보다는t Conflict Serializable 을 보장하는 프로토콜을 적용한다고 말씀주셨는데, 혹시 프로토콜에 대한 키워드가 있을 지 궁금합니다 ㅎㅎ 더 찾아보고 싶은데 뭐라고 검색해야 할지 모르겠어요
쉬운코드 선생님. DB 데드락 관리에 대해 궁금할 점이 너무 커서 질문드립니다 ㅜ 선생님이 CRUD 강의 후 보여주시는 DB 데드락 관리에 대한 강의 내용들을 다 수강해보고, 어디서 어떻게 실제적으로 코딩하는걸까? 하는 의문을 가지고 여기저기 정말 많이 알아봤는데요 ㅜ 약 한달정도 알아본 결과 데드락 관련한 문제을 위해 하둡이나 카프카 같은 라이브러리 서비스들이 있으며, 이런 서비스를 사람들이 많이 이용하기 때문에 선생님의 데드락 관련 강의들에 나오는 지식과 해결방법이 보편적인 지식은 아니라는 결론에 도달했습니다. 질문1) 위 문제들의 해결을 위해 코딩하는 곳은 혹시 백엔드 비지니스 로직 안이 아니라, DB서버 속의 DBMS 코드 명령창 안에서 이루어지나요? 질문2) 혹시 주로 현업에서 저런 지식과 코딩작업이 쓰이는 곳은 시중은행 금융권 같은 대규모 레거시 코드에서 쓰이는게 맞나요? 질문3) 로우한 레벨에서 직접 저렇게 문제를 해결하는 방법도 있으며, 하둡같은 라이브러리를 써서 해결하는 방법도 있을까요? 혹시 영상에서처럼 로우한 레벨에서 직접 해결할 때 장점은 무엇일까요?
안녕하세요! 영상 잘보고 있습니다 감사합니다! 다른이 아니라, 저는 "equivalent" 과 "conflict equivalent" 개념을 같이 보고 있고, "serializable" 과 "conflict serializable" 개념이 같다고 생각하고 있습니다.. 잘못된 생각인지 궁금합니다!
`LOCK을 활용한 concurrency control 기법을 배워봅니다.` 강의까지 진행하다가 궁금한 부분이 생겨서요 `(1부) concurrency control 기초:18:30` 에서 Sched.2 와 Not Conflict Equivalent 하고 다시 Sched.1와 비교하는데요. 둘 중 하나만 같아도 Conflict Serializable 하다고 하는게 헷갈려서요... `LOCK을 활용한 concurrency control 기법:13:50` 에서 처럼 Serial Schedule 도 트랜잭션에 순서에 따라서 결과가 다르기 때문에 둘 중 하나만 같은면 Conflict Serializable 하다 인걸까요? 좋은 강의 감사합니다~ 계속 돌려서 보게되네요 :) (1부) concurrency control 기초:18:30 : ua-cam.com/video/DwRN24nWbEc/v-deo.html LOCK을 활용한 concurrency control 기법:13:50 : ua-cam.com/video/0PScmeO3Fig/v-deo.html
오 네 맞습니다~!! serial schedule 중에 하나와 같기만 하면 됩니다 예를 들어 두 개의 트랜잭션 t1, t2가 있다면, 이게 순차적으로 실행되는 경우는 t1이 먼저 실행되고 끝나면 t2가 실행되는 경우거나 t2가 먼저 실행되고 끝나면 t1이 실행되는 경우입니다. 두 경우 중에 어떤 경우로 실행되더라도 각각의 결과는 정상적인 결과라고 볼 수 있죠, 왜냐하면 어쨌든 둘 다 순차적으로 실행됐으니까요 문제가 생길 수 있는 경우는 t1과 t2가 겹쳐서 동시에 실행될 때 인데요, 겹쳐서 실행되는 바람에 데이터가 이상한 값으로 저장된다면 이건 문제가 되는 부분이지만, 겹쳐서 동시에 실행되더라도 그 결과가 앞에서 말한 그 두 가지 경우 중에 하나와 같다면 이것은 문제가 아니죠~ 이런 측면에서 접근해 주시면 될 것 같아요 :)
오 아닙니다~ 내용 자체가 좀 어려울 수 있어요~! 혹시 어떤 부분이 이해가 잘 안되셨는지 알려주시면 제가 좀 더 구체적으로 가이드를 드릴 수 있을 것 같아요 우선 이 영상의 핵심을 정리해서 말씀드리면 'transaction의 특징 중 하나인 isolation이 제대로 보장되려면 동시에 여러 트랜잭션들이 실행될 때도 마치 순차적으로 실행되는 것처럼 동작할 수 있어야 한다, 그걸 serializability라고 부른다' 가 되겠습니다 이 serializability 개념을 자세히 살펴본 것이 이번 영상이고요 참고로 여러 트랜잭션이 동시에 실행될 때 발생할 수 있는 이상 현상들은 아래 영상에서 설명하고 있어요~ ua-cam.com/video/bLLarZTrebU/v-deo.html
Non-serial Schedule을 Non Block sync IO라고 이해해도 괜찮을까요? 근거는 우선 r2(H) IO를 보내고 동시에 r1(K)를 요청을하였고 이후 read()가 완료되었다는 응답이 와야 w2(H)와 W1(K)를 수행할수 있기 때문이라고 생각합니다. 항상 양질의 강의와 뛰어난 강의력에 감사드립니다..!
오 항상 애청해 주셔서 감사합니다 :) 칭찬의 말씀도 감사합니다!! 👍 질문 주신 부분에 대해서는,, 개인적으로는 Non Block sync IO로 이해하시는 것보다는 그냥 Non-serial Schedule 그 자체로 이해해 주시는 것이 좋지 않을까 싶어요 ㅠ 서로 별개의 개념이라 제 생각엔 더 헷갈릴 수 있을 것 같아서요ㅠ
H 계좌에 +20을 해주려면 기본적으로 현재 H 밸런스가 얼마인지 읽지 않고 +20을 어떻게 할 수 있을까요??? 아마도 update 쿼리문을 생각하신 것 같은데 그 update 쿼리 문도 내부 구현 자체는 결국 일단 H 계좌의 현재 값을 읽어야 할 겁니다 프로그래밍 레벨에서 흔히 쓰는 a += 20 이라는 명령문 자체도 사실은 a = a + 20의 의미죠
mysql 8.0.33버전에서 3:24초의 lost update상황을 재현해보고자 했습니다. 그런데, write(H_balance = 220만원)을 하는 시점에 Transaction2의 결과가 같이 합쳐져서 업데이트가 되는 상황이 발생했습니다. isolation level은 repeatable read입니다! 이런 상황을 mysql이 대비해 놓은 것일까요? 이론적으로는 Transaction2의 결과가 Transaction1의 write(H_balance=220만원)시점에 반영되면 안되는 거 같은데! 제가 잘못생각한 부분이 있을까요??
코멘트 하나 남깁니다 ~
* Concurrency control 기초
- 1부 영상 : ua-cam.com/video/DwRN24nWbEc/v-deo.html (현재 영상)
- 2부 영상 : ua-cam.com/video/89TZbhmo8zk/v-deo.html
진짜 레전드
헤헤 👍👍👍
해외 영상중에도 이 정도 퀄리티의 간단한 설명이 없는데 .. 대박이네요
크 ㅠㅠㅠ 엄청난 칭찬 덕분에 기분이 많이 좋으네요 ㅎㅎ
진짜 혼자알기 아쉬운 채널이네요.. 좋은강의 앞으로도 계속 부탁드릴게요!
크 칭찬 감사합니다!! 앞으로도 꾸준히 좋은 영상으로 인사드릴게요 👍
오왕 1부 듣는데 너무 설레요!!!
헿 감사합니다~! 내일 밤에 2부 올라갑니다용~~
오늘도 감사합니다. 설명이 정말 깔끔하신게, 배우는 입장에서 감사하면서도 부럽네요.
이거 완전 멀티프로세스/쓰레드 동기화 개념이네요 감사합니다 정말 잘 보고 있어요
맞아요 맞아요 ㅎㅎ 거의 쌍둥이급이죠 ㅋㅋ 항상 유익하게 봐주셔서 감사합니다 :) 👍
이 어려운 부분을 이렇게 명쾌하게 풀어내시는게...엄청난 내공을 가지신듯 합니다!! 세번째로 엄청납니다
와우 트리플엄청을 달성했군요!! 👍
단계적으로 설명해주셔서 어려운 개념임에도 불구하고 이해를 할 수 있었던 것 같습니다. 감사합니다!!
다음 영상이 너무 기대되요 감사합니다!
감사합니다 :)
늦지 않게 다음 영상으로 찾아올게요 👍
너무 이해가 잘 됩니다!! 이 멍청한 저를 이해시키다니 대단하네요
이 어려운 개념을 이렇게 쉽게 설명해주시다니 감사합니다
좋게 봐주셔서 정말 감사합니다 :)
와..이게 이런의미였군요 어려운데 설명을 너무 잘해주셔서 재밌어요!! 처음 공부하는 내용이어서 두세번은 봐야겠어요 넘 감사합니다!!
크~! 맞습니다 사실 이번 내용은 어려운 내용이라 최대한 쉽게 이해하실 수 있도록 잘 만들려고 노력을 많이 했었어요
재밌게 봐주셔서 감사합니다 :)
크 기가 막히네요 진짜 설명도 너무 좋았습니다
이번 영상은 2회 정주행하였습니다..
좋은 영상 감사합니다.
오~~! 이해되실 때 까지 보신 거군요 최고십니다 !! 👍
감사합니다
저도 댓글 감사합니다 👍
구독하고 갑니다 감사합니다.
오늘도 잘 듣고 갑니다 :) 감사합니다!!!🙃
헤헤 늘 애청해 주셔서 감사합니다~! 😭
좋은 영상 감사합니다~ 동시성 제어 관련해서 학부 과정에서나 들을 수 있을법한 강의내용이네요! 다만 개인적으로 언급했으면 좋았던 점이 있는데, 충돌 직렬가능성을 컴퓨터가 어떻게 판단하는지에 대한 내용(우선순위그래프, 위상정렬)과, 뷰동등의 정의도 간단히 언급해주셨으면 더 좋았을것 같습니다. 개인적으로 근래에 데이터베이스 시스템에 대해 공부를 하던 와중에 한글로 된 이렇게 양질의 강의를 보게 되어 좋았습니다. 좋은 강의 앞으로도 많이 부탁드립니다~
안녕하세요
영상을 너무 너무 좋게 봐주셔서 감사합니다 :)
다른 유익한 영상들도 많으니까요 자주 놀러와 주세요~!
옛날에 7급 공무원 준비할때 이 부분 진짜 어려웠었는데 이렇게 쉽게 설명해주셔서 감사합니다 이제야 제대로 이해가되네요
헿 도움을 드릴 수 있어서 저도 기분이 뿌듯하고 좋습니다 :)
댓글 남겨주셔서 감사해요~! 😊
진짜 멋지네요 잘배우고가요
와. 이런 좋은 강좌를.왜 이제.알게되었을까...복귀하셨음 좋겠네요. 영상잘보고갑니다.
항상 잘 보고 있습니다! 궁금한 것이 있는데요. 데이터베이스의 격리수준으로 해결이 안되는 동시성 문제가 있나요? 또 분산 락은 언제 사용하는건가요 ? 좋은 강의 감사합니다!
안녕하세요~! 늘 애청해주셔서 감사합니다 :)
isolation level(격리 수준)과 동시성 문제는 아래 영상에서 다루고 있어서 이 영상을 참고해 주시면 좋을 것 같아요 ua-cam.com/video/bLLarZTrebU/v-deo.html
분산 락은 제 채널에서 아직 언급한 적이 없지만 다른 분들도 궁금해 하실 수 있어서
요거는 다음에 기회될 때 영상으로 잘 만들어서 올려볼게요 👍
최고👍
감사합니다...!!!
어우 내용 너무 알차게 잘봤습니다. 마지막에 모든 Transaction에 Serializable 인지 검사하기 보다는t Conflict Serializable 을 보장하는 프로토콜을 적용한다고 말씀주셨는데, 혹시 프로토콜에 대한 키워드가 있을 지 궁금합니다 ㅎㅎ 더 찾아보고 싶은데 뭐라고 검색해야 할지 모르겠어요
쉬운코드 선생님. DB 데드락 관리에 대해 궁금할 점이 너무 커서 질문드립니다 ㅜ
선생님이 CRUD 강의 후 보여주시는 DB 데드락 관리에 대한 강의 내용들을 다 수강해보고, 어디서 어떻게 실제적으로 코딩하는걸까? 하는 의문을 가지고 여기저기 정말 많이 알아봤는데요 ㅜ
약 한달정도 알아본 결과 데드락 관련한 문제을 위해 하둡이나 카프카 같은 라이브러리 서비스들이 있으며, 이런 서비스를 사람들이 많이 이용하기 때문에 선생님의 데드락 관련 강의들에 나오는 지식과 해결방법이 보편적인 지식은 아니라는 결론에 도달했습니다.
질문1) 위 문제들의 해결을 위해 코딩하는 곳은 혹시 백엔드 비지니스 로직 안이 아니라, DB서버 속의 DBMS 코드 명령창 안에서 이루어지나요?
질문2) 혹시 주로 현업에서 저런 지식과 코딩작업이 쓰이는 곳은 시중은행 금융권 같은 대규모 레거시 코드에서 쓰이는게 맞나요?
질문3) 로우한 레벨에서 직접 저렇게 문제를 해결하는 방법도 있으며, 하둡같은 라이브러리를 써서 해결하는 방법도 있을까요? 혹시 영상에서처럼 로우한 레벨에서 직접 해결할 때 장점은 무엇일까요?
와 굳굳😍😍😍😍😍
헤헤 감사합니다~!!! :) 👍👍👍👍👍
안녕하세요! 영상 잘보고 있습니다 감사합니다!
다른이 아니라, 저는 "equivalent" 과 "conflict equivalent" 개념을 같이 보고 있고,
"serializable" 과 "conflict serializable" 개념이 같다고 생각하고 있습니다.. 잘못된 생각인지 궁금합니다!
`LOCK을 활용한 concurrency control 기법을 배워봅니다.` 강의까지 진행하다가 궁금한 부분이 생겨서요
`(1부) concurrency control 기초:18:30` 에서 Sched.2 와 Not Conflict Equivalent 하고 다시 Sched.1와 비교하는데요. 둘 중 하나만 같아도 Conflict Serializable 하다고 하는게 헷갈려서요...
`LOCK을 활용한 concurrency control 기법:13:50` 에서 처럼 Serial Schedule 도 트랜잭션에 순서에 따라서 결과가 다르기 때문에 둘 중 하나만 같은면 Conflict Serializable 하다 인걸까요?
좋은 강의 감사합니다~ 계속 돌려서 보게되네요 :)
(1부) concurrency control 기초:18:30 : ua-cam.com/video/DwRN24nWbEc/v-deo.html
LOCK을 활용한 concurrency control 기법:13:50 : ua-cam.com/video/0PScmeO3Fig/v-deo.html
오 네 맞습니다~!! serial schedule 중에 하나와 같기만 하면 됩니다
예를 들어 두 개의 트랜잭션 t1, t2가 있다면, 이게 순차적으로 실행되는 경우는 t1이 먼저 실행되고 끝나면 t2가 실행되는 경우거나 t2가 먼저 실행되고 끝나면 t1이 실행되는 경우입니다.
두 경우 중에 어떤 경우로 실행되더라도 각각의 결과는 정상적인 결과라고 볼 수 있죠, 왜냐하면 어쨌든 둘 다 순차적으로 실행됐으니까요
문제가 생길 수 있는 경우는 t1과 t2가 겹쳐서 동시에 실행될 때 인데요, 겹쳐서 실행되는 바람에 데이터가 이상한 값으로 저장된다면 이건 문제가 되는 부분이지만, 겹쳐서 동시에 실행되더라도 그 결과가 앞에서 말한 그 두 가지 경우 중에 하나와 같다면 이것은 문제가 아니죠~ 이런 측면에서 접근해 주시면 될 것 같아요 :)
@@ez. 감사합니다. 👍
@@dhs948 저야말로 멤버십 가입으로 힘을 보태주셔서 정말 정말 감사합니다 (_ _)👍👍👍
오.. 어렵네요 ㅜㅠ 제가 이해하지 못하는 이유는 너무나도 많겠지만.. 혹시 어떤 개념을 공부하고 다시 보면 이해하는데 좀 도움이 될까요??
오 아닙니다~ 내용 자체가 좀 어려울 수 있어요~!
혹시 어떤 부분이 이해가 잘 안되셨는지 알려주시면 제가 좀 더 구체적으로 가이드를 드릴 수 있을 것 같아요
우선 이 영상의 핵심을 정리해서 말씀드리면
'transaction의 특징 중 하나인 isolation이 제대로 보장되려면
동시에 여러 트랜잭션들이 실행될 때도 마치 순차적으로 실행되는 것처럼 동작할 수 있어야 한다,
그걸 serializability라고 부른다'
가 되겠습니다
이 serializability 개념을 자세히 살펴본 것이 이번 영상이고요
참고로 여러 트랜잭션이 동시에 실행될 때 발생할 수 있는 이상 현상들은 아래 영상에서 설명하고 있어요~
ua-cam.com/video/bLLarZTrebU/v-deo.html
Non-serial Schedule을 Non Block sync IO라고 이해해도 괜찮을까요?
근거는 우선 r2(H) IO를 보내고 동시에 r1(K)를 요청을하였고 이후 read()가 완료되었다는 응답이 와야 w2(H)와 W1(K)를 수행할수 있기 때문이라고 생각합니다.
항상 양질의 강의와 뛰어난 강의력에 감사드립니다..!
오 항상 애청해 주셔서 감사합니다 :)
칭찬의 말씀도 감사합니다!! 👍
질문 주신 부분에 대해서는,, 개인적으로는 Non Block sync IO로 이해하시는 것보다는 그냥 Non-serial Schedule 그 자체로 이해해 주시는 것이 좋지 않을까 싶어요 ㅠ
서로 별개의 개념이라 제 생각엔 더 헷갈릴 수 있을 것 같아서요ㅠ
15:25 이후에 나오는 스케줄에서 충돌이 왜 발생하는 건가요? 스케줄 3에서 t2가 h에 대해서 read, write 작업 후 commit 하고나서 t1이 h에 대해서 read, write 작업을 했는데 이게 충돌이 발생하나요?
시리얼 스케줄이 io할 때도 코어가 다른 트랜잭션을 처리하러 가지않고 기다린다해도 다른 코어가 다른 트랜잭션을 처리하면서 순서가 이상해지고 이상한 결과가 나올 수 있는 거 아닌가요? 코어가 한 개인 CPU에만 해당하는 이론일까요?
안녕하세요!
항상 좋은 강의 감사히 보고 있습니다.
제가 공부 목적으로 노션에 강의 내용을 정리하려고 하는 데 괜찮을까요?
정리하는 개념과 관련된 영상의 링크를 같이 작성하긴 할 건데, 안 된다면 따로 정리하겠습니다!
오 네네 물론이에요~ 정리하셔도 됩니다 :)
링크만 잘 달아주시면 채널 홍보도 되고 너무너무 좋죠👍
@@ez. 감사합니다!
저야말로 항상 애청해 주셔서 감사합니다 :)
안녕하세요. 알려주신 내용과 설명하실 때 사용한 그림을 이용해서 블로그에 정리하고 싶은데 자료 출처를 정확히 적고 블로그에 정리해도 괜찮을까요?
넵~ 사용하셔도 괜찮습니다 :)
출처만 잘 써주시면 저도 채널 홍보가 되고 좋아요 👍
너무 감사합니다. 너무 너무 잘 보고있습니다.
출처는 정확하게 큼지막하게 남기겠습니다. 😭
헤헤 항상 애청해 주셔서 감사합니당 😊
쉬운코드를 국회로!!!!!
K계좌에서 H계좌로 20만원을 이체하는 상황에서, K계좌를 조회하고 -20만원을 업데이트하는건 자연스러운 흐름같은데 H계좌에 20만원을 업데이트해주기 위해 H계좌를 조회할 필요가 있을까요??? 문제 상황을 만들기 위해 예시를 R -> W로 구성하신건가요???
H 계좌에 +20을 해주려면 기본적으로 현재 H 밸런스가 얼마인지 읽지 않고 +20을 어떻게 할 수 있을까요???
아마도 update 쿼리문을 생각하신 것 같은데 그 update 쿼리 문도 내부 구현 자체는 결국 일단 H 계좌의 현재 값을 읽어야 할 겁니다
프로그래밍 레벨에서 흔히 쓰는 a += 20 이라는 명령문 자체도 사실은 a = a + 20의 의미죠
mysql 8.0.33버전에서 3:24초의 lost update상황을 재현해보고자 했습니다. 그런데, write(H_balance = 220만원)을 하는 시점에 Transaction2의 결과가 같이 합쳐져서 업데이트가 되는 상황이 발생했습니다. isolation level은 repeatable read입니다! 이런 상황을 mysql이 대비해 놓은 것일까요? 이론적으로는 Transaction2의 결과가 Transaction1의 write(H_balance=220만원)시점에 반영되면 안되는 거 같은데! 제가 잘못생각한 부분이 있을까요??
앗 저는 예상대로 실행이 됩니다~ 8.0.31에서 테스트했고요, repeatable read isolaion level입니다
테스트를 어떻게 하신 걸까요? 저는 command line으로 콘솔 두개 띄우고 했습니다
진짜 이거 개념 만든인간은 빡대가리가 분명함.
많이먹는데 살이 안찌고싶다면 많이 먹는데 살 안찌는 사람이 먹는 음식과 같은결로 먹어라
정도의 존나 간단한 개념인데 베베꼬아서 컨플릭트니 시리얼이제이블이니 개소리 ㅈㄴ함