MongoDB vs. 카산드라 [닫기]

최고의 마이그레이션 옵션이 무엇인지 평가하고 있습니다.

현재 샤드 MySQL (수평 파티션)을 사용하고 있으며 대부분의 데이터는 JSON blob에 저장되어 있습니다. 복잡한 SQL 쿼리가 없습니다 (DB를 파티션 한 이후 이미 마이그레이션되었습니다).

지금은 MongoDB와 Cassandra가 모두 옵션 일 것 같습니다. 내 상황 :

• 모든 쿼리에서 많은 읽기, 덜 정기적 인 쓰기
• "대규모"확장성에 대해 걱정하지 않음
• 간단한 설정, 유지 관리 및 코드에 대해 더 걱정
• 하드웨어 / 서버 비용 최소화

모든 쿼리에서 많은 양의 읽기, 적은 정기적 인 쓰기

두 데이터베이스 모두 핫 데이터 세트가 메모리에 적합한 읽기에서 잘 수행됩니다. MongoDB의 인덱스가 현재 더 유연하지만 둘 다 조인없는 데이터 모델을 강조하고 대신 비정규 화를 권장하고 문서 또는 행 에 인덱스를 제공합니다 .

Cassandra의 스토리지 엔진은 데이터 세트가 아무리 커지더라도 일정한 시간 쓰기를 제공합니다. MongoDB에서는 쓰기가 더 문제가됩니다. 부분적으로 b- 트리 기반 스토리지 엔진 때문이지만 다중 단위 잠금 때문에 발생합니다.

MongoDB는 분석을 위해 맞춤형 맵 / 감소 구현을 제공합니다. Cassandra는 Hive (Hadoop 맵 / 리 듀스에 구축 된 SQL 데이터웨어 하우스) 및 Pig (많은 사람들이 SQL보다 맵 / 리덕션 워크로드에 더 적합하다고 생각하는 Hadoop 특정 분석 언어)를 포함하여 기본 Hadoop 지원을 제공합니다 . Cassandra는 Spark 사용도 지원합니다 .

"대규모"확장성에 대해 걱정하지 않음

단일 서버를보고 있다면 MongoDB가 더 적합 할 것입니다. 확장에 더 관심이있는 사람들을 위해 Cassandra의 단일 실패 지점 아키텍처는 설정이 쉽고 안정적입니다. (MongoDB의 전역 쓰기 잠금도 더욱 고통스러워지는 경향이 있습니다.) Cassandra는 여러 데이터 센터 지원을 포함하여 복제 작동 방식을 훨씬 더 많이 제어 할 수 있습니다.

간단한 설정, 유지 관리 및 코드에 대해 더 걱정

둘 다 설정하기가 쉽지 않으며 단일 서버에 대해 기본적으로 적합한 기본값이 있습니다. Cassandra는 걱정할 특수 역할 노드가 없기 때문에 다중 서버 구성에서 설정하는 것이 더 간단합니다.

현재 JSON Blob을 사용하고 있다면 MongoDB는 BSON을 사용하여 데이터를 저장한다는 점에서 유스 케이스에 매우 적합합니다. 현재 데이터베이스보다 더 풍부하고 쿼리 가능한 데이터를 가질 수 있습니다. 이것은 몽고에게 가장 중요한 승리입니다.

나는 계층 적 데이터 관리 시스템을 구축하면서 MongoDB를 광범위하게 (지난 6 개월 동안) 사용했으며, 설치의 용이성 (설치, 실행, 사용!)과 속도를 모두 보증 할 수있다. 인덱스에 대해 신중하게 생각하는 한 절대 속도로 비명을지를 수 있습니다.

MongoDB 팀이 패리티를 위해 노력하고 있지만 Cassandra는 Twitter와 같은 대규모 프로젝트에서 사용하기 때문에 더 나은 확장 기능을 가지고 있습니다. 시험 실행 단계 이후에 카산드라를 사용하지 않았으므로 세부 사항을 말할 수는 없습니다.

우리가 NoSQL 데이터베이스를 평가할 때 실제 스윙 어는 쿼리였습니다. Cassandra는 기본적으로 거대한 키 / 값 저장소이며 쿼리는 약간 이상합니다 (최소한 MongoDB와 비교). 따라서 성능을 위해서는 일종의 수동 색인으로 많은 양의 데이터를 복제하십시오. 반면에 MongoDB는 "query by example"모델을 사용합니다.

