데베

어디까지 진도 나갔는지 봐서 실형법이 결정할거에요. 트랜잭션에 대해서 공부하셨는데, 트랜잭션은 여러개의 명령어로 이루어져 있지만, 논리적으로는 단 하나의 명령어처럼 간주되어야 하는 명령어 집합을 뜻하는데요. 그래서 이게 트랜잭션이에요. 지금 명령어가 다섯개로 이루어져 있는데, 다섯개가 모두 실행되거나, 아니면 모두 실행되지 않거나, 그 중 하나만 되어야 합니다. 그래서 잔고에서 25달러를 결제하는 트랜잭션이 되는데요. 잔고에 얼마인지 믿고, 25달러보다 많이 있으면은 25달러를 지불하고, 25달러를 차감해서 계좌를 쓰는 그런 장소입니다.

작업들이 기재가 되어 있는데요. 이렇게 진행을 하다가 갑자기 3개의 오퍼레이션만 진행이 되고 컴퓨터가 망가졌다. 라고 하게 되면은 지불은 됐는데 25달러가 차감되지 않는 그런 문제가 발생할 수 있죠. 그래서 이 중에서 이 5개 중에서 2분만 실행되면 되는 것이 아니라 모두 다 실행되거나 아니면 모두 다 실행되지 않거나 그 둘 중에 하나만 허용이 되어야 합니다. 간단하게 이러한 트랜젝션을 구현하는 방법은 일단

트랜젝션이 도착하는 순서대로 하나씩만 실행되도록 하는 방법이 있어요. 하나씩만 실행되도록 하고, 그리고 트랜젝션이 시작할 때 전체 데이터베이스를 새로운 파일에 복사해서 복사해서 그 변경점들을 그 복사한 파일에 기록하는 방법이 있습니다. 원본 데이터베이스는 그대로 있고, 원본은 그대로 있고, 복사한 곳에 여기다 뭔가 변경점을 다 저장한 다음에 '시장 개선이 완벽하게 끝났다'라고 하면

이것을 우리의 새 데이터베이스로 사용하면 되겠죠. 그런데 만약에 트랜지션이 실패했다고 하면 이걸 버리고 원래 원본 디디를 사용하던 대로 사용하면 돼요. 이렇게 간단하게 구현을 할 수가 있습니다. 그렇게 해버리게 되면 트랜지션이 하나씩만 실행되어 있고 우리 CPU에 코어가 많이 있는데 그 많은 CPU 코어도 활용하지 못하고 변화를 할 수가 없어요. 그래서 느려지기 때문에 우리는 트랜지션을 한 번에 여러 개 수행할 거다. 앱올드 되어 있고요

반반에 여러 개 수행하다 보면 문제가 생길 수 있는 것이 일시적인 일관성이 깨지는 것과 영구적으로 일관성이 깨지는 게 있는데 일시적으로 깨지는 건 괜찮아요. 일시적으로 값이 이상한 값이 들어가 있다. 언젠가 고쳐진다면 괜찮은데 영구적으로 값이 고장난 채로 들어가 있다. 라고 하면 좋지 않은 상황이 되겠죠. 이러한 것을 피해야 돼요. 그래서 우리가 데이터베이스가 올바른 상태에 있는지 아닌지 알려주는 기준이 베시드랑 웨싱!

원자성, 모든 것이 일어나거나 아니면 하나도 일어나지 않거나 둘 중에 하나가 만족이 되어야 하고요. 그 다음에 일관성, 트랜잭션이 일관성이 있고 그 다음에 DB가 일관성이 있는 상태로 시작했다고 하면은 그 트랜잭션들을 마무리 실행해도 무조건 일관성이 있는 상태로 데이터베이스가 나와 있어야 된다는 뜻이고요. 그 다음에 고립성은 각 트랜잭션들은 홀로 실행되는 것 같은 결착각 속에 실행이 되면 좋습니다.

프로그래머가 작업하기 편하게 나 홀로 실행되고 있다는 것을 착각을 지워야 되고요. 그 다음에 듀어벨려 팀은 트랜유션이 커밋이 되면 그것의 효과가 지속되어야 된다. 커밋 된다고 하면 그것의 효과가 컴퓨터가 꺼지든 어떻게 되든 계속해서 남아있어야 된다는 뜻입니다. 그래서 에터홀시티 같은 경우는 트랜유션의 실행 결과는 두 가지가 있는데 커밋된 것이 있고

커밋은 말 그대로 DB에 접수가 돼서 완벽하게 접수된 가정이 끝이 났다. 트랜젝션이 모든 행동들을 말로 했다 라는 뜻이고요. 오버터도 중단되어서 모든 것이 다 취소됐다 라는 뜻인데요. 트랜젝션이 애토밋하다 라는 것은 그 모든 액션들을 다 실행했거나 아니면 아무것도 실행하지 않거나 그 둘 중에 하나만 되어야 애토밋하다 라고 할 수 있다는 뜻입니다.

그 애터러시티를 위해서 설계할 수 있는 첫 번째 방법이 로깅이 있는데요. 바로 다음 강의 슬라이드가 로깅에 관련되는 거예요. 기록을 남기는 로깅을 하는 방법이 있고요. 아까 말씀드린대로 'Shadow Paging'이라고 해서 우리가 데이터베이스에 카피를 만든 다음에 그 카피에 모드 변경 사항들을 저장하고 그것이 잘못됐으면 폐기하고 이렇게 끝났으면 그것을 우리의 메인 디디어로 사용되는 방법이 있는데요. 그리고 다음 강의 슬라이드에 나옵니다. 로깅이랑 쉐도우 페이지는 다음 강의 슬라이드에 자세히 나오고요.

성능 문제 때문에 '셰도우 페이지를 가급적 쓰지 말라' 라고 되어 있습니다. 복사하고 막 그런 과정이 오버헤드가 커서 우리가 많은 페이지를 건드려서 작업을 하게 되면 그 카피보드를 다 만들어야 되잖아요. 그래서 성능에는 큰 저하가 올 수가 있습니다. 그래서 대국은 쓰지 않고요. 그래서 위관성을 유지하기 위해서는 여러 가지 제약 조건들을 넣어서 우리가 위관성을 유지할 수 있다. 그런데 우리가 서버가 여러 개 있을 경우에

은행 서버인데 어떤 사람이 돈 100달러를 입금했다고 해봐요. 여기는 반영이 됐는데 순간적으로는 다른 곳에 반영이 안 됐을 수도 있거든요. 그래서 나는 원래 900달러 있던 곳이 1000달러가 됐는데 다른 곳은 계속 900달러로 남아있을 수 있어요. 그래서 어떤 사람이 100달러 입금하고 이 서버에서 조회를 했더니 아직도 900달러인 거예요. 그러면 문제가 생긴 거죠. 그런데 이 벤처 컨실리턴스는 시간이 충분히 흐르면 모두 다 똑같은

1000달러로 입력이 될 거다 라는 것을 보장해 주는데 이렇게 되어버리게 되면 개발자들이 작업을 하기 힘들어집니다. 모두 다 입고 하는 순간 모든 서버에서 1000달러로 인식이 되어야지 어디서는 900달러로는 1000달러로 이러면 사용자들로도 항의도 있고 개발자도 작업을 하기 힘들어져요. 그래서 이러한 트렌드가 사라지는 추세다 라고 되어 있어요. 그래서 이것에 반대되는 개념은 수트러운 컨시스턴스인데

