MongoDB에 대한 '데이터 손실' 비판은 어느 정도 유효합니까?

MongoDB에 대한 '데이터 손실' 비판은 어느 정도 유효합니까?

MongoDB에 대한 '데이터 손실' 비판은 어느 정도 유효합니까?다음을 가리키는 것입니다.

1. MongoDB는 벤치마크를 획득하기 위해 기본적으로 안전하지 않은 방법으로 쓰기를 발행합니다.

getLastError()를 발행하지 않으면 MongoDB는 명령어가 처리되었음을 데이터베이스에서 확인할 때까지 기다리지 않습니다.이로 인해 적어도 다음 두 가지 종류의 문제가 발생합니다.

• 동시 환경(접속 풀 등)에서는 쓰기 완료 후 후속 읽기 실패가 발생할 수 있습니다.데이터베이스가 어느 시점에서 쓰기 커밋을 인식할지를 알기 위한 장벽 조건은 없습니다.
• 다양한 장소의 큐잉, TCP 버퍼 내의 미결 사항 등으로 인해 알 수 없는 수의 저장 작업이 바닥에 드롭될 수 있습니다.데이터베이스의 접속 드롭이 KILL'd 또는 segfault일 경우 하드웨어 크래시가 발생합니다.

2. MongoDB는 많은 놀라운 방법으로 데이터를 잃을 수 있다

다음은 우리가 개인적으로 경험한 기록 분실 방법 목록입니다.

1. 가끔 사라지곤 했어요원인 불명.
2. 손상된 데이터베이스를 성공적으로 복구하지 못했습니다. 트랜잭션 로그 전.
3. 마스터와 슬레이브 간의 복제는 oplogs에 공백이 있어 마스터가 가지고 있던 기록이 없어졌습니다.예, 체크섬은 없습니다.또, 레플리케이션 상태는 슬레이브가 최신입니다.
4. 복제가 오류 없이 중지되는 경우가 있습니다.복제 상태를 모니터링합니다.

...[기타 비판]

만약 여전히 유효하다면, 이러한 비판은 어느 정도 우려스러울 것이다.이 문서에서는 주로 v1.6과 v1.8에 대해 언급하고 있지만 그 이후 v2가 출시되었습니다.기사에서 설명한 단점은 현재 출시 시점에서도 여전히 미해결 상태입니까?

콘텍스트에 관한 주의:

이 질문은 2012년에 제기되었지만 오늘날까지도 트래픽과 투표가 이어지고 있습니다.원래 답변은 질문 당시 인기 있었던 특정 게시물을 반박하는 것이었다.이 답변이 작성된 이후 상황은 크게 변화하고 있습니다(그리고 계속 변화하고 있습니다).MongoDB는 기본적인 저널링과 같은 것들이 비교적 새로운 2012년보다 훨씬 더 견고하고 신뢰할 수 있게 되었습니다.이 답변에 대한 자세한 내용과 코멘트를 얻을 수 있는 것은 제목에 관한 질문(상세가 아니라 현재 가치)에 대한 현재의 일반적인 답변에 대해 언급하고 있지 않다고 느끼기 때문입니다."데이터 손실 비판은 여전히 유효합니까?"아래 업데이트에서 명확하게 설명하려고 했지만 기본적으로 이 질문에 대한 완벽한 답은 없습니다.관점, 기대/상태, 사용 중인 버전, 기본 설정에 대한 불쾌감 등에 따라 달라집니다.

원답:

MongoDB의 CTO이자 공동 창업자인 Eliot Horowitz는 이 게시물을 다음과 같이 하나하나 공개했다.

http://news.ycombinator.com/item?id=3202959

여기에도 좋은 요약이 있습니다.

http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/

요약하자면, 이것은 기본적으로 확실한 증거나 확증 없이 관심을 끌기 위해 (성공적으로) 발버둥치는 누군가였던 것 같습니다.과거에도, 제품의 진화에 수반해, 또는 보다 구체적인 버그가 발견되어 수정되었을 때에 대처한 실제의 사고가 있었습니다(예를 들면, 1.8의 저널링의 도입 참조).

면책사항:저는 MongoDB(기존 10gen)에서 일하고 있습니다.필네이트가 여기에 와서 독립적으로 먼저 반박했다는 사실이 마음에 듭니다.아마도 그 제품에 대해 다른 무엇보다도 더 많은 것을 말하고 있을 것입니다.

갱신일 : 2013년 8월 19일

SERVER-10478의 버그 발표와 관련된 것으로 생각되는 이 답변에 대해 최근 많은 액티비티를 보았습니다.이것은 확실히 엣지 케이스입니다만, 이 문제의 수정을 포함한 v2.2.6 및 v2.4.6으로 가능한 한 빨리 업그레이드하기 위해 큰 문서와 함께 샤딩을 사용하는 것을 추천합니다.

