무엇을 선택해야하나요 : MongoDB / Cassandra / Redis / CouchDB?

무엇을 선택해야하나요 : MongoDB / Cassandra / Redis / CouchDB?

---

우리는 정말 큰 프로젝트를 개발하고 있는데, 우리가 어떤 DB 백엔드를 선택해야하는지에 대해 누군가 나에게 조언을 해줄 수 있는지 궁금합니다.

우리의 시스템은 중앙 서버로 신호를 전송 한 다음 서버가 신호 정보를 저장하는 1100 개의 전자 장치로 구성되어 있습니다 (신호 길이는 약 35 바이트). 이러한 장치는 분당 약 3 개의 신호를 전송하므로 숫자를 지정하면 데이터베이스에 하루 4.752.000 개의 새 레코드가 있고 월별 총 142.560.000 개의 새 레코드가됩니다.

빠르고 안정적인 조명 DB 백엔드가 필요합니다. 물론 해당 DB에서 복잡한 데이터 마이닝을 수행해야합니다. 우리는 MongoDB / Cassandra / Redis / CouchDB에 대해 약간의 연구를하고 있지만 문서 웹 사이트는 아직 초기 단계에 있습니다.

도움이 필요하세요? 아이디어?

감사합니다!

---

공간적 규모 (1000 개 이상의 장치)가 계산 및 / 또는 스토리지 규모에 대해 오해하지 않도록하십시오. 초당 수십 개의 35 바이트 삽입은 저가형 하드웨어에서 실행되는 경우에도 모든 주류 DBMS에 대한 사소한 워크로드입니다. 마찬가지로 한 달에 1 억 4,200 만 개의 레코드가 인덱스를 포함하여 압축없이 월 1 ~ 10 기가 바이트 정도만 저장됩니다.

귀하의 질문 댓글에서 다음과 같이 말했습니다.

"모든 것은 안정성, 확장 성 및 속도에 관한 것입니다. 솔루션을 쉽게 확장 (MongoDB 자동 샤딩?)하는 것이 매우 중요하며 더 많은 노드를 추가하는 것이 중요하며 속도도 매우 중요합니다.

신뢰할 수 있음? 모든 주류 DBMS는이를 보장 할 수 있습니다 (데이터가 손상되지 않고 충돌하지 않을 것이라는 가정하에이 답변의 맨 아래에있는 CAP 정리에 대한 논의를 참조하십시오). 속도? 한 대의 기계라도이 작업량의 10 ~ 100 배는 문제가되지 않습니다. 확장 성? 현재 속도로 볼 때 압축되지 않은, 심지어 완전히 인덱싱 된 1 년의 데이터는 100GB의 디스크 공간에 쉽게 맞을 것입니다 (마찬가지로 삽입 속도는 문제가되지 않음).

따라서 NoSQL과 같은 이국적인 솔루션이나 심지어 분산 데이터베이스에 대한 명확한 필요성은 보이지 않습니다. MySQL과 같은 평범하고 오래된 관계형 데이터베이스는 괜찮을 것입니다. 장애 조치가 걱정된다면 마스터-슬레이브 구성에서 백업 서버를 설정하기 만하면됩니다. 현재 규모의 100 배 또는 1000 배에 해당하는 경우 데이터 수집 장치의 ID를 기반으로 몇 개의 인스턴스를 수평으로 분할합니다 ( 예 : {partition index} = {device id} modulo {number of partitions}).

관계형 데이터베이스 세계의 안전하고 편한 경계를 벗어나는 것은 표현 모델 과 풍부한 도구 세트를 모두 버리는 것을 의미 합니다. 이렇게하면 "복잡한 데이터 마이닝"이 훨씬 더 어려워집니다. 데이터를 데이터베이스에 넣을 필요가없고 가져와야합니다.

이 모든 것을 말하면 MongoDB와 CouchDB는 배포 및 작업이 매우 간단합니다. 그들은 또한 매우 재미 있고 많은 사람들에게 당신을 더 매력적으로 만들 것입니다 (프로그래머뿐만 아니라 경영진도!).

일반적인 상식은 귀하가 제안한 세 가지 NoSQL 솔루션 중 Cassandra가 높은 삽입 볼륨에 가장 적합하다는 것입니다 (물론 상대적으로 삽입 볼륨 이 높지 않다고 생각합니다. Facebook에서 사용하도록 설계되었습니다 ). ; 이것은 작업하기가 더 어렵 기 때문에 대응됩니다. 따라서 언급하지 않은 이상한 요구 사항이 없으면 사용 사례에 대해 반대하는 것이 좋습니다.