스튜디오 파실 타는 시간 내 모든 서버의 내용이 커밋이 되면 모든 서버의 내용이 동시 즉각적으로 다 동일했습니다 그래서 이쪽으로 감축해서 이것은 지금 어서지는 추세다 라고 이제 보시면 되구요 음 그 다음에 고립성 같은 경우는 각 트랜젝션에 마치 혼자 시행되고 있는 것 같은 착각을 부여하는 것인데요 그럼 프로그램을 하기 쉬워집니다.

그런데 실제로는 DBMS는 여러 트랜젝션들을 지속버서 실행하게 되는데 그래도 우리는 한 번에 하나씩만 실행되는 것 같은 그러한 환경을 조성해 줘야 된다. 어떻게 해야 되느냐 하면 우리가 동시성 제어를 해야 된다는 뜻인데요.

트랜젝션이 두 개가 있어요. 하나는 이체하는 거고, 하나는 이자를 주는 거에요. 하나는 A에서 B로 100달러를 이체하는 거고, 하나는 A랑 B의 계좌에서 각각 6%씩 이자를 지급하는 곳인데요. T1, T2가 동시에 들어왔다고 해주면 T1 먼저 실행되고 T2 나중에 실행되고 이렇게 되는 것이 있고, T1 나중에 실행되고 T2 먼저 실행되고 이 방법이 있는데, 결과가 다릅니다. 결과는 다르지만, 우리가 T1도

T1이 12시에 실행되라고 예약이 걸려있었고 T2도 12시에 실행되라고 예약이 걸려있었다고 해주면 똑같은 일시에 시작이 되도록 되어있기 때문에 어느 거 하나는 먼저 실행을 해야 되잖아요. 그렇기 때문에 T1 먼저 실행해도 괜찮고 T2 먼저 실행해도 괜찮아요. 그런데 어떤 것을 먼저 실행하는가에 따라서 결과가 달라지는데 어쨌든 둘 다 신처적으로 실행이 됐다고 하면 T1 완전히 실행되고 T2 완전히 실행되고 아니면 T2 완전히 실행되고 T2 완전히 실행되고 이렇게 보면 모두 다 옳은 것으로 감추합니다.

둘 다 옳다 라고 이제 감주를 한다는 뜻이고요. 어쨌든 이 두 계좌의 합계는 2120달러가 되어야 된다.

근데 이렇게 순서를 섞을 수도 있어요. 시원에 A에서 100달러 빼주고 T2에서 A 계좌에 이자 주고 B에서 100달러 더해주고 B에서 이자 지급하고 이렇게 했을 때 954126이 나왔는데 이것은 이것과 결과가 똑같거든요. 그래서 이것도 오른 것으로 간수를 이거 잘못된 것이라고 했었네요.

-

T1 먼저 실행되고 T2 나중에 실행되면 954-1160인데 여기 잘못 기재됐어요 954-1160 어쨌든 결과까지 똑같이 나와서 괜찮은 순서로 섞는 방법이 되겠고요 괜찮은 스케줄이에요 이것은 이렇게 섞었다 라고 하게 되면 954-1160이 나왔는데 합치면 2114달러라서 어느 계좌에서도

아, 어느 그 시리얼 스케줄에서도 954-1166은 안 나오거든요. 아, 954-1160. 954-1160은 여기서 안 나와, 여기서 안 나오죠. 그래서 이렇게 섞어버리면 잘못된 결과가 나오는 거예요. 이거 보시면은, A랑 B의 계좌 보시면은 전체 2000달러가 있어야 되는데, 2000달러에 대해서 6달러가 지급이 되어야 되는데, A에서 빼신 채로 양 계좌에 이자가 지급되고, 나중에 B에 100달러가 들어갔기 때문에 문제가 생긴 거예요.

그래서 이것은 옳지 않은 스케줄이다. 이렇게 스케줄을 잡으면 안된다는 뜻입니다. 그래서 시리얼 스케줄은 정의가 우리가 트윈터스를 하나씩 실행한 것을 실행 스케줄이라고 해요. 그래서 이것도 하나의 시리얼 스케줄이고 이것도 하나의 시리얼 스케줄이에요. 하나씩만 실행된 것입니다. 그 다음에 시리얼 라이저블 스케줄. 우리말로 한다면은

직렬 가능 일정이라고 할까요? 직렬 가능 스케줄이라고 보면 스케줄을 짰는데 아까 시리얼 스케줄이랑 똑같은 결과가 나왔다 라고 하면 시리얼 라이저블 스케줄이라고 합니다 예를 들어서 이거 같은 경우는 이러한 시리얼 스케줄이랑 그 결과가 똑같기 때문에 얘는 시리얼 라이저블 스케줄이에요 직렬 가능한 스케줄 얘는 직렬 스케줄이고요 관청기가 좀 어려워요

그 다음에 complete라는 개념이 나오는데 서로 다른 트랜젝션에서 똑같은 오브젝트에 대해서 한쪽이 적어도 쓰고 있다 라고 하면 complete가 생길 수 있습니다. read read 같은 경우는 complete가 안 생긴다고 했었죠. 똑같은 값을 얘도 읽고 얘도 읽었어요. 그러면 똑같은 값을 읽었겠죠. 아무 문제 없어요. 그런데 한쪽에 써버렸다 라고 하면 read write나 write나 write write 해버리면 문제가 생기는데

리드라이트 같은 경우는 10달러를 읽었는데 여기서 19달러로 덮었었어요. 똑같은 것을 읽었는데 19달러가 나오는 거예요. 티아닌장에서 봤을 때는 나 혼자 실행되고 있다고 하면 한번 읽은 거 또 읽었을 때 10달러가 나와야 되는데 바뀌어 있잖아요. 내가 혼자 실행되지 않는구나. 그래서 고립성이 깨진 거죠. 그래서 문제가 생긴 것이고요. 그 다음에 라이트 리드 같은 경우에는 여기서 10달러 읽어서 12달러로 쓰고 얘는 12달러로 읽어서 10달러 썼는데 여기에서 10달러 읽어서 10달러 썼는데

롤맵을 해버렸어요. 그러면 롤맵을 10달러가 되잖아요. 그래서 A가 10달러 있음에도 불구하고 얘는 이제 12달러로 기술을 삼아서 뭔가 작업을 했기 때문에 문제가 생기는 예제가 됐습니다. 그리고 이제 라이트 라이트 컴플릭터는 이제 A, B 쓰고 얘도 A, B 쓰고 있는데 T1이 먼저 시행되고 T2가 나중에 시행됐다 라고 하면 19달러에 박 아니면 거꾸로 T2가 언제 시행되고 T1가 나중에 시행되다 가면 10달러에 A, B 쓰고 이렇게 값이 적혀있어야 되는데 지속해서 적혀있게 되면 19달러에 A, B 쓰고 있기 때문에 시리얼 스케줄과 유치하지 않습니다. 그래서 이것도 문제가 생긴 거예요.