예를 들어 Users가 포함 된 Collection (RDMS 테이블과 동등한 몽고 DB 용어)이 있다고 가정합니다. MongoDB는 기본적으로 바이너리 JSON 객체 인 Documents로 레코드를 저장합니다. 예 :

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

관리자 권한이있는 Smith라는 모든 사용자를 찾으려면 Javascript를 사용하여 관리 콘솔에서 또는 선택한 언어를 사용하여 프로덕션에서 새 문서를 작성하면됩니다.

{
   LastName: "Smith",
   Groups: "Admin"
}

... 그리고 쿼리를 실행하십시오. 그게 다야. 비교, RegEx 필터링 등을위한 추가 연산자가 있지만 모두 매우 간단하며 위키 기반 문서는 매우 좋습니다.

기존 데이터베이스와 NoSQL 데이터 저장소 중에서 선택해야하는 이유는 무엇입니까? 둘 다 사용하십시오! 초기 학습 곡선 이외의 NoSQL 솔루션의 문제점은 트랜잭션이 부족하다는 것입니다. MySQL에 대한 모든 업데이트를 수행하고 MySQL이 NoSQL 데이터 저장소에 읽기를 수행하도록하면 각 기술의 장점을 활용할 수 있습니다. 이것은 더 복잡해 지지만 이미 MySQL 쪽이 있습니다 .MongoDB, Cassandra 등을 믹스에 추가하십시오.

NoSQL 데이터 스토어는 일반적으로 동일한 사양으로 기존 DB보다 확장 성이 뛰어납니다. Facebook, Twitter, Google 및 대부분의 신생 기업이 NoSQL 솔루션을 사용하는 이유가 있습니다. 새로운 기술에 관심을 가진 사람들은 아닙니다.

아마 이상한 사람이 될지 모르지만 MySQL을 유지해야한다고 생각합니다. 실제로 해결해야 할 실제 문제에 대해서는 설명하지 않았으며, MySQL / InnoDB는 BLOB / JSON 데이터에도 탁월한 스토리지 백엔드입니다.

RDBMS의 모든 기능이 사용되는 것이 아니라는 사실을 깨닫 자마자 웹 엔지니어들에게 더 많은 NoSQL을 사용하려고하는 일반적인 트릭이 있습니다. 대부분의 NoSQL 데이터베이스에는 데이터 엔진 (MySQL이 스토리지 엔진이라고 함)이 열악하기 때문에, 이것만으로는 좋은 이유가 아닙니다.

이제 그런 종류가 아닌 경우 MySQL에서 누락 된 것을 지정 하고 다른 데이터베이스 (예 : 자동 샤딩, 자동 장애 조치, 다중 마스터 복제, 약한 데이터 일관성 보장)를 찾고 있습니다 더 높은 쓰기 처리량 등으로 클러스터 지불

나는 Cassandra를 사용하지 않았지만 MongoDB를 사용했으며 훌륭하다고 생각합니다.

간단한 설정을 마치면 다음과 같습니다. MongoDB를 untar하고 mongod 데몬을 실행하면 바로 실행됩니다.

분명히 그것은 시작에 불과하지만 시작하기는 쉽습니다.

나는 어제 mongodb에 관한 프리젠 테이션을 보았다. 나는 포장을 풀고 발사하는 것처럼 간단하게 셋업이 "간단한"것이라고 말할 수있다. 끝난.

mongodb와 cassandra는 거의 모든 일반 Linux 하드웨어에서 실행되므로 해당 영역에서 많은 장벽을 찾아서는 안됩니다.

나는이 경우 하루가 끝날 때 개인적으로 더 편안하게 느끼고 선호하는 툴 세트가 있다고 생각합니다. mongodb에 대한 프레젠테이션에서 발표자는 mongodb의 툴셋이 매우 가벼우 며 MySQL에서 사용할 수있는 툴과 유사한 툴이 거의 없었습니다. 이것은 물론 YMMV의 경험이었습니다. mongodb에 대해 좋아했던 것 중 하나는 많은 언어 지원이있는 것 같습니다 (Python 및 .NET이 주로 사용하는 두 가지입니다).

mongodb를 사용하는 사이트 목록은 매우 인상적 이며 트위터가 cassandra를 사용하도록 전환 한 것을 알고 있습니다.