NoSQL 배포를 적극적으로 설정했다면 CAP 정리를 고려할 수 있습니다. 이것은 MongoDB와 CouchDB 중 하나를 결정하는 데 도움이됩니다. 다음은 좋은 링크입니다. http://blog.nahurst.com/visual-guide-to-nosql-systems . 모든 것이 "신뢰성"이라는 의미로 귀결됩니다 . MongoDB는 일관성을 위해 가용성을 거래하는 반면 CouchDB는 가용성을 위해 일관성을 거래 합니다. (Cassandra를 사용하면 쓰기 / 읽기가 성공하기 위해 작성 / 읽어야하는 서버 수를 지정하여 쿼리 당이 절충안 을 미세 조정할 수 있습니다. 업데이트 : 이제 BigCouch 와 함께 CouchDB도 가능합니다 ! 매우 흥미 롭습니다 ...)

프로젝트에서 행운을 빕니다.

---

대부분의 답변은 수집 된 후 원하는 작업에 따라 달라집니다. 많은 양의 데이터를 저장하는 것은 쉽습니다. 데이터베이스가 필요없이 로그 파일에 더하기 만하면됩니다. 반면에 복잡한 분석 및 데이터 마이닝을 수행하려면 데이터베이스가 유용합니다.

다음 질문은 어떤 종류의 분석을 할 것인지입니다. 특정 속성이있는 데이터의 하위 집합 (지난 시간 / 일 / 주 / 월)에 대해서만 수행됩니까? 데이터를 집계 할 수 있습니까? 아니면 미리 계산할 수 있습니까? 즉, 수집 된 형식의 전체 데이터 세트에 액세스해야합니까? 너무 오래되어 흥미롭지 않을 때 데이터를 보관할 수 있습니까? 데이터를 집계하고 집계에 대한 분석을 수행 할 수 있습니까?

광고 분석 (광고 노출에 대한 수십억 개의 데이터 포인트 수집) 작업을 통해 얻은 경험상 집계가 핵심입니다. 원시 데이터를 수집하고 삭제 한 다음 MongoDB, Cassandra 또는 MySQL과 같은 데이터베이스에 저장하여 업데이트 및 쿼리를 수행 할 수 있습니다. 그런 다음 주기적으로 데이터를 집계하고 데이터베이스에서 제거합니다 (하지만 원시 데이터는 보관하지만 나중에 필요할 수 있음).

집계는 기본적으로 데이터에 대해 묻고 싶은 모든 질문을하고 특정 질문에 대한 답을 쉽게 검색 할 수있는 양식으로 저장합니다. 어떤 요일에 X가 가장 많은지 알고 싶다고 가정 해 봅시다. 이것의 순진한 구현은 기록 된 모든 신호를 거대한 테이블에 보관하고 X가있는 모든 행을 합산하는 쿼리를 수행하는 것입니다. 수집 된 수로 신호 증가이 쿼리는 더 오래 걸립니다. 인덱싱, 샤딩 또는 최적화의 양은 이에 도움이되지 않습니다. 대신 매일 / 시간 / 분 (정확한 사용 사례 및보고해야하는 최신 정보에 따라 다름) 기록한 새로운 신호를 확인하고 X마다 얼마나 많은 신호를 추적하는지 카운터를 증가시킵니다. X 월요일이면 월요일, 화요일이면 화요일 등등. 이렇게하면 나중에 각 요일의 개수를 검색하고 비교할 수 있습니다. 답할 수있는 모든 질문에 대해이 작업을 수행 한 다음 데이터베이스에서 신호를 제거합니다 (하지만 원시 데이터는 유지).

집계를 기록하는 데이터베이스 유형은 수신 신호를 저장하는 것과 동일 할 수 있지만 매우 화려할 필요는 없습니다. 특정 답을 나타내는 키와 일반적으로 숫자에 불과한 값을 저장합니다.

구식 데이터웨어 하우징에서는 들어오는 신호를 저장하는 데이터베이스를 OLTP (온라인 트랜잭션 처리 용)라고하고 집계를 저장하는 데이터베이스를 OLAP (온라인 분석 처리 용)라고합니다. OLTP는 삽입에 최적화되어 있고 OLAP는 쿼리에 최적화되어 있습니다. 용어는 오래되었고 사람들이이 용어를들을 때 즉시 SQL과 스타 스키마 등을 생각하는 경향이 있습니다. 사용하지 말아야 할 것 같지만 편리한 용어입니다.