그래서 여기까지 했었는데, 우리가 complete equivalent하다, complete 관점을 써야 동등하다 라고 하는 것은 두 개의 스케줄이 똑같은 트랜젝션에 같은 행동을 포함하고 있고 모든 complete가 발생하는 액션들이 같은 순서로 되어 있다. 그러면 우리가 complete equivalent 하다 라고 하는데요. 감사합니다.

그러니까 컴플릭트 관점에서 봤을 때 지금 이렇게

여기서 리드한 것을 라이트에서 컴퓨터가 발생했거든요. 이런 스케줄이 있고, 다른 스케줄도 있는데 간단해서 여기서는 다른 스케줄을 만들어낼 수가 없는데 약간 복잡한 스케줄이었다고 해봐요. 약간 복잡한 스케줄이었는데 이것이 포함되어 있었는데 여기서도 똑같이 컴퓨터가 들어있다 라고 하게 되면 스케줄은 컴퓨터가장에서 봤을 때 동등하다 라는 뜻이에요.

그래서 우리가 '컴플레이트 관점에서 징계가 가능하다'라는 뜻은 S가 시리얼 스케줄이 있었죠. 완벽하게 혼자서 실행되는 것들 신체적으로 혼자 실행되는 것들과 위에서 보셨던 '컴플레이트 유퀘베렌드'라는 것과 동등하다고 하면 '컴플레이트 관점에서 징계가 가능하다'라고 합니다. 이건 약간 개념이 어려운데 예제를 통해서 보시면 될 것 같아요. 이제가 이제 Dependency Graph로 이제 나오는데 이것부터 새로 진정하는 거죠.

보시면은 의전성 그래프에서 나와 있는데 트랜젝션이 있으면은 하나의 노드 그래프에는 노드랑 엣지가 있잖아요 노드는 쉽게 말해서 노드는 점이고 엣지는 선입니다 트랜젝션이 있으면은 하나하나를 다 점으로 표현하는거에요 점으로 표현하고 그 다음에 선이 어떨 때 그어지냐면은 트랜젝션 TI에 있는 어떤 오퍼레이션은 트랜젝션 TJ에 있는 오퍼레이션과 충돌이 일어난다

그리고 i에 있는 오퍼레이션이 먼저 발생했다 라고 하면 i에서 j로 선이 그어집니다. 무슨 말인가 하면 선이 그어졌잖아요. 선이 그어졌으면 ti번제 트랜젝션에 있는 어떤 오퍼레이션이 tj에 있는 오퍼레이션과 충돌이 발생했구나 라는 것을 알 수가 있어요. 이게 먼저 실행됐구나. 그거를 뜻합니다. 그래서 프레스 단스 글레토 브라우드 하고

이 그래프가 사이클이 없을 경우, 사이클이 없을 경우, 오르면 컴퓨터 관점을 진행 가능하다고 합니다. 이렇게 되어 있으면, 사이클이 없죠. 순환이 없기 때문에 이것은 직렬 가능해요. 그래서 Ti를 먼저 실행하고, 나중에 TJ를 실행하고, 동일한 효과가 나오는데, 예제를 통해서 보시면, 좀 더 감이 오실 겁니다. 이렇게 보시면, 애플레이션 T1과 T2가 있어요. 그러면 점을 만들어줘야 돼요. T1이라는 점을 만들어주고,

티틀 안에 저를 만들어줘야 되요 그 다음에 분석을 해야 합니다 컴퓨터가 뭐가 있을 때 분석을 해야 되는데 똑같은 에이에 대해서 똑같은 에이에 대해서 한번은 라인트를 하고 있고 한번은 리드를 하고 있죠 그래서 라이트 인도 이제 컴퓨터가 발생했어요 그리고 t1에서 먼저 시작이 됐죠 그래서 t1에서 t2로 이렇게 엣지가 보여집니다 에이에 대해서 그 다음에 또 컴퓨터가 있나 보시면은 여기서도 b 에 대해서 라이트 하고 있고 리드를 하고 있죠 그래서 컴퓨터가 발생했어요 그래서 이제 번에는 t2가 먼저 실행됐기 때문에 이렇게 그려져요

그래서 보시면 사이클이 생겼습니다. T1에서 T1 사이클이 생겼기 때문에 이것은 중렬 가능하지 않아요. 어떻게 실행을 해도 T1 먼저 실행하고 T2 나중에 실행하고 그리고 T2 먼저 실행하고 T1 먼저 실행하고 그거랑 일치하지 않습니다. 이거랑 정확하게 똑같은 것이 앞에 나온 앞에 나온 이것과 정확하게 똑같아요. 여기서 A를 한번 읽어서 썼죠. A를 읽어서 쓰고 B를 읽어서 쓰고 B를 읽어서 쓰고

이렇게 있는데, A 이것을 쓰고 B 이것을 쓰고 B 이것을 쓰고. 그래서 아까 이 스케줄은 옳지 않다고 했었구요. 그래서 어떻게 해도 이것은 직렬 스케줄이랑 값이 다르게 나옵니다. 두 번째 예제인데요. T1, T2, T3를 쓰니까 점을 T1, T2, T3를 만들어줘요. 그 다음에 컴퓨터 견해 봐야 되는데, 똑같은 것에 대해서 작업을 할 때 컴퓨터가 생기는데, 지금 보시면 A에 대해서

1명은 읽고, 1명은 쓰고 있죠. 그래서 문제가 발생했어요. 그래서 T1에서 T3로 엣지가 생겼고요. 그 다음에 B에 대해서도 문제가 생기겠죠. 어차피 T1에서 T3 가는 것, 라이트 리드도. 이것도 컴퓨터인데 이미 한 번 들어줬기 때문에 그럴 필요는 없습니다. 라이트 라이트도 컴퓨터 발생했고요. B에 대해서 라이트 리드가 발생했고, T2에서 T1으로 가야되요.

라이트라이트도 가세요.

또 하나 보시면 ReadWrite로 발생하겠죠. 그래서 어쨌든 중요하지는 않는데 이것이 보시면 사이클이 없는 채로 끝났어요. 더 이상 그릴 수가 없거든요. 사이클이 없는 채로 끝났는데 이것이 Serial Schedule이랑 동의한가? 동등한가? 라고 나와있는데 동등하다라고 되어 있고요. 어떻게 실행한가가 갔냐면 T2 먼저 실행하고 T1 그 다음에 실행하고 T3 나중에 실행한 것과 동의합니다. 보시면 T2를 먼저 실행하게 되면

제가 b를 읽어서 b를 썼고요. 그 다음에 a를 읽어서 b를 읽고 b를 쓰고 a를 읽어서 a를 쓰고 이렇게 되어있는데

구체적인 예로 보면은 좀 쉬울텐데

A는 100이라는 수치가 기재되어 있고, B는 200이라는 수치가 기재되어 있고, 라이트 할 때마다 10씩 더해진다고 해봅시다. 그러면 T2 먼저 하고, T1 나중에 하고, T3 마지막에 하고 이렇게 되버리면 이 경우에는 200 읽어서 210 쓰고, 그 다음에 키원 수행됐다 옆에 밀고 와서