갱신일 : 2017년 3월 24일

저는 더 이상 MongoDB에서 일하지 않지만, 그래도 이 답변을 지지합니다.이 답변이 계속 높은(낮은) 투표와 많은 조회수를 얻고 있는 것을 감안하여 이 질문 이후 MongoDB의 진척을 보여주는 이 게시물에 있는 사람들을 지적하고 싶습니다.이제 데이터베이스는 Jepsen 테스트를 통과하고 테스트를 빌드 프로세스에 통합했습니다. 통과하지 못한 훨씬 더 성숙한 시스템이 많이 있습니다.2017년에도 데이터 손실 문제를 극복하고 있는 사람들은 전혀 주의를 기울이지 않고 있습니다.

갱신일 : 2020년 5월 24일

Jepsen은 MongoDB 4.2.6을 재분석했습니다.MongoDB는 현재 풀 ACID 트랜잭션(full ACID transactions)을 제공하고 있으며, 부분적으로는 상당히 기술적인 수준이지만 MongoDB의 데이터 손실이 우려되는 경우 기사를 읽을 것을 강력히 권장합니다(Jepsen 테스트에서 사용하는 데이터베이스 중 어느 것이든 확인해도 취약할 수 있습니다).이 보고서에서는 기본 읽기 및 쓰기 문제의 취약점을 요약하고 적절한 읽기 및 쓰기 문제와 함께 트랜잭션 이외의 읽기 및 쓰기가 얼마나 안정적인지에 대해 설명하고 문서의 결함을 해결하며 새로운 ACID 트랜잭션(및 관련 읽기/쓰기) 테스트 시 발생하는 문제에 대한 중요한 세부 정보를 제공합니다.(te connections)

그렇다면, MongoDB로 데이터를 손실할 수 있습니까?네, 특히 기본 설정의 경우 대부분의 데이터베이스에 해당됩니다.이 질문에 답했을 때의 상황보다 상황이 크게 개선되어 신뢰성과 내구성이 향상되었습니다.또한 이 기능은 (트랜잭션을 제외하고) 기능하고 있는 것 같습니다.운용에 있어서의 구성의 제한에 대해 학습하고, 제품/비즈니스/유스케이스에 대해서 데이터 손실의 리스크가 허용 가능한지를 판단해 주세요.

모든 경우를 대변할 순 없지만 내 사건만 대변할 순 없어그러나 Mongo나 그 경쟁사에서 일하지 않는 다른 답변과는 달리, MongoDB를 사용할 때 데이터가 손실되어 약 10년간 Mongo를 사용했기 때문에, 이하대로 하겠습니다.

2020

Jepsen은 MongoDB 4.2.6을 평가하여 다음과 같은 결론을 내렸습니다.

MongoDB 4.2.6은 읽기 및 쓰기 문제가 가장 심한 수준에서도 스냅샷 격리를 유지하지 못했습니다.대신, Jepsen은 읽기 왜곡, 주기적인 정보 흐름, 중복 쓰기 및 내부 일관성 위반을 관찰했습니다.기본값이 약하다는 것은 트랜잭션에서 쓰기가 손실되고 더티 읽기가 허용될 수 있으며 데이터베이스 및 수집 수준에서 요청된 안전 수준을 다운그레이드할 수도 있음을 의미합니다.

2016년(및 2020년)

2016년 Meteor 프로젝트에서는 MongoDB 쿼리가 항상 일치하는 문서를 반환하지 않는 문제가 발생했습니다.

이후 관리자 패스워드를 설정하지 않고 디폴트로 모든 인터페이스에서 리슨하는 MongoDB의 정책도 많은 사용자에게 좋지 않게 작용하고 있습니다.디폴트로는 모든 포트로 리슨하는 것은 좋지 않다는 것은 20년 전(아마도 그 이전에는 알고 있었을 것입니다만)부터 알고 있었습니다.그 때문에, 다른 소프트웨어에서는 이 문제를 회피하고 있습니다.

2020년 업데이트: 야옹 공격으로 인해 Mongo의 오래된 네트워크 디폴트 데이터베이스가 자동으로 파괴되었습니다.

2014

2014년에는 안정적인 MongoDB 드라이버에서 완전히 다른 버그가 발생하였습니다.

2013

이후 2013년에 MongoDB 기본값이 네트워크 파티션 중에 인식된 쓰기의 상당한 손실을 야기할 수 있다는 연구 결과가 발표되었습니다.

또한 2013년 Mongo 공식 생산 노드 Mongo 드라이버는 모든 오류를 포장하여 폐기했습니다.

