MongoDB와카산드라
최적의 이행 옵션을 검토하고 있습니다.
현재 저는 Sharded MySQL(수평 파티션)에 있으며 대부분의 데이터는 JSON blobs에 저장되어 있습니다.복잡한 SQL 쿼리는 없습니다(DB 파티션 분할 후 이미 이행되어 있습니다).
현재로선 MongoDB와 Cassandra 둘 다 선택사항이 될 것 같습니다.내 상황:
- 모든 쿼리에서 많은 읽기, 규칙적인 쓰기 감소
- '대규모' 확장성 걱정 없음
- 심플한 셋업, 유지보수, 코드에 대한 배려
- 하드웨어/서버 비용 최소화
모든 쿼리에서 많은 읽기, 정기적인 쓰기 감소
두 데이터베이스 모두 메모리에 핫 데이터 세트가 들어맞는 읽기 작업에 적합합니다.또한 둘 다 조인리스 데이터 모델을 강조하며(대신 정규화를 장려한다), MongoDB의 인덱스는 현재 보다 유연하지만 둘 다 문서 또는 행에 인덱스를 제공합니다.
Cassandra의 스토리지 엔진은 데이터 세트가 아무리 커지더라도 지속적인 쓰기 기능을 제공합니다.쓰기는 MongoDB에서 더 문제가 되는데, 부분적으로 B-Tree 기반 스토리지 엔진 때문이기도 하지만 다중 입도 잠금 기능이 있기 때문입니다.
분석을 위해 MongoDB는 맞춤형 맵/축소 구현을 제공합니다. Cassandra는 Hive(Hadoop 맵/축소를 기반으로 구축된 SQL 데이터 웨어하우스) 및 Pig(Hadoop 전용 분석 언어)를 포함하여 기본 Hadoop 지원을 제공합니다.카산드라는 스파크 사용도 지원합니다.
'대규모' 확장성 걱정 없음
단일 서버를 사용한다면 MongoDB가 더 적합할 수 있습니다.확장에 관심이 많은 고객에게 Cassandra의 싱글 포인트 오브 에러 아키텍처는 셋업이 간단하고 신뢰성이 높아집니다.(MongoDB의 글로벌 쓰기 잠금도 문제가 되는 경향이 있습니다.)또, Cassandra는, 복수의 데이터 센터에 대한 서포트 등, 레플리케이션의 동작에 대해서도 보다 많은 제어를 실시합니다.
심플한 셋업, 유지보수, 코드에 대한 배려
둘 다 셋업이 간단하며, 1대의 서버에 대해 즉시 사용할 수 있는 합리적인 기본값입니다.Cassandra는 특별한 역할 노드가 없기 때문에 멀티 서버 구성에서 설정하기가 더 쉽습니다.
현재 JSON Blobs를 사용하고 있다면 BSON을 사용하여 데이터를 저장하는 MongoDB는 사용 사례에 매우 적합합니다.현재 데이터베이스보다 더 풍부하고 쿼리 가능한 데이터를 가질 수 있습니다.이것은 몽고에게 가장 중요한 승리가 될 것이다.
지난 6개월 동안 MongoDB를 광범위하게 사용하여 계층형 데이터 관리 시스템을 구축했습니다.또한 셋업의 용이성(설치, 실행, 사용!)과 속도도 보증할 수 있습니다.인덱스에 대해 주의 깊게 생각하는 한, 인덱스는 확실히 고속으로 따라갈 수 있습니다.
Cassandra는 Twitter와 같은 대규모 프로젝트에서 사용하기 때문에 MongoDB 팀이 그곳에서 동등하게 작업하고 있지만 스케일링 기능이 더 우수하다고 생각합니다.시운전 단계 이후로는 카산드라를 사용하지 않았기 때문에 자세한 내용은 말씀드릴 수 없습니다.
NoSQL 데이터베이스를 평가할 때 저에게 있어 가장 큰 변화는 쿼리였습니다. Cassandra는 기본적으로 거대한 키/값 저장소일 뿐이며, 쿼리는 약간 불안정하기 때문에(적어도 MongoDB와 비교), 성능을 위해 수동 인덱스의 형태로 많은 데이터를 복제해야 합니다.반면 MongoDB는 "예시로 쿼리" 모델을 사용합니다.
예를 들어 사용자를 포함하는 컬렉션(RDMS 테이블에 해당하는 MongoDB 용어)이 있다고 가정합니다.MongoDB는 기본적으로 이진 JSON 개체인 Documents로 레코드를 저장합니다.예:
{
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 데이터스토어는 일반적으로 동일한 사양의 기존 DB보다 훨씬 더 잘 확장됩니다. Facebook, Twitter, Google 및 대부분의 스타트업에서 NoSQL 솔루션을 사용하는 데는 이유가 있습니다.단순히 괴짜들이 새로운 기술에 열광하는 것만이 아닙니다.
난 아마 이상한 사람이 될 거야 하지만 넌 MySQL에 머물러야 할 것 같아MySQL/InnoDB는 BLOB/json 데이터에도 뛰어난 스토리지 백엔드입니다.
웹 엔지니어들 사이에서는 RDBMS의 모든 기능이 사용되지 않는다는 것을 깨닫자마자 NoSQL을 더 많이 사용하려고 하는 공통적인 요령이 있습니다.대부분의 NoSQL 데이터베이스는 데이터 엔진(MySQL이 스토리지 엔진이라고 부르는 것)이 다소 불량한 경우가 많기 때문에 이것만으로는 충분하지 않습니다.
이러한 유형이 아닌 경우 MySQL에서 찾을 수 없는 항목과 다른 데이터베이스(자동 샤딩, 자동 페일오버, 멀티 마스터 복제, 높은 쓰기 처리량에서 얻을 수 있는 클러스터의 데이터 일관성 저하 등)를 지정하십시오.
Cassandra는 써본 적이 없지만 MongoDB는 써봤는데 대단하다고 생각해요.
간단한 셋업을 하고 싶다면, 바로 이것입니다.MongoDB를 언타래하고 mongod 데몬을 실행하면 끝입니다.달리고 있어요
물론 이것은 시작에 불과하지만, 시작하기란 쉬운 일입니다.
어제 mongodb에서 발표를 봤어요.포장을 풀고 기동하는 것만으로 간단하게 셋업이 「심플」이라고 말할 수 있습니다.다 했어요.
저는 mongodb와 cassandra 모두 거의 모든 일반 Linux 하드웨어에서 실행되므로 그 영역에서 큰 장벽을 발견하지 못할 것이라고 생각합니다.
이 경우, 결국 개인적으로 어느 쪽이 더 편하고, 어느 쪽이 원하는 도구 세트를 가지고 있는지로 귀결될 것이라고 생각합니다.mongodb에 관한 프레젠테이션에서 발표자는 mongodb용 툴셋이 매우 가볍고 MySQL과 유사한 툴이 많이 있다고 말했습니다.이것은 물론 그들의 경험이었기 때문에 YMMV입니다.제가 mongodb에 대해 좋아했던 것 중 하나는 mongodb에 대한 언어 지원이 많은 것 같다는 것입니다(Python, 및).주로 사용하는 것은 NET입니다).
mongodb를 사용하는 사이트 목록은 매우 인상적이며, 트위터가 방금 cassandra를 사용하는 것으로 전환한 것으로 알고 있습니다.
언급URL : https://stackoverflow.com/questions/2892729/mongodb-vs-cassandra
'programing' 카테고리의 다른 글
| springboot embedded tomcat 및 tomcat- (0) | 2023.03.16 |
|---|---|
| 스프링 테스트에서 보안되지 않은 URL에 대해 401 반환 (0) | 2023.03.16 |
| 끌어서 놓기 정렬 가능한 ng:AngularJs에서 반복하시겠습니까? (0) | 2023.03.16 |
| Java에서의 JSON 문자열 해석 (0) | 2023.03.11 |
| AngularJS 시드: JavaScript를 별도의 파일(app.js, controllers.js, directives.js, filters.js, services.js)에 저장합니다. (0) | 2023.03.11 |