그 다음에 200c를 읽어서 226 그 다음에는 100c를 읽어서 126 이렇게 끝나게 되거든요. 그래서 a는 120이 기조되어 있고 d는 120이 기조되어 있는데 이건 뭐 어떻게든 같게 나왔을 텐데요. 좋지 않은 예전인데 어쨌든 이렇게 결과까지 나오는데

그냥 이 순서대로 타임 순서대로 실행해도 같이 나옵니다. 여기 보시면은, 100 나오고, 100씩 나오고, 100씩 나오고, 200씩 나오고, 200씩 나오고, 200씩 나오고, 200씩 나오고. 그냥 제가 접어놓은 것도 똑같이 되죠. 그래서 T2, T1, T3 이렇게 순서대로 실행 방법과 이것이 완벽하게 일치를 합니다. 그래서 좀 더 복잡한 예정을 만들었어야 하는데, 어쨌든 이렇게 간단한 예정을 만들었어도, 이렇게 시간 순서대로 실행 방법과 순차적으로 하나씩 하나씩 하나씩 실행하고 동등하게 나오면 똑같이 나옵니다

I는 이렇게 스킬들을 잡고 병렬을 시켜도 괜찮구나 라는 것을 알 수가 있어요. 동시에 여러 트랜젝션들을 수행해도 괜찮구나. 그 다음에 여기 보시면은 여기가 좋지 않은 스케줄인데 Read/Right 있고 그 다음에 Read/Read 있고 그 다음에 Read/Right 있는데 여기 보시면은 여기 컴퓨터가 발생해요. Read/Right 형은 Read를 하고 있고 Read랑

이 부분에 대해서 라이트를 하고 있기 때문에 둘 다 컴플릭트가 발생해서 그래프가 이렇게 그려지거든요. 그려져서 옳지 않은 그런 결과값이 나오게 되는데

T1만 보시면은, 계좌이체를 보시면 되는데 T1만 보시면 A에서 10달러 빼서 B에다가 10달러 더해주는 거예요. T2는 모든 계좌를 읽어서 A도 읽고 B도 읽어서 다 더해주는 거예요. 다 더해주는 것인데 T1 먼저 실행하고 T2 나중에 실행하고 T2 먼저 실행하고 T1 나중에 실행하고 이렇게 했을 때 T2 A에 100달러 있었고 B에 100달러 있었고 이렇게 있었다고 해볼까요?

그러면 t1 먼저 실행하고 t2 나중에 실행하고 하게 되면 t1 먼저 실행하시면 a90 b110 sum은 eb에 나오고요 t2 먼저 실행하고 t1 나중에 실행하고 이렇게 했을 때 t1 먼저 실행하면 sum 100 나오고 t1 나중에 실행하면 a90 나오고 b110 나오고 결과가 똑같이 나오거든요

똑같이 나올 필요는 없지만 어쨌든 이렇게 똑같이 나오는데 문제는 이 스케줄대로 실행을 하시게 되면 T1이 90이 됐고 A가 90이 됐고 이 상태에서 sum을 해버리게 되면 sum이 190이 나오잖아요 sum이 190 나오고 나중에 B이 190이 되고 그래서 혼자서 이렇게 실행하게 되면 sum이 190이 나온 거여서 문제가 생깁니다 A만 빼진 채로 sum을 해버리니까 문제가 생긴 거죠 그래서 이렇게 스케줄을 짜면 좋지 않는데 저희가 응용소프트웨어의 성격에 따라서 혹시 문제가 없을 수도 있어요

지금은 각 계좌의 합을 구했기 때문에 문제가 생겼는데 여기서 보시면 계좌의 수를 구하고 있어요. 활성화 되어있는 계좌의 수. A의 잔고가 0보다 크거나 같다. 그러면은 E를 더해주고 B의 잔고가 0보다 크거나 같다. 그러면 E를 더해져서 전체 계좌 수를 반하는다. 콩플리트가 마구 발생했음에도 불구하고 전혀 문제없는 소프트웨어가 됩니다. 그래서.. 네.. 그래서 이제 그..

증렬 가능한 스케줄이 아닌에도 불구하고 애플리케이션 레벨에서 동작을 제대로 할 수 있다는 것을 보여주고 있어요. 그래서 반드시 모든 경우에 있어서 사이클이 없어야 된다는 뜻은 아닙니다. 이런 경우도 있다. 이 정도로 아시면 될 것 같고요. 그 다음에 뷰 관점에서 증렬 가능성을 보는 것이 있는데 증렬 가능성에 또 다른 개념이다. 라고 나와 있는데 약간 개념이 어려워요. 그리고

이것의 문제는 viewserializable 하는지 아닌지 알아보는 방법이 MP-Ward 문제거든요. 그래서 우리가 빠른 시간 내에 이것이 가능한지 아닌지 알아내는 방법이 없기 때문에 실제로는 사용되지 않습니다. 복잡하기만 하고 실제로는 사용될 수 없기 때문에 이 부분은 생략하고 넘어가고 있어요. 예를 들어서 이런 스케줄이 있다고 했을 때 디페렌셜 그래프를 그려보시면 마구 사이클이 생기거든요.

사이클이 생김에도 불구하고 이렇게 실행돼도 전혀 문제가 없는 스케줄이에요 보시면 한번 읽어서 나중에 막 쓰고 있는데 서로 그냥 읽지 않고 쓰기만 하고 있기 때문에 큰 문제가 없어요 그래서 이것과 동일합니다. 이것과 동일합니다. 이렇게 실행되는 것과 동일해서 우리가 집밴던시 그래프로 분석을 해보면 이거 문제 있다 라고 볼 수가 있는데

Vue Serializability 같은 경우에는 문제가 없거든요. 그래서 이런 것도 있고 이런 것도 있구나 라고 보시면 되는데 이게 가능한지 아닌지 알아보는 방법이 아까 말씀드린 MPIAD 문제이기 때문에 주어진 시간 내에 빠르게 풀 수가 없어서 이곳은 실제로는 사용되지 않습니다. 그래서 우리가 실제로는 아까 보셨던 Dependency Graph를 사용해서 Complete Serializability를 가지고 우리가 중요할 가능성이 있는지 없는지를 판단하다고 보시면 될 것 같고요. 이것에 대해서는 깊게 공부하실 필요는 없습니다.

그래서 스케줄들을 보시면 하나씩 순차적으로 실행하는 스케줄들이 이만큼 있다고 하면 우리가 Complete Serializable, 그러니까 Complete 관점에서 봤을 때 Serial하게 실행한 거 동일하다고 하는 스케줄들 이만큼 있고요. 그리고 더 크게 View Serializable 있고, All Schedule들이 이만큼 있습니다. 그 다음에 Transaction Drobability에서 나와 있는데 다음 강의 슬라이드에 좀 더 자세히 공부할 텐데 Committed Transaction들의 모든 변경 사항들은 지속되어야 한다.