2010

이것이 내가 Mongo를 처음 사용하기 시작했을 때, 그 당시에 Mongo에 대한 주된 비판은 다음과 같았다.

• Mongo의 안정적인 버전에는 사용자에게는 분명하지 않은 데이터 손실의 주요 버그가 있었다.예를 들어, 1.8 이전 비클러스터 구성에서는 데이터가 손실될 수 있습니다.이는 Mongo에 의해 문서화되어 있지만, 안정적인 버전의 DB에서 데이터 손실 버그가 발생하는 정도는 아닙니다.

그 비판의 주된 방어는 다음과 같다.

• 사용자는 이 위험을 명확하게 알지는 못했지만 알고 있었다.사용자는 시작하기 전에 모든 설명서를 읽어야 합니다.

저 자신의 경우 1.7을 단일 서버 구성으로 사용하고 있었지만 위험을 인식하고 있었습니다.백업을 위해 DB를 종료했습니다.DB 자체를 종료하는 동작으로 인해 10gen의 지원(무료)을 받았지만 데이터를 복구할 수 없었습니다.

결론

Mongo가 퍼포먼스 벤치마크를 획득하기 위해 안전하지 않은 디폴트를 가지고 있다는 일반적인 관측은 수년간 반복되어 왔습니다.Mongo는 일반적으로 사용자가 모든 관련 문서를 읽음으로써 이러한 사항을 인지하고 필요할 경우 안전한 옵션을 사용할 수 있다고 응답합니다.

2020년을 기점으로 MongoDB는 시간과 투자만으로 보다 안정적인 제품이라고 생각합니다만, 10년간 당사의 데이터를 베타 테스트에 사용한 것은 결코 믿을 수 없으며, 또 다른 데이터 손실 조건이 밝혀져도 전혀 놀라지 않을 것입니다.Postgres JSONB, FoundationDB, DynamoDB 및 Reconstock을 사용해 왔습니다.DB는 구조화된 데이터 저장소로서 유효한 대안이 될 수 있습니다.

2017년 2월 현재, 가장 최근의 MongoDB 분석 결과, MongoDB 3.2.11 및 3.4.0-rc4까지의 모든 버전의 MongoDB에서 데이터 손실이 가능했습니다.

따라서 질문을 작성할 때(2012년) 대답은 '그렇다'고 했어야 했는데, 이론적인 관점에서 보면 그러한 비판은 타당했다.하지만 고객들은 그 이론에 신경 쓰지 않는 것 같아요.재고할 때DB 실패가 확인되었으므로 정확성은 중요하지 않습니다.중요한 것은 출시 기간뿐입니다.너무 슬퍼요.

2018년 10월 현재 On MongoDB 3.4 - 이것은 여전히 문제입니다.

최근 버전에서는 이러한 심각한 문제에 대해 들어본 적이 없습니다.당신이 고려해야 할 것은 MongoDB는 뒤에 있는 관계형 시스템으로서 10년 동안 발전한 것이 없다는 것입니다.또한, MongoDB는 데이터 손실을 방지하기 위한 기능을 전혀 제공하지 않는 것이 사실일 수 있습니다.그러나 관계형 시스템을 사용하더라도 데이터가 손실되는 일은 없습니다.시스템 구성에 따라 크게 달라집니다(복제 및 수동 데이터 백업을 사용하면 매우 안전합니다).

베타 버그나 이전 버전의 버그를 피하기 위한 일반적인 가이드라인으로 프로덕션에서 새로운 버전을 사용하지 마십시오(debian이 서버에 매우 인기 있는 이유가 있습니다).만약 MongoDB가 (항상) 그렇게 심각한 문제를 겪고 있다면, 사용자 리스트는 적어질 것입니다.https://www.mongodb.com/community/deployments 게다가 저는 이 페이스트빈 메시지를 별로 신뢰하지 않습니다.왜 익명으로 공개됩니까?이 개인 회사는 mongodb를 사용했다고 말하는 것이 부끄럽습니까, 그들은 10gen을 두려워합니까?이러한 버그 리포트에 대한 링크는 어디에 있습니까(또는 10gen이 JIRA에서 삭제했습니까)?

이러한 점에 대해 간단히 설명하겠습니다.

1. Yep MongoDB는 화재 및 망각 모드에서 정상적으로 동작합니다.단, https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError 옵션을 사용하여 이 옵션을 변경할 수 있습니다.따라서 MongoDB가 디폴트로 설정되어 있다고 해서 필요에 따라 변경할 수 없는 것은 아닙니다.그러나 앱 내에서 실행하거나 잊어버리지 않으면 왕복이 추가되므로 성능이 저하될 수 있습니다.

   업데이트: 버전 2.6 이후 명령어는insert,update,save,remove디폴트에서는, 는 기입을 승인합니다.