어쨌든, OLTP의 경우 데이터를 빠르게 삽입 할 수있을뿐만 아니라 데이터 인덱싱 및 검색을 지원하는 것을 원합니다. 집계는 최대 값과 최소값을 더하고 찾는 작업의 절반을 수행하는 데이터베이스에 의해 크게 도움이됩니다. MongoDB는 설정 및 작업이 매우 쉽기 때문에 정말 좋아합니다. 내가 작업하는 데이터는 지저분하고 모든 항목이 동일한 속성 집합을 갖는 것은 아니므로 Mongo의 관용적 인 스키마리스는 장점입니다. 반면에 데이터는 훨씬 더 균일하게 들리므로 Mongo는 많은 이점을 제공하지 않을 것입니다. 그래도 좋은 오래된 관계형 데이터베이스를 간과하지 마십시오. 많은 합산 등을 수행하려는 경우 SQL이 훌륭합니다. 이것이 바로 SQL입니다.

훨씬 간단한 OLAP의 경우 키-값 저장소 만 있으면됩니다. Redis를 사용하는 이유는 작업 및 설정이 매우 쉽기 때문입니다. 또한 스칼라 값 이상을 저장할 수 있으므로 편리합니다. 때로는 값이 실제로 목록 또는 해시 인 경우가 있습니다. 대부분의 키-값 저장소에서 이러한 값을 인코딩해야하지만 Redis가 기본적으로 처리합니다. Redis의 단점은 쿼리를 수행 할 수 없다는 것입니다 ( "Y에 대해이 값이있는 모든 행을 제공"). 데이터에 대한 인덱스를 직접 유지해야합니다. 반면에 모든 질문에 대한 답변이 미리 계산되어 있기 때문에 인덱스가 많이 필요하지 않습니다. 질문에 정의 된 키로 답변을 조회하기 만하면됩니다. 위의 질문에서 X가 가장 많은 요일은 월요일, 화요일 등의 X 작업 수를 조회합니다.

결론 : MongoDB와 Redis는 저에게 잘 맞습니다. MongoDB가 사용 사례에 적합하지 않다고 생각합니다. 대신 기존 SQL 데이터베이스에서 더 많은 이점을 얻을 수 있다고 생각합니다 (하지만 데이터가 정말 간단하다면 Redis를 끝까지 사용할 수 있다는 점에 따라 다릅니다). 가장 중요한 것은 데이터를 하나의 데이터베이스에 보관하고 영원히 보관해야한다고 생각하는 실수를하지 않는 것입니다. 집계 및 오래된 데이터 버리는 것이 핵심입니다.

---

CouchDB는 매우 안정적이며 뛰어난 내구성을 제공하며 CPU 부하가 매우 낮습니다. 또한 주문형 또는 지속적으로 여러 노드간에 복제하는 데 탁월합니다.

Thanks to its replication abilities and RESTful API (it uses HTTP for its API) you can scale horizontally pretty easily using mature tools. (Nginx or Apache for reverse proxying, HTTP load balancers, etc.)

You write map/reduce functions in JavaScript to precompute queries. The results are built up incrementally on disk which means they only neeed to be computed once per signal. In other words, queries can be really fast because it only has to do calculations on the signal data recorded since the last time you ran the query.

CouchDB trades disk space for performance, so you can expect to use a lot of disk space. Your queries can be lightning fast and conserve disk space if you implement them properly.

Give CouchDB a try.

Check out Why Large Hadron Collider Scientists are Using CouchDB and CouchDB at the BBC as a fault tolerant, scalable, multi-data center key-value store

---

~3000 signals/minute = 50 writes/s which any of these systems will be able to handle easily.

Cassandra will probably work best as your data set grows larger than memory, though, and the Hadoop integration will help with your data mining.

---

So you are storing data in a central db for datamining? No online transaction processing?

I don't think that MongoDB does a good job when it comes to durability. See http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of .

Maybe you can use analytics db Infobright, it has a community edition: http://www.infobright.org/ ?

---

You are looking for a datastore that can allow "lightning fast" writes (data persisted on disk), and the data-mining will occur at a later stage (this is the READ cycle). Also, considering the numbers you state, it turns out you will collect all of 159MB of information per day, or approx 5GB per month.

In this case, why not look at Redis.

You could always archive the daily Redis data file, and refer to it later (if you have concerns of loading 5GB or greater amount of RAM space, then you this archiving could be a workaround)

Redis is rather fast, based on the numbers published on that site. Hope this helps. Kiran

---

I've used MongoDB from Incanter and have liked it. Although I can't speak to the speed with such large datasets, Clojure (which Incanter is based on) is very reliable in terms of transaction management. Incanter also provides some great analysis tools, so if you're planning on analyzing all of that data, MongoDB + Incanter could be a powerful combination.

---

If you're liking the look of Cassandra for its designed-from-the-start ability to scale horizontally, tune consistency against availability and such, then you may also want to look at Riak, which has a similar feature set but a different approach.

참고URL : https://stackoverflow.com/questions/3478916/what-should-i-choose-mongodb-cassandra-redis-couchdb