그래서 업데이트가 쪼개져서 일부는 되고 일부는 안되고 이렇게 되어 있으면 안된다는 뜻이고요. 그리고 실패한 트랜젝션에 변경사항이 조금이라도 들어가면 안된다는 뜻입니다. 이것을 달성하기 위해서 로그를 남기거나 Shadow Paging 이라는 기법을 써야 합니다. 그래서 Acid 아까 설명을 드렸었고요. Atomacyt 모두 실행되거나 생되지 않거나 보존하기 위해서는 이미 한 것 또 하고 아니면 취소하고 이런 메카니즘이 필요하고요. 이것도 다음 슬라이드에 나와요.

그리고 여태까지 보셨던 도시성 제휴 그러니까 그 동시에 여러 개가 실행이 되고 있는데 그것이 그 시리얼 스케줄과 동일한 결과를 내야 된다고 했었죠 그래서 애터물시키지까지 보셨 그러니까 하나하나 한 트랜에 시행 모두 다 실행되거나 실행되지 않거나 그것까지는 똑같이 효과를 내야 된다는 뜻이고요 일관성을 위해서는 제약조건이나 아니면은 우리가 복제를 해서 일관성을 유지할 필요가 있고요 그 다음 권리성도 동일성 제휴를 해줘야 되고 Dura-Bility는

복제하라고나 아니면 앞으로 볼 리드 언디 메칸집을 통해서 할 수가 있습니다. 그래서 결론이 독립성 제어, 트랜지에이션과 리커버리, 복구시키는 것은 DBMS에서 가장 중요한 기능들 중에 하나다. 독립성 제어는 자동으로 일어난다 라고 되어 있어요. 여러분들 신경 쓰지 않아도 DBMS가 자동으로 일어난다 라고 되어 있고요. 그래서 독립성 제어가 어떤 것을 보장해 주냐 하면 최종 결과물이

트랜젝션을 하나씩 순차적으로 실행이 없는 것과 동일한 결과를 내줍니다. 트랜젝션이 어떻게든 보시면 감이 오셨을 수도 있을텐데 트랜젝션의 ACID를 만족시키기 위해서 굉장히 많은 노력이 들어가요. 오버헤드가 트랜젝션을 사용하게 되면 DBMS가 좀 버버워합니다. 그래서 2000년대 초반에 SQL 운동이 있어서 거기서는 트랜젝션이 굉장히 나쁘고 느리다.

라는 주장에 있어서 트랜젝션이 한때는 사라진 적이 있었거든요. 새롭게 등장한 디비내스들에서는. 그런데 그런 트렌드가 다시 사라지고 트랜젝션이 부활하는 수세에 있습니다. 보시면 구글의 스패너 논문인데요. 여기 보시면 글로벌리티 디스트리뷰티도 데이터베이스에서 나와 있는데 전 지구적으로 분산되어 있는 데이터베이스의 스패너라는 것은 그 논문 배우는 어떤 것이 있냐 하면은 우리는 믿는다. 무엇을 믿냐 하면은

트랜잭션이 없어서 심겹게 코딩을 해나가는 것보다는 차라리 트랜잭션을 가도하게 사용해서 바틀렛 성능저하를 일으키는 것이 차라리 낫다고 믿는다고 되어 있어요 과거에는 트랜잭션의 오버헤드가 너무 가도하다고 했었는데 차라리 트랜잭션이 있는게 편하다는 뜻이에요 왜냐하면 트랜잭션이 없을 때 어떤 일이 발생했냐면 프로그래머가 엔딩을 다 트랜잭션을 직접 구현을 했어야 해요

템니액션이 없는 DBMS에서 작업을 하게 되면 은행에서 계좌이체 할 때 DBMS와 트리러닉스는 보장하지 않는다 라고 하면 그걸 프로그래머가 다 알아서 했어야 했죠. 무슨 말인가 하면은 이렇게 중간이 실행되다가 갑자기 기계가 망가졌다. 그랬을 때 발생하는 모든 일들을 다 프로그래머가 책임을 지었어야 해요. 이렇게 됐을 때 어떻게 어떻게 해라 라는 것을 프로그래머 다 코딩을 했어야 해요. 그럼 굉장히 어렵겠죠.

차라리 트랜지션을 시작해서 트랜지션 끝을 하는 다음에 그 안에 5개의 문장을 넣어버리고 끝나는 일을 중간에 끝나게 되면 어떻게 될지 프로그램을 다 작성해야 되기 때문에 너무 힘들었어요. 그래서 차라리 트랜지션을 다시 부활시키고 편하게 코딩하자 라는 추세가 다시 생겼다고 보시면 됩니다. 사실 구글이 이걸 주도해서 트랜지션을 없애자 라는 걸 주도해서 통계실 없었는데 다시 구글이 트랜저션을 분할시켰습니다.

그래서 트랜젝션은 DBMS에선 중요하다. 그런데 실현하기는, 구현하기는 어렵다. 그 정도로 보시면 됩니다.

다음 강의 슬라이드로 넘어갈 건데 시간 관계상 다 나가지 못하니까 일부 해보고 많이 충분히 나갔으면 시험 범위에 들어가게 하고요 그렇지 않으면은 시험 범위에서 한번 빼겠습니다 이번 주제는 데이터베이스 로그인, 로그를 남기는 것인데요 로그는 원래 똥나무라는 뜻을 지니고 있어요. 과거 오래전에 배를 타시는 분들이

배 속도 측정을 했거든요. 배 속도 측정을 한 다음에 그것을 로그국이라는 것에 기록을 했어요. 배가 얼마나 빠른 속도로 이동하고 있는지 로그국이라는 것에 기록을 했어요. 그래서 여기에서 누래돼서 로그라고 하면은 뭔가 시간의 순서대로 기록을 남기는 것이다 라고 해서 쓰여지고 있는데 데이터베이스에서도 시간 순서에 따라서 뭔가 기록을 남기는 것을 데이터베이스에 로그인을 이용합니다. 감사합니다.

우리는 동시성 제어를 통해서 Acid의 Atomality와 Constance와 Isolation을 보장할 수 있었고요. 그 다음에 Log를 통해서 Atomality와 Naturalability를 보장하게 됩니다. 그래서 이제 예제가 하나 나오고 있는데요. 여기 보시면은 A를 하나 한번 읽고 있어요. 그러면은 우리가 그 SSG나 Hard Disk에

자료가 있으면은 그것은 우리가 활용을 할 수가 없죠. 반드시 메모리 올려야 돼요. 메모리 올릴 때 어떤 하나의 오브젝트를 올릴 수가 있는 것이 아니라 페이지 단에 올린다고 했어요. 일반적으로 4KB라고 했는데 페이지 단으로 메모리 올렸습니다. 이것은 메모리입니다. 그래서 썼어요. a에다 이런 걸 썼어요. 그 다음에 커밋을 하게 되면은

'아, 내가 쓴 A는 E라는 값이 영구적으로 데이터베이스에 남겠구나'라고 기대를 할 수가 있는데 갑자기 내 기드가 망가졌습니다. 다시 켰더니 요리는 다 사라지고 A는 E가 남아있게 되겠죠. 그래서 '아, 뭔가 추가적인 자료를 하지 않으면 드러블리티가 만족되지 않을 수 있겠구나' 그래서 내가 A는 E라고 쓰고 커밋을 했는데도 불구하고 A는 E라고 쓰는 것이 어디에도 반영되지 않아서 이렇게 중간에 망가져 버린다는 기계가

