안녕하세요? MongoDB Master 주종면입니다.
2012년 초에 외국 기사에 MongoDB애 대한 부정적 기사가 올아왔어죠~
그리고, NoSQL & MongoDB 사용자들 사에 이슈가 많이 되었던 내용이기도 했구요..
아직도, 당시의 기사에 대한 질문을 하시는 분들이 간혹 걔시며 잘못된 오해로 인해 MongoDB 를 적절하게 사용하고 있지 못하는 문제점을 해소하기 위해 이 기사를 올리게 되었습니다.
1. MongoDB의 기본 설정상태로 빅 데이터에 대한 쓰기작업은 안전하지 않다.
애플리케이션 레벨에서 드라이버를 통해 MongoD에 접속할 때 getLastError 함수에 의해 데이터 처리에 대한 성공 여부를 Check하게 되는데 이때 그 결과를 리턴 해 주는 레벨을 Safe 모드라고 하며 처리 결과를 돌려주지 않는 레벨을 Unsafe 모드라고 합니다. 기본 설정 모드는 Unsafe 모드인데 이것은 NoSQL의 대표적인 특징인 초당 몇 만 건의 빅 데이터를 빠르게 쓰기 하기 위함입니다.
만약, 기본 설정 모드를 Safe 모드로 설정하게 된다면 빅 데이터에 대한 쓰기 작업 시 매 건마다 처리 여부를 확인해야 하기 때문에 빠른 쓰기 작업을 수행할 수 없게 될 것 입니다.
만약, 데이터의 무결성이 보장되어야 하는 경우라면 사용자의 선택에 의해 safe 모드를 사용할 수 있으며 다만, 이것은 빠른 쓰기 성능을 지연하게 될 것 입니다.
<결론>
MongoDB의 Write Concern 정책과 빅 데이터를 위한 빠른 쓰기/읽기 솔루션에 대한 이해 부족으로 인한 잘못된 해석으로 판단됩니다..
2. MongoDB 운영 시 다양한 이유로 데이터가 날라가는 경우가 발생한다.
MongoDB 1.8 이전(2011년) 버전에는 Journal 기능이 없어 Memory 영역에 대한Crash 발생하는 경우 백업 데이터가 존재하지 않기 때문에 데이터 유실이 발생하였습니다. 하지만, 이러한 문제를 개선하기 위해 이후 버전에서는 메모리 상에 입력, 수정, 삭제된 데이터는 실 시간으로 Journal 파일에 백업부터 되기 때문에 Memory Crash가 발생하더라도 Journal 파일을 통해 거의 모든 데이터에 대한 복구가 가능하며 최근에는 이러한 사례가 보고되고 있지 않습니다.
<결론>
MoggoDB는 NoSQL 영역에서 아직도 성장하는 기술 중에 하나이므로 몇몇 버그들이 발견되고 있지만 현재 대부분의 관계형 DB에서 발생하는 범주라고 판단됩니다. 1988년 당시 국내 모 신문 기사에는 일부 데이터 유실과 관련된 관계형 데이터베이스의 문제점에 대한 기사들을 종종 볼 수 있었는데 이러한 문제는 시간이 지나면서 자연스럽게 해소되었던 것처럼 현재 버전의 MongoDB에서도 발견되고 있지 않습니다.
3. 빅 데이터 환경에서 써야 할 데이터 양이 많으면 감당하지 못한다.
NoSQL의 대표적인 기술 중에 하나는 Memory Mapping 기술인데 이것은 충분한 시스템 메모리를 요구합니다.
하지만, 대부분의 사용자들은 관계형 데이터베이스 수준의 시스템 메모리 정도로 NoSQL을 운영하고 있으며 빅 데이터를 처리하고 있는 것이 현실입니다.
문제는 이러한 환경에서는 빅 데이터를 효과적으로 처리할 수 없을 뿐만 아니라 오히려 다양한 성능 지연 및 장애 현상을 유발시킬 수 도 있습니다.
관계형 DBMS의 경우에도 부적절한 메모리 할당으로 인한 성능 지연 및 장애가 발생하는 경우 서버 튜닝을 통해 문제 해결을 수행하고 있습니다.
<결론>
대부분의 사용자들은 기술적 기반과 아키텍처 구조가 다른 NoSQL을 RDBMS 관점에서 접근하고 이해하려는 경향들이 있습니다. 이러한 접근 방법으로는 NoSQL 기술을 제대로 이해하고 사용하는 것은 한계가 있을 수 밖에 없습니다.
** 원문에서는 Global Lock으로 인한 쓰기 성능에 대한 이슈를 강조하였는데 이 문제는 2.0 버전에서 Database Lock 매커니즘을 통해 대 부분 해소되었으며 2013년 12월까지 Collection Lock 기능까지 제공하겠다고 발표하였으며 보다 향상된 성능이 기대됩니다.
4. 데이터 분산처리 시스템인 샤딩 환경에서 데이터를 불러올 때 적절한 샤딩이 제대로 작동하지 않을 때가 있다.
MongoDB를 사용하는 대부분의 사용자들은 샤딩 시스템을 구축하는 것 만으로 좋은 성능을 기대할 수 있다고 생각하는 경우들이 종종 있습니다.
하지만, 그렇지 않습니다. 우리나라에는 과유불급이라는 속담이 있습니다.
어떤 좋은 기능이라도 이것을 구축하려는 환경에 적합한지, 구축 시 고려해야 할 사항이 무엇인지, 구축 후 관리 사항에 대한 정확한 기술적 접근과 이해를 바탕으로 구축 여부를 결정하는 것이 올바른 접근 방법입니다.
샤딩이 정상적으로 잘 작동되기 위해서는 몇 가지 전제 조건이 필요합니다.
먼저, 빠른 쓰기 작업에 있어서 Chunk Size와 Shard Key를 적절하게 설계해야 하는데 대부분 사용자들은 단순히 데이터 양적인 측면에서의 분산 저장 정도로 생각하여 단순 설계하기 때문에 결국 좋은 성능이 보장되지 않는 것입니다.
또한, Peak Time에 과도한 마이그레이션이 발생하는 경우 데이터 읽기 작업이 발생한다면 빠른 읽기 및 쓰기 성능이 보장되지 못할 것 입니다.
<결론>
샤딩 및 복제 기술과 DBMS 운영 기술에 대한 이해 부족으로 잘못 운영함으로서
발생했던 문제점으로 판단됩니다, .
5. 데이터 삭제 또는 변경 했을 때 단편화 문제가 발생하여 데이터 처리에 필요 이상의 메모리를 사용합니다.
단편화(Fragmentation) 현상은 모든 파일 시스템 그리고 RDB에서 발생하는 문제점이며 MongoDB 만의 문제점은 아닙니다. 또한, 단편화가 발생한다고 시스템의 메모리룰 사용하는 것은 아니기 때문에 반드시 과 부하가 발생하지는 않습니다.
<결론>
단편화 현상에 대한 이해 부족과 MongoDB 메모리 구조 및 운영 메커니즘애 대한 이해 부족으로 인해 MongoDB 아키테처 구조의 문제점으로 잘못 이해하고 있는 것으로 생각됩니다.
** 원문에서는 mongos 프로세스가 가끔 shutdown 되는 문제에 대한 이슈를 강조하였는데 일반적으로 mongos 프로세스와 유사한 구조는 기존의 관계형 DB 또는 많은 애플리케이션에서도 발생하는 문제점이기도 합니다.
이러한 문제에 대한 원인은 대부분 시스템 메모리 영역과의 Crash에 의해 발생하게 되는데 이 문제점에 대한 대응은 Crash에 대비하여 여러 개의 mongos를 활성화하여 FailOver에 대비해야 합니다.
6. 몽고DB 1.8 이후 버전에서 문제가 해결되었지만 데이터 셋을 전부 날리는 경향이.있습니다.
2) 질문 내용에 대한 답변과 동일함.
7. 몽고 DB에서 발견된 버그가 빨리 해결되지 않는다.
미국의 공인된 평가 기관인 PerfectMarket사의 2011년 발표에 의하면 조사 분석된 NoSQL 제품 중 MongoDB는 버그에 대한 빠른 패치 제공이 이루어지고 있고 커뮤니티에 대한 지원이 가장 좋다는 평가 결과가 있습니다.
2.2 (2012년 초) ？ 2.3 (2012년 말) ？ 2.4 (2013년 3월) ？ 2.5 (2013년 11월)
실제 원문에서 말하려고 했던 것은 문제점에 대한 패치를 즉시 제공하지 않고 다음 릴리즈 버전에서 제공한다는 점을 어필했던 것으로 보입니다.
1.8 버전이 발표되었던 시점에 미국 Funding 마켓에서 NoSQL의 비중에 낮았다면 2011년 이후 급속도로 Funding 투자의 활성화로 자금 유입과 함께 보다 빠른 버그에 대한 대응 및 패치가 제공되고 있는 것으로 판단됩니다.
8. 데이터의 안전한 저장을 위한 복제 시스템이 필요 이상의 서버를 차지한다.
Replication은 빅 데이터를 처리할 때 발생하는 데이터 유실을 방지하기 위한 최후의 수단입니다.
몽고 DB는 ReplicaSets을 통해 여러 대의 서버에 데이터를 복제할 수 있는데 이것은 사용자의 선택이지 필수 조건이 아닙니다. 적절한 시스템 설계를 통해 구현하지 않고 오픈 소스의 장점 만이 부각되어 부 적절하게 구축되는 경우에 해당합니다. 이러한 무절제한 복제가 서버 부하를 유발시키는 것은 당연하며 이것은 모든 NoSQL 뿐만 아니라 관계형 DB에서도 발생합니다.
이 문제를 해결할 수 있는 방법은 MongoDB에서 제공하는 다양한 백업/복구 솔루션과 함께 최소한의 서버로 복제 시스템을 구축하는 것입니다.
<결론>
Replication 시스템 및 운영 메커니즘애 대한 이해 부족으로 판단됩니다.
지금까지 설명된 8가지 사항은 현재 국내 MongoDB 시장에서 사용자 간에 회자되고 있는 MongoDB의 불편한 오해와 진실에 대한 설명이었습니다..
관계형 데이터베이스가 무려 40년이라는 세월 동안 꾸준하게 발전하며 평가 받아온 성숙된 기술이라면 MongoDB는 이제 8년 된 성장하고 있는 기술입니다.
MongoDB의 초기 버전에서 발생했던 몇 가지 문제점들은 상위 버전으로 업그레이드 되면서 많은 발전을 이루어 내었고 이제 안정화 단계로 접어들고 있는 것이 현실입니다. 어떠한 기술이든 초기 버전부터 완벽한 기술과 기능을 제공하는 제품은 없습니다. 많은 사용자의 관심과 지속적인 투자를 통해 사용자의 바램을 충족할 수 있는 기술로 발전하는 것 입니다. 이제 MongoDB는 NoSQL 분야에서 선택될 수 밖에 없는 기술로 평가 받고 있고 사용자의 관심을 끌고 있습니다. 앞서 소개 드린 MongoDB의 불편한 오해를 말끔히 털어내시고 여러분의 비즈니스 분야에 MongoDB를 적극적으로 활용해 보시기를 권장합니다.
감사합니다.
댓글 없음:
댓글 쓰기