"최종"일관성과 거래가없는 거래 (일명 Simpledb)를 얼마나 멀리 갈 수 있습니까?

Question

나는 정말로 SimpleDB를 사용하고 싶지만 실제 잠금과 트랜잭션이 없으면 전체 시스템이 치명적으로 결함이 있다고 걱정합니다. 나는 고도로 읽기/저작물 앱의 경우 결국 시스템이 일관되게되기 때문에 의미가 있지만 그 사이의 시간은 어떻습니까? 일관되지 않은 DB의 올바른 쿼리는 전체 데이터베이스 전체에서 추적하기가 매우 어려운 방식으로 혼란을 일으킬 것 같습니다. 잘만되면 나는 단지 걱정 사마귀가되고있다 ...

Answer 1

이것은 일관성과 확장 성 사이의 전형적인 전투입니다. 일부 데이터가 항상 그렇게 일관 될 필요는 없습니다. 예를 들어, digg.com과 이야기에 대한 Diggs 수를보십시오. DB가 "user_digg"테이블에 대한 조인을 강요하기보다는 "Digg"레코드에 값이 복제 될 가능성이 높습니다. 그 숫자가 완벽하게 정확하지 않으면 중요합니까? 아마 그렇지 않을 것입니다. 그런 다음 SimpleDB와 같은 것을 사용하는 것이 적합 할 수 있습니다. 그러나 은행 시스템을 작성하는 경우 아마도 무엇보다도 일관성을 평가해야 할 것입니다. :)

1 일째부터 방대한 규모를 다루어야한다는 것을 알지 못하면 RDBMS와 같은 더 간단한 기존 시스템을 고수 할 것입니다. 합리적인 비즈니스 모델로 어딘가에서 일하고 있다면 트래픽이 크게 급증하는 경우 수익이 크게 급증 할 수 있기를 바랍니다. 그런 다음 그 돈을 사용하여 스케일링 문제를 해결할 수 있습니다. 스케일링은 단단하고 스케일링은 예측하기 어렵습니다. 당신을 해치는 대부분의 스케일링 문제는 당신이 결코 기대하지 않는 문제가 될 것입니다.

나는 오히려 사이트를 시작하고 트래픽이 픽업 될 때 규모 문제를 해결 한 다음 규모에 대해 걱정하는 데 많은 시간을 소비하여 돈이 부족하기 때문에 절대 생산에 절대 만들지 않을 것입니다. :)

Answer 2

당신이 이야기하고 있다고 가정합니다 이 단순한, 당신은 걱정하지 않습니다. 실제 DBM으로 사용하지 않는 실제 이유가 있습니다.

DBMS의 트랜잭션 지원에서 얻은 특성은 약어 "산"과 같은 약자, 일관성, 격리 및 내구성에 의해 약식 될 수 있습니다. A와 D는 대부분 시스템 충돌과 관련이 있으며 C와 저는 정기적 인 작동과 관련이 있습니다. 그것들은 사람들이 상용 데이터베이스를 사용 할 때 완전히 당연한 것으로 여기기 때문에 하나 이상이없는 데이터베이스를 사용하는 경우 불쾌한 놀라움을받을 수 있습니다.

원자력: 모든 거래는 완전히 완료되거나 전혀 완료되지 않습니다 (즉, 깨끗하게 커밋하거나 중단합니다). 이것은 단일 문 ( "업데이트 테이블 ...")과 더 길고 복잡한 트랜잭션에 적용됩니다. 이것을 가지고 있지 않으면 잘못된 것이 무엇이든 (예를 들어, 디스크가 가득 차고 컴퓨터 충돌 등)는 반쯤 남을 수 있습니다. 다시 말해, 실제 문제가 발생할 수 있고 간단한 업데이트 문도 부분적으로 완료 될 수 있기 때문에 DBM에 DBMS에 의존 할 수는 없습니다.

일관성: 데이터베이스에 대해 설정 한 규칙은 항상 시행됩니다. 마찬가지로, A Always B와 같은 규칙이있는 경우, 데이터베이스 시스템에 아무도하지 않는 사람이 해당 규칙을 위반할 수 없습니다. 시도하는 작업에 실패합니다. 모든 코드가 완벽하다면 이것은 중요하지 않습니다 ... 그러나 실제로 그 경우는 언제입니까? 또한,이 안전망이 빠졌다면, 잃을 때 상황이 정말 유쾌 해집니다 ...

격리: 데이터베이스에서 취한 모든 작업은 마치 연속적으로 발생하는 것처럼 (한 번에 하나씩) 실행됩니다. 한 명 이상의 사용자 가이 데이터베이스를 동시에 누르고 있다면, 당신이 이것을 가지고 있지 않다면, 당신이 꿈조차 할 수없는 것들이 잘못 될 것입니다. 원자 진술조차도 예상치 못한 방식으로 서로 상호 작용하고 물건을 망칠 수 있습니다.

내구성: 전원을 잃거나 소프트웨어 충돌이 발생하면 진행중인 데이터베이스 트랜잭션은 어떻게됩니까? 내구성이 있다면 대답은 "아무것도 - 모두 안전합니다"입니다. 데이터베이스는 실패 후 현재 상태를 재구성 할 수 있도록 "Undo / Redo Logging"이라는 것을 사용하여 "Undo / Redo Logging"이라는 것을 사용하여 다음을 수행합니다. 그 없이는 위의 다른 속성은 일종의 쓸모가 없습니다. 왜냐하면 충돌 후 일관성을 유지할 수 없기 때문입니다.

이런 것들이 당신에게 중요합니까? 답은 당신이하고있는 거래 유형과 실패 상황에서 원하는 것을 보장하는 것과 관련이 있습니다. 필요하지 않은 경우 (읽기 전용 데이터베이스와 같은) 사례가있을 수 있지만, 사소한 일을 시작하면 나쁜 일이 발생하자마자, 당신은 당신이 원했을 것입니다. 어쩌면 당신이 예상치 못한 일이 발생할 때마다 백업으로 되돌아가는 것은 괜찮지 만, 내 추측은 그렇지 않다는 것입니다.

또한 이러한 모든 보호 기능을 삭제한다고해서 데이터베이스가 더 나은 성능을 발휘할 수있는 것은 아닙니다. 사실, 아마도 반대 일 것입니다. 실제 DBMS 소프트웨어는 또한 수많은 코드가 있기 때문입니다. 최적화 쿼리 성능. 따라서 Simpledb에서 6 개의 테이블을 결합하는 쿼리를 작성하면 해당 쿼리를 실행하는 최적의 방법을 알아낼 것이라고 가정하지 마십시오. 상용 DBM이 색인화 된 해시가 결합하여 .5 초 안에 가져옵니다. 쿼리 성능을 최적화하기 위해 할 수있는 작은 트릭이 있으며, 저를 믿으십시오.

이 중 어느 것도 Simpledb를 노크하는 것은 아닙니다. 그것을 가져 가라 소프트웨어의 저자: "훌륭한 교육 도구이지만 다른 사람이 다른 사람에게 사용하고 싶다고 상상할 수 없습니다."