그래서 문제가 발생했을 때 복구하는 알고리즘이 필요한데 복구하는 알고리즘은 데이터베이스의 일관성과 그 다음 에트머시티랑 듀러블 요티를 그 기계가 망가졌음에도 불구하고 그것을 보장시켜주는 기술이다 라고 되어 있고요. 복구시켜주는 알고리즘은 두 개의 파트로 구성되어 있다. 첫 번째 파트는 우리가 DBMS가 실패로부터 복구할 수 있도록 평소 트랜저션들을 하는 행동들로 구성이 되었습니다.

미리 대비하는 과정이라고 보시네요. 망가질 것을 대비하면서 평소에 하는 액션들이 있고요. 실제로 뭔가 망가졌을 때 실제로 해야 하는 행동들이 있어요. 이것은 다른 슬라이드에서 공부를 하는데 저희는 다루지 못하겠죠. 그래서 평소에 어떤 작업들을 하는지에 대해서만 공부를 할 거예요. 그래서 아마 다 나가질 못하고 이 정도만 나가자는 생각이 들었는데

데이터베이스에 주된 저장장치는 비휘발성 스토리지에 있다. 그러나 휘발성 스토리지보다 훨씬 느리다 라고 되어 있는데 비휘발성이랑 휘발성은 전원이 내려갔을 때 그 자료가 남아 있는지 남아 있지 않은지에 따라서 구분이 되죠. 비휘발성은 날아가지 않는 것. 하드 디스크는 SSD가 되겠고요. 휘발성 스토리지는 뒤메뉴이죠. 메인 메모리. 좋은 하루 되세요.

그렇기 때문에 메일 메모리를 DBMS는 적극적으로 활용합니다. 훨씬 빠르기 때문에. 그래서 무언가 작업을 할 때 타겔 레코드, 대상이 되는 레코드를 메일 메모리를 올립니다. 디스크는 너무 느리기 때문에 메모리에 올려서. 그리고 쓸 때도 우선은 메모리에 써요. 디스크 너무 느리기 때문에 바로 디스크 쓰면 느려서 메모리에 쓰고. Dirty 레코드. Dirty 레코드라고 하는 것은 디스크에서 메모리에 올라왔는데 그 내용들이 서로 달라진 것을 뜻합니다. 예를 들어서

디비에 대해서 읽어왔죠. 아직은 더티하지 않아요. 그런데 내가 써버렸어요. 앤에 있는 내용을 써버렸는데 더티해진거에요. 디스크에 있는 내용물이랑 덜어들었다고 하면 더러워졌다고 하는것인데 이렇게 더러워진 것들을 다시 디스크에 쓸 필요가 있습니다. 그래서 DBMS는 다음에 그것들을 해줘야해요. 어떤 것들을 보장해줘야하냐면 DBMS가 무언가 커밋됐어 라고 하면

트랜지션은 변경 사항들이 진짜로 남아있어야 된다. 커밋됐다 라고 하면 진짜로 그것들이 반영되서 남아있어야 된다는 뜻이고요. 그 다음에 트랜지션이 중단됐다 라고 하면 어떤 부분적인 변경 사항도 지속되면 안 된다. 하나도 남아있으면 안 된다 라는 뜻이에요. 커밋됐으면 그 변경 사항이 완벽하게 남아있어야 되고 취소됐다 라고 하면 하나도 변경 사항이 남아있으면 안 됩니다.

중 하나만 되어야 돼요. 그런 것을 보장하기 위해서 해주는 작업이 언두랑 리듬가 있는데 언두는 취소하는 작업이고 리듬는 다시 하는 작업이에요. 뭔가 트랜젝션이 실패해서 중단되었다고 하면 해당 트랜젝션이 해놨던 리듬은 다 하나씩 하나씩 없애버려야겠죠. 하나씩 하나씩 없애는 것이 언두고 그 다음에 뭔가 커밋이 됐는데 디스크이 아직 쓰지 못한 채로 종료됐어요. 그러면은 다시 뭔가 작업을 수행해서 디스크에 써야겠죠. 그래서 다시 하는 것을 리듬이라고 합니다.

그래서 ond와 need를 어떻게 하는가 하는 dbms가 버퍼풀이라고 되는데 메인메모리라고 생각하시면 되요. 메인메모리를 어떻게 관리하는지에 따라 달려있다. 이렇게 나와있구요. 버퍼풀이라고 되는데 메인메모리라고 생각하시면 됩니다. 이러한 스케줄이 있구요. 메인메모리 상태이고, 디스크에요. 그래서 a를 읽겠다 라고 되어 있어서 a가 있는 페이지를 통째로 읽어옵니다.

여기 A뿐만 아니라 B도 있고 C도 읽네요. 그 다음에 A를 쓰는 것이 있죠. A를 3으로 썼어요. 그 다음에 B를 읽으니까 9였고 거기서 E를 빼서 8이라고 저장했습니다. 그리고 커밋을 했어요. 커밋을 한순간 이 변경사항은 여기에 저장해야 될까? 라고 물어보고 있어요. 그래서 정책에 따라서 저장하는 정책도 있고 저장하지 않고 넘어가는 정책도 있습니다. 그리고 마찬가지로 제스크를 쓴다고 했을 때 A까지 아직 커밋도 안 되는데 같이 써야 될까? 라는

그 물음이 있는데 이것도 써도 되는 정책이 있고, 쓰면 안 되는 정책이 있어요. 다 나중에 나올 겁니다. 결정하기 나름이고요. 그래서 만약에 T1이 롤백을 해버렸어요. 어, 나 일단 어떤 일로 할래? 라고 생각되면은 어떤 작업들을 해야 될까? 이것이 굉장히 쉬운 정책도 있고, 좀 어려운 정책도 있습니다. 그래서 우리가 정책을 삼키는 나름인데, 두 가지 정책이 있어요. 스틸이랑 포스라는 정책이 있는데,

둘가지 정책을 어떻게 펼치느냐에 따라서 전략이 달라집니다. 첫번째 다운받이 스틸 폴리션인데 스틸은 아직 커밋되지 않은 트랜젝션이죠. 아직 커밋되지 않은 트랜젝션에 dirty한 오브젝트를 쓸지 말지를 정하는거에요. 아직 커밋되지 않은 dirty한 오브젝트를 쓸지 말지 정하는 것입니다. 이 물음이에요. 지금 이것을 쓰려고 하는데 아직 커밋이 안됐죠. 여기까지 밖에 진행 안되서

커밋이 안됐어요. 신지어는 롤백이 예정되어 있는데 아직 모르는 문제죠. 이것을 써야 될까 말아야 될까 써도 된다 라고 하는 것이 써서 덮어서도 된다 라고 하는 것이 스틸이구요. 추방 자리를 쫓아내는 뜻인데 자리를 쫓아내서 덮었습니다. 이것이 허용되는 스틸이구요. 이것이 허용되지 않으면 노 스틸입니다. 그러니까 아직 커밋되지 않았는데 써도 된다.

