MongoDB 대 Cassandra

MongoDB 대 Cassandra

---

가장 좋은 마이그레이션 옵션이 무엇인지 평가 중입니다.

현재 저는 대부분의 데이터가 JSON blob에 저장된 샤딩 된 MySQL (수평 파티션)을 사용하고 있습니다. 복잡한 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을 사용하여 데이터를 저장한다는 점을 감안할 때 사용 사례에 매우 적합합니다. 현재 데이터베이스에서보다 더 풍부하고 쿼리 가능한 데이터를 가질 수 있습니다. 이것은 Mongo에게 가장 중요한 승리가 될 것입니다.

---

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

나는 Cassandra가 트위터와 같은 대규모 프로젝트에서 사용되기 때문에 MongoDB 팀이 패리티를 위해 작업하고 있지만 더 나은 확장 기능을 가지고 있다고 생각합니다. 나는 시운전 단계 이상으로 카산드라를 사용하지 않았기 때문에 세부 사항에 대해 말할 수 없다는 점을 지적해야한다.

NoSQL 데이터베이스를 평가할 때 저에게 진정한 스윙 어는 쿼리였습니다. Cassandra는 기본적으로 거대한 키 / 값 저장소 일 뿐이며 쿼리는 (적어도 MongoDB에 비해) 약간 까다롭기 때문에 성능을 위해서는 다음을 수행해야합니다. 일종의 수동 색인으로 상당히 많은 데이터를 복제합니다. 반면에 MongoDB는 "예제 별 쿼리"모델을 사용합니다.

예를 들어, 사용자가 포함 된 컬렉션 (RDMS 테이블에 해당하는 MongoDB 용어)이 있다고 가정합니다. MongoDB는 레코드를 기본적으로 바이너리 JSON 객체 인 문서로 저장합니다. 예 :

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

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

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

... 그런 다음 쿼리를 실행합니다. 그게 다야. 비교, RegEx 필터링 등을위한 연산자가 추가되었지만 모두 매우 간단하며 Wiki 기반 문서도 꽤 좋습니다.

---

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

NoSQL datastores generally scale way better than a traditional DB for the same otherwise specs -- there is a reason why Facebook, Twitter, Google, and most start-ups are using NoSQL solutions. It's not just geeks getting high on new tech.

---

I'm probably going to be an odd man out, but I think you need to stay with MySQL. You haven't described a real problem you need to solve, and MySQL/InnoDB is an excellent storage back-end even for blob/json data.

There is a common trick among Web engineers to try to use more NoSQL as soon as realization comes that not all features of an RDBMS are used. This alone is not a good reason, since most often NoSQL databases have rather poor data engines (what MySQL calls a storage engine).

Now, if you're not of that kind, then please specify what is missing in MySQL and you're looking for in a different database (like, auto-sharding, automatic failover, multi-master replication, a weaker data consistency guarantee in cluster paying off in higher write throughput, etc).

---

I haven't used Cassandra, but I have used MongoDB and think it's awesome.

If you're after simple setup, this is it: You simply untar MongoDB and run the mongod daemon and that's it ... it's running.

Obviously that's only a starter, but to get you started it's easy.

---

I saw a presentation on mongodb yesterday. I can definitely say that setup was "simple", as simple as unpacking it and firing it up. Done.

I believe that both mongodb and cassandra will run on virtually any regular linux hardware so you should not find to much barrier in that area.

I think in this case, at the end of the day, it will come down to which do you personally feel more comfortable with and which has a toolset that you prefer. As far as the presentation on mongodb, the presenter indicated that the toolset for mongodb was pretty light and that there werent many (they said any really) tools similar to whats available for MySQL. This was of course their experience so YMMV. One thing that I did like about mongodb was that there seemed to be lots of language support for it (Python, and .NET being the two that I primarily use).

The list of sites using mongodb is pretty impressive, and I know that twitter just switched to using cassandra.

참고URL : https://stackoverflow.com/questions/2892729/mongodb-vs-cassandra