2. 그런 문제는 들어본 적이 없다.자신의 실패가 원인인 것 말고는...관계형 시스템에서도 가능합니다.마스터-슬레이브 복제에 대해서만 언급하고 있는 것 같습니다.Replica-sets는 전혀 안정적이지 않습니다.다른 dbms가 오작동으로 인해 데이터 손실을 일으킨 웹 링크도 있습니다.http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-running-oracle-on.html http://bugs.mysql.com/bug.php?id=18014 http://bugs.mysql.com/bug.php?id=18014 (이러한 게시된 링크는 해당 링크에 전혀 유리하지 않습니다.)다른 시스템에도 데이터 손실을 일으킬 수 있는 버그가 있음을 나타내는 것 이외에는 의미가 없습니다.)

3. 네, 실제로는 인스턴스 레벨에 잠금이 있습니다.섀드 환경에서는 글로벌하지 않다고 생각합니다.다른 인스턴스를 잠글 필요가 없기 때문에 섀드별로 인스턴스 레벨로 잠글 필요가 없습니다.향후 버전 2.2는 DB 레벨로 잠기며, Collection Level 티켓은 확장 또는 문서도 존재할 수 있습니다(https://jira.mongodb.org/browse/SERVER-4328)).단, 잠금관리는 비용이 많이 들기 때문에 더 깊은 수준의 잠금은 MongoDB의 실제 성능에 영향을 미칠 수 있습니다.

4. 각 노드에서 몇 개의 청크를 가져와 새 노드로 이동해야 하므로 청크를 이동해도 큰 문제가 발생하지 않습니다.청크의 ping/pong을 발생시키거나 1, 2 청크의 차이만으로 재밸런싱이 시작되는 일은 없습니다.문제가 될 수 있는 것은 샤드 키가 잘못 선택되었을 때입니다.따라서 새로운 엔트리가 모두 아닌1개의 노드에 삽입되는 경우가 있습니다.따라서 문제를 일으킬 수 있는 균형 재조정이 더 자주 나타나지만, 그것은 당신의 잘못된 선택 샤드키보다는 mongo 때문이 아닙니다.

5. 이 건에 대해서는 코멘트할 수 없습니다.

6. 100% 확신할 수는 없지만 1.6에서 소개된 복제본 세트는 데이터 손실을 감수할 수 있는 경우를 제외하고는 프로덕션에서 최신 버전을 사용하지 않는다고 생각합니다.모든 새로운 기능과 마찬가지로 버그가 발생할 가능성이 있습니다.광범위한 테스트에서도 모든 문제가 드러나지 않을 수 있습니다.데이터 손실을 감수할 수 있는 경우를 제외하고는 항상 수동 백업을 실행합니다.

7. 이에 대해 언급할 수 없습니다.그러나 실제로는 소프트웨어에 심각한 버그가 포함되어 있을 수 있습니다.많은 게임들이 이러한 문제를 겪고 있고 바나나 소프트웨어가 꽤 유명하거나 알려진 다른 분야들도 있다.MongoDB 이전이라 구체적인 내용은 코멘트할 수 없습니다.

8. 복제는 이러한 문제를 일으킬 수 있습니다.레플리케이션 전략에 따라서는, 이것이 문제가 되어, 다른 시스템에 적합한 경우가 있습니다.그러나 실제로 쓰기 집약적인 워크로드가 없으면 이러한 문제가 발생하지 않을 수 있습니다.실제로 1개의 마스터에서 3개의 복제 폴링 변경사항이 있는 경우 문제가 발생할 수 있습니다.파편을 더 추가하면 문제를 해결할 수 있습니다.

결론은 다음과 같습니다.네, 그러한 문제가 존재했을지도 모르지만, MongoDB는 이 방향에서 많은 것을 해왔고, 또한 다른 DBMS는 그 문제 자체를 가지고 있지 않았다고 생각합니다.기존의 관계형 DBM을 사용하면 웹 확장성이 뛰어나면 MongoDB, HBase 등의 시스템이 필요하지 않습니다.모든 요구에 맞는 시스템을 얻을 수는 없다.따라서 하나의 단점을 감수하거나 필요한 것을 얻기 위해 여러 시스템을 조합하여 구축해야 합니다.

면책사항:저는 MongoDB나 10gen에 소속된 것이 아니라 MongoDB와 협력하면서 제 의견을 말할 뿐입니다.

언급URL : https://stackoverflow.com/questions/10560834/to-what-extent-are-lost-data-criticisms-still-valid-of-mongodb