그렇지 않으면 no speed을 내리겠습니다. 그 다음에 forcePolicy는 Transaction이 Commit했을 때 디스크에 쓸지 말지를 정하는 거예요. force면 강제한다는 뜻이죠. 디스크에 쓰는 것을 강제하는 것이고요. no force는 강제하지 않는 거예요. 보시면 P2 Commit했죠. Commit했으면 이걸 써야 된다. 라고 하는 것이 force고 바로 쓰게 된다. 뜯지 않는 것이 녹호스가 가능했으니까

조합이 4개가 있습니다. 스틸과 노스틸, 포스랑 노포스가 있는데 조합이 총 4개가 가능한 것이 스틸포스, 스틸 노포스, 노스틸포스, 노스틸 노포스 이렇게 2개가 있는데 이 중에서 의미있는 것은 2개밖에 없어요. 스틸 노포스랑 의미가 있는 것은 스틸 노포스랑 노스틸 포스가 있는데

일단 no-stil force 예제부터 나왔습니다. 어떤 것을 뜻하냐 하면, no-stil 보시면, 얘는 아직 커밋되지 않았으니까 쓰지 말아라 라고 하는 것이요. 그리고 force는 얘는 커밋됐으니까 써라 라는 거에요. 그러니까 이건 좀 단순해요. 커밋이 안됐으면 쓰지 말고 커밋이 됐으면 써라 라는 것이고요. 반대되는 개념은, 너는 아직 커밋도 안되는데 써도 돼 라는 것이고 얘는 커밋됐어도 안쓰도 돼 라는 것인데, 상황에 따라서 디스크의 쓸지 말지를 결정한다는 것인데 그렇기 때문에 이쪽은 성능에서 우위를 정한 것입니다. 이쪽은.

디스크에 한 번 가는 곳이 굉장히 코스트가 많이 드는데 얘네들은 무조건 디스크로 가는 것이 아니라 상황에 따라서 디스크에 가는 곳이기 때문에 커밋면은 유리한데 어쨌든 노스트리트 포스에 대해서는 살펴볼 거예요. 중간 단계에 쓰지 마라 라고 커밋됐으면 써라 라는 것인데 다시 A를 읽어서 A를 쓰고 B를 읽어서 B를 쓰고 커밋됐죠? 커밋됐기 때문에 이것을 써야 되는데 노스트리트는 A는 쓰면 안 안된대요.

어떻게 해야 되냐면 A는 반영되지 않은 B에 변경사항만 반영된 페이지를 하나 만들어서 이것을 쓰게 됩니다. 이렇게 쓰게 되면 T2에 결과물이 반영되고 T1은 반영이 안되죠. 이런 식으로 쓰게 됩니다. 만약 T1에서 룰백이 일어났다 그러면 이거 버리고 끝나요. T1이 관여해졌던 페이지를 삭제해버리면 끝나면 되나요?

디스크에 쓰지도 않았으니까 굉장히 쉬워요. 그래서 노스트리 포스는 구현하기에 가장 쉽다 라고 생각했고요. 언두할 필요가 없어요. 언두랑 리드를 반드시 해줘야 한다고 했는데 언두할 필요가 없고 메인 메모리 일시적으로 있었던 것들 있죠. 롤백된 트랜지어셨이 만들었던 메모리 일시적으로 있었던 것들은 디스크에 하나도 쓰여져 있지 않기 때문에 취소할 필요가 없고 메모리를 삭제만 하면 돼요. 언두 할 필요가 없습니다.

그 리드 할 필요도 없어요. 왜냐하면 커밋된 것들은 무조건 디스크에 쓰여지기 때문에 리드를 할 필요도 없습니다. 언두 할 필요도 없고 리드 할 필요도 없고. 그런데 이것의 가장 큰 문제는 뭔가 트랜젝션이 작업을 하게 되면 메인메모리에 마구 페이지를 생성하게 되는데 굉장히 많은 페이지를 생성하게 돼서 메인메모리에 다 들어가지 않는다 라고 하게 되면 문제가 생깁니다. 메인메모리에 변경사항을 다 전형하는데 그 변경사항들이 메모리 크기를 넘어졌다 라고

이런 행동이 되면 이것은 어떻게 감당할 수가 없어요. 이런 문제가 발생하게 됩니다.

그 다음에 Shadow Paging은 아까 보셨던 Nost, Force에 약간 발전된 형태인데 이 Shadow Paging은 데이터베이스의 두 가지 버전을 유지하고 있습니다. Master 버전은 오로지 Committed Transactions의 변경사항만 기록된 버전을 Master 버전이라고 하고요. Committed 변경사항들만 있어요. 그 다음에 Shadow 버전은 아직 Committed Transactions들의 변경사항이 반영된 데이터베이스가 되겠습니다.

이 Shadows Paging에서는 DBMS가 트랜지션을 사용하기 전에 카피본을 하나 만들어서 작업을 하고 만약에 성공적으로 끝났다고 하게 되면 Shadows가 변경사항에 반영된 거니까 Shadows를 마스터로 만들고 새로운 작업을 하게 됩니다. 그래서 Shadows Paging도 Lost에 보스를 하고

쓰는 거예요 중간 단계에는 반영하지 않고 커밋되면 무조건 반영하고 이것을 쓰는 것인데 가장 대표적인 것이 여러분들이 익숙할만한 것이 SQLite 최근 버전은 이거 안쓰는데 2010년도까지는 이것을 썼어요 쉐도우 페이징 기반을 써서 지금도 옵션을 잘 주면 쉐도우 페이징을 쓰도록 할 수가 있는데 굳이 그렇게 할 필요가 없겠죠. 아주 오래전에 만든 데이터베이스랑 호환성을 유지해야 한다고 하면 호환성을 위해서

옵션을 남겨줬기 때문에 쓸 수는 있는데, 굳이 그럴 필요가 없다고 하시면 굳이 쉐도우 페이징을 쓰실 필요가 없습니다. 쉐도우 페이징의 예제인데, 마스터 포인터는 데이터베이스, 그러니까 커밋된 트랜지션들의 변경사항들 저장된 데이터베이스를 가르치는 포인터가 되는데요. 이것은 페이지 디렉토리라고 보시면 돼요. 첫 번째 페이지는 어디 있고, 디스크가 어디 있고, 두 번째 페이지는 어디 있고, 이런 걸 밝히고 있습니다.

트랜젝션 T1이 생겨서 뭔가 변경을 하라고 해요. 그러면 이 섀도우가 생겨나서 이것을 복제합니다. 이걸 복제해서 섀도우를 만들어요. 복제했기 때문에 지금 다 똑같겠죠? 똑같은 곳을 가리키고 있어요. 복제를 했기 때문에. 그 다음에 트랜젝션 T1이 뭔가 업데이트를 하려고 해요. 업데이트를 하려고 하면 이 마스터를 건드리는 것이 아니라 이 섀도우를 건드립니다. 그래서 여기를 뭔가 건드리려고 하면은

이것을 복제본을 만들어서 여기를 건드리게 하고요. 그 다음에 여기를 건드리면은 여기 복제본을 만들어서 또 여기를 수정하게 합니다. 계속해서 수정을 하게 하고 동시에 T2라는 트랜지에이션이 뭔가 읽고 있어요. 읽으려고 그러면은 그냥 마스터 읽게 하면 되겠죠. 마스터 버전 읽게 하면 되요. 그래서 나중에 T1이 커밋을 했어요. 그러면 변경사항에 가해진 파란색 부분들을

이 커밋댄 트랜젝션이기 때문에 이것을 업데이트해서 이 마스터 포인트는 원래 여기 가르치고 있었을텐데 업데이트해서 이 파란색을 가르쳐라 라고 업데이트를 하고 얘가 여기 가르치되는거에요. 이걸 폐기하고 그러면은 이것이 새로 마스크가 된거에요. 얘는 변경된 트랜젝션을 건드린 부분들을 이제 잘 가르쳐 볼게요.

이렇게 동작을 합니다. 그 Shadow Penis는 롤배드랑 리커버리가 굉장히 쉽다 라고 되어있어요. 만약에 Undue를 하고 싶다 라고 하게 되면은 Shadow Penis를 없애버리면 됩니다. 뭔가 요새는 Commit이 됐는데 Commit되지 않고 뭔가 다 취소해야 된다 라고 하면은 이거 다 버리면 끝나요. 버리고 그 이전 상태는 여기 암박하게 남아있잖아요. 감사합니다.

리두는 아예 할 필요가 없다고 되어 있는데 트랜셔리션이 완료가 커밋되면 무조건 디스크에 쓰여져 있는 상태로 끝나기 때문에 이걸 다 가르치고 있죠. 그래서 리두를 할 필요가 없습니다. 리두를 해야 되는 것이 뭔가 메인메일에선 변경되는데 디스크에 안 쓰여졌다 라고 하면 문제가 되는 것인데 이 디스크에 다 쓰여져 있잖아요. 그래서 리두를 할 필요가 없습니다. 그래서 이제 복구하거나

롤백할 때 굉장히 편한데 단점이 페이지 테이블을 전체를 다 복사해야 하기 때문에 굉장히 비슷합니다. 그래서 LNDB 같은 경우는, 우리는 공부하지 않았지만 LNDB 같은 경우는 페이지 테이블은 B+Tree를 유지하고 있어서 전체 테이블을, Tree를 카피하는 것이 아니라 우리가 변경점에 가한 LNDB까지 가는데 필요한 경로만 복사를 하면 되서

이것을 야간 보완할 수 있는데, 이것은 공부하지 않으니까 자세히 안표는 없고요. 어쨌든 전체 테이블을 복사하는 것은 비용이 비싸다. 그리고 commit overhead도 높습니다. 왜냐하면 모든 업데이트된 페이지랑 페이지 테이블이랑, 루트, 아까 이런 마스터 프린터라고 보시면 될 것 같은데, 이것들을 다 디스크에 써버려야 하기 때문에, 이렇게 쓰는 것이 굉장히 시간이 오래 걸리죠. 그리고 심지어는

스퀀셜 라이트가 아닐 수도 있어요. 스퀀셜 라이트가 아닐 수도 있어서 굉장히 힘듭니다. 그래서 데이터가 마구 파편화되는 문제가 발생하고요. 보시면 새로운 데이터에서는 이렇게 있잖아요. 스퀀셜 라이트가 안 되어 있어서 이전에는 풀 스퀀셜 라이트가 이렇게 쭉 스퀀셜 라이트 읽으면 되는데 이제는 여기서는 이렇게 읽고 스퀀셜 하지 않게 됐어요. - 그럼, 잡이구, 여기를, 여기를, 여기를, 여기를.

파편화대에서 힘들다. 가비지 컬렉션이 필요할 수도 있다. 중간에 마구 생겨나는 카피 본드를 그리고 과거의 마스터 테이블을 정리를 해야 하기 때문에 가비지 컬렉션이 필요하고요. 라이터가 하나만 허용됩니다. 쓰는 것이 하나만 허용되고 동시에 여러 개의 라이터 트랜젝션들이 동작할 수가 없어요. 동시에 여러 개가 도착하게 되면 실로가 여러 개 막 생겨나야 되는데

그렇게 되면 복잡해져서, 쉐도우는 하나만 만들 수 있습니다. 일반적인 트랜지션에서는 라이터가 여러 개 있을 수 있는데, 쉐도우 페이징 쓰게 되면 하나만 하면 된다고 나와있어요. 이런 단점들이 있고요.

SQLite 보시면은 2010년 이전에 SQLite 같은 경우 보시면은 무언가 트랜지에서들이 페이지를 변경하고자 하면은 DBMS는 오리지널 페이지를 별도의 전월 파일이라는 것을 만듭니다. 또 전월이 일기장이라는 뜻도 있는데 일기와 같은 곳에 저장해서 만든다고 보시면 될 것 같구요. 예를 들어서 페이지 6을 딱 수정하려고 해요. 그러면은 원본 페이지를 여기다 저장하고

페이지 2도 뭔가 변경하려고 하면 원본을 저널 파일에 제정합니다. 이렇게 하다가 갑자기 망가졌다고 하면 저널 파일이 그대로 있는 채로 시작이 되겠죠. 그 다음에 시작했는데 저널 파일이 존재했다고 하게 되면 DBMS가 이 저널 파일을 보고 과거에 디스크에 발생했던 작업들을 다 취소하게 됩니다. 커밋되지 않은 작업들을 취소하게 됩니다.

그래서 관찰을 보시면, Shadows Paging은 DBMS가 디스크에서 녀석적이지 않은 랜덤 액세스를 해서 라이트하는 것을 수행하게 됩니다. 아까 이렇게 들으면 녀석적이지 않죠.

그래서 랜덤 라이트보다는 시퀄셜 라이트로 바꿔주고 그리고

데이터가 변경될 때마다 각 페이지를 쓸 필요가 없는 정책이 필요하다고 되어 있어요. 한 번에 몰아서 시크셜 라이트를 쓰는 것이 낫지, 필요할 때마다 조금씩 조금씩 갖춰서 쓰는 것은 성능에서 저가가 발생하니까 반드시 텐션이 커밋될 때마다 그쪽만 쓰는 것보다는

스케줄을 잘 짜서 효율적으로 쓰는 것이 좋다는 뜻을 보시면 됩니다. 카우치 디비 같은 경우는 섀도우 페이지를 데이터베이스 끝에 붙이기만 합니다. 그래서 시퀘셜 라이트를 지원하긴 하는데 전체 페이지를 쓰고 있기 때문에 이것도 월드가 있습니다. 그리고 뭐하지 않는다면 카우치 디비 같은 경우는 무시하겠는데요. 어쨌든 섀도우 페이징은 성능상에서 문제가 있다. 랜덤 라이트도 많이 하고

그래서 우리가 시퀀셜 라이트를 바꾸고 그 다음에 필요할 때마다 몰아서 라이트를 해주는 것이 좋은 쪽으로 가야 되는데 그렇게 해주려고 하면은 라이트 어리드 로그 방식 많은 DBMS가 채용하고 있는 이 방식으로 가야 되는데요 이 부분은 공부를 할 수가 없겠네요 그래서 여기까지만 진도를 나갈 거고요 시험 범위는

네 여기까지 하도록 하겠습니다. 19페이지까지. 로깅도 시험에 나와요. 그러면은 여기까지 진도 나가고 이번 학기 시험 마치도록 하겠습니다.