2010-08-13 2 views
70

우리는 정말 큰 프로젝트를 개발하고 있으며, DB 백엔드가 어떤 것을 선택해야하는지 누군가가 조언을 해줄 수 있는지 궁금합니다.내가 선택할 수있는 항목 : MongoDB/Cassandra/Redis/CouchDB?

우리 시스템은 중앙 서버에 신호를 보내고 신호 정보를 저장하는 1100 전자 장치에 의해 합성됩니다 (신호는 약 35 바이트 길이입니다). 이 장치는 분당 3 개의 신호를 각각 어떻게 전송할 것인가? 그래서 우리가 숫자를하면 데이터베이스에 하루에 4.752.000 개의 새 레코드가 생기고 총 142.560,000 개의 새로운 레코드/월이됩니다.

우리는 빠르고 신뢰성있는 DB 백엔드가 필요합니다. 물론 우리는 DB에서 복잡한 데이터 마이닝을해야합니다. 우리는 MongoDB/Cassandra/Redis/CouchDB에 대한 연구를하고 있지만, 문서화 웹 사이트는 아직 초기 단계에 있습니다.

어떤 도움이 필요합니까? 아이디어?

고맙습니다.

+2

그럼 선택 기준은 무엇입니까? db가 얼마나 빠릅니까? 특정 기능을 찾으십니까? 이 질문은 매우 모호합니다. –

+0

그것은 모두 신뢰성, 확장 성 및 속도에 관한 것입니다. 솔루션이 쉽게 확장되는 것은 매우 중요합니다. (MongoDB autosharding?) 더 많은 노드를 던지면 속도 또한 매우 중요합니다. – Juanda

+1

관련 상품 http://stackoverflow.com/questions/2892729/mongodb-vs-cassandra/2894665#2894665 –

답변

2

저는 MongoDB를 Incanter에서 사용했고 그것을 좋아했습니다. Clojure (Incanter가 기반으로하는)와 같은 대규모 데이터 세트의 속도는 말할 것도 없지만 트랜잭션 관리 측면에서 매우 신뢰할 수 있습니다. Incanter는 훌륭한 분석 도구를 제공하기 때문에 MongoDB + Incanter는 모든 데이터를 분석 할 계획이라면 강력한 조합이 될 수 있습니다.

+1

Clojure는 데이터베이스 트랜잭션이 아니라 소프트웨어 트랜잭션 메모리 *를 기본적으로 지원합니다. – user359996

4

데이터 마이닝을 위해 중앙 DB에 데이터를 저장하고 있습니까? 온라인 거래 처리가 없습니까?

MongoDB는 내구성면에서 좋은 직장이라고 생각하지 않습니다. http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of을 참조하십시오.

아마도 analytics db Infobright를 사용할 수 있습니다. 커뮤니티 버전이 http://www.infobright.org/입니까?

+0

답장을 보내 주셔서 감사합니다. 데이터 마이닝을위한 저장 만 온라인 트랜잭션 처리가 필요하지 않습니다. 나는 infobright를 체크 아웃하고 알려 드리겠습니다. – Juanda

2

카사 드라의 디자인을 처음부터 디자인했기 때문에 수평 확장이 가능하고 가용성과 일관성을 유지할 수 있다면 비슷한 기능 세트가있는 Riak을보고 싶을 수도 있습니다 그러나 다른 접근법.

+0

나는 Riak을 몰랐다. 나는 그것을 시도하고 알려주지. 답장을 보내 주셔서 감사합니다! – Juanda

9

~ 3000 신호/분 = 50 개의 쓰기/이러한 시스템 중 어느 것이 쉽게 처리 할 수 ​​있는지.

데이터 세트가 메모리보다 커지면 Cassandra가 가장 잘 작동하지만 Hadoop 통합은 데이터 마이닝에 도움이됩니다.

+0

답장을 보내 주셔서 감사 드리며, Hadoop을 더 자세히 살펴 보겠습니다. 진실은 내가 익숙하지 않다는 것입니다. 고마워요! – Juanda

4

"번개 빠른"쓰기 (데이터는 디스크에 유지됨)를 허용 할 수있는 데이터 저장소를 찾고 있으며 나중에 데이터 마이닝이 수행됩니다 (READ주기 임). 또한 귀하가 진술 한 숫자를 고려하여 하루에 159MB의 정보를 모두 수집하거나 매달 약 5GB의 정보를 수집합니다.

이 경우 Redis를 보시기 바랍니다.

당신은 매일 레디 스 데이터 파일을 보관하고

레디 스 오히려입니다 (당신이로드 5기가바이트의 우려 사항이나 RAM 공간의 큰 금액이있는 경우에, 당신이 보관이 해결 될 수있다) 나중에 참조 항상 수 해당 사이트에 게시 된 번호를 기반으로합니다. 희망이 도움이됩니다. Kiran

13

CouchDB는 매우 안정적이며 뛰어난 내구성을 제공하며 CPU로드가 매우 낮습니다. 또한 온 디맨드 (on-demand) 또는 지속적으로 여러 노드간에 복제 할 때 탁월합니다.

복제 기능과 RESTful API (API에 HTTP를 사용함) 덕분에 성숙 도구를 사용하여 쉽게 수평 확장 할 수 있습니다. (Nginx 또는 역방향 프록시 용 Apache, HTTP로드 밸런서 등)

JavaScript에서 map을 사용하여 쿼리를 사전 계산합니다. 결과는 디스크에 점진적으로 축적되어 신호당 한 번만 계산하면됩니다. 즉, 쿼리를 마지막으로 실행 한 이후로 기록 된 신호 데이터에 대한 계산 만 수행하면되므로 쿼리가 실제로 빨라질 수 있습니다.

CouchDB는 성능을 위해 디스크 공간을 교환하므로 많은 디스크 공간을 사용할 수 있습니다. 쿼리를 적절하게 구현하면 쿼리가 번개처럼 빨리 수행되고 디스크 공간을 절약 할 수 있습니다.

Give CouchDB a try.

체크 아웃 Why Large Hadron Collider Scientists are Using CouchDB

100

CouchDB at the BBC as a fault tolerant, scalable, multi-data center key-value store은 공간 규모 (1000 개 장치) 계산 및/또는 저장 규모로 당신을 오해하지 마십시오. 초당 수십 개의 35 바이트 인서트는 저가형 하드웨어에서 실행되는 주류 DBMS에 대한 간단한 작업 부하입니다. 마찬가지로 매월 1 억 4 천 2 백만 건의 기록은 색인을 포함하여 압축없이 1 개월에 1 ~ 10 기가 바이트의 저장량을 유지합니다. 귀하의 질문에 코멘트에서

, 당신은 말했다 :

"그것은 모든 안정성, 확장 성 및 속도에 관하여 매우 솔루션 (MongoDB를가 autosharding?) 만 이상의 노드에 던지는 쉽게 확장하는 것이 중요하고, 속도입니다. 또한 매우 중요하다

신뢰성 모든 주류 DBMS는 당신이 당신의 데이터가 손상에 없을거야 의미 가정 (이 보장 할 수 있으며 충돌 않을거야? -이 하단의 CAP 정리의 내 설명을 참조하십시오 답). 속도? 단일 기계로도이 작업량의 10 ~ 100 배는 prob가 아니어야합니다 흠. 확장 성? 현재의 속도로 볼 때 압축되지 않은 데이터 (완전 인덱싱 된 데이터)는 100 기가 바이트의 디스크 공간에 쉽게 맞을 것입니다 (마찬가지로 인서트 비율은 이미 문제가되지 않습니다).

이와 같이 NoSQL이나 분산 데이터베이스와 같은 이국적인 솔루션에 대한 분명한 필요성은 없습니다. MySQL과 같은 평범하고 오래된 관계형 데이터베이스도 괜찮습니다. 장애 조치가 걱정된다면 마스터 - 슬레이브 구성으로 백업 서버를 설정하기 만하면됩니다. 현재 규모의 100 배 또는 1000 배를 말하는 경우 데이터 수집 장치의 ID (예 : , 즉 {파티션 색인} = {장치 ID} 모듈로 {파티션 수})를 기반으로 몇 개의 인스턴스를 가로로 분할합니다. . 관계형 데이터베이스 세계의 안전하고 편안한 경계를 떠나는 것은 그 구상 모델하고 풍부한 툴셋 모두를 포기 의미를 염두에

곰. 이렇게하면 "복잡한 데이터 마이닝"이 훨씬 어려워집니다. 데이터베이스에 데이터를 넣을 필요 만 아니라 데이터를 가져와야합니다.

MongoDB와 CouchDB는 배치 및 작업이 매우 간단합니다. 그것들은 또한 매우 재미 있고, 당신을 어떤 수의 사람들에게나 매력적으로 만들 것입니다. (프로그래머들 - 임원들도!).

당신이 제안한 3 가지 NoSQL 솔루션 중 Cassandra가 높은 삽입량에 가장 적합하다는 것이 일반적입니다. (물론, 상대적으로 말하자면, 나는 당신이 생각하지 않습니다. 은 높은 삽입량이입니다. 에 의해 사용되는 것); 이것은 함께 일하기가 더 어려워 져서 반대됩니다. 따라서 언급하지 않은 이상한 요구 사항이 없으면 사용 사례에 대해 권장 할 것입니다.

NoSQL 배포를 적극적으로 설정 한 경우 CAP 정리를 고려할 수 있습니다. 이렇게하면 MongoDB와 CouchDB 사이에서 결정하는 데 도움이됩니다. 다음은 좋은 링크입니다 : http://blog.nahurst.com/visual-guide-to-nosql-systems. 모든 것이 "신뢰성"을 의미합니다 : MongoDB는 일관성을 위해 가용성을 교환하지만 CouchDB는 가용성을 위해 일관성을 교환합니다. (Cassandra는 쓰기/읽기가 성공하기 위해 얼마나 많은 서버가 쓰여지거나 읽혀 져야 하는지를 질의별로 결정할 수있게 해줍니다.) 업데이트 : 이제 CouchDB도 BigCouch으로 매우 재미 있습니다 ...)

프로젝트에서 가장 좋은 행운.

+0

질문에 Riak은 포함되지 않았지만이 시나리오에서는 어떻게 생각합니까? – Mark

+0

+1 "MongoDB는 일관성을위한 가용성을 제공하지만 CouchDB는 가용성을 위해 일관성을 유지합니다." –

27

답변의 상당 부분은 수집 한 후에 무엇을하고 싶은지에 따라 달라집니다. 많은 양의 데이터를 저장하는 것은 간단합니다. 로그 파일에 넣기 만하면되므로 데이터베이스가 필요 없습니다. 반면에 복잡한 분석 및 데이터 마이닝을 수행하려는 경우 데이터베이스가 유용합니다.

다음 질문은 당신이 어떤 분석을 할 것인지입니다. 특정 속성이있는 데이터의 하위 집합, 마지막 시간/일/주/월에서만 데이터가 집계되거나 사전 계산 될 수 있습니까? 즉, 수집 된 형태로 전체 데이터 세트에 액세스해야합니까? 너무 오래되어서 재미있을 때 데이터를 보관할 수 있습니까? 데이터를 집계하고 집계에 대한 분석을 수행 할 수 있습니까?

광고 분석 (광고 노출에 관한 수십억 데이터 수집)에서의 경험으로 집계가 중요합니다. 원시 데이터를 수집하고 위생 처리 한 다음 MongoDB, Cassandra 또는 MySQL과 같은 데이터베이스에 저장하여 업데이트 및 쿼리를 수행 할 수 있습니다. 그런 다음 주기적으로 데이터를 집계하여 데이터베이스에서 제거합니다 (그러나 원시 데이터는 보관해야하며 나중에 필요할 수 있습니다).

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

집계를 기록하는 데이터베이스 유형은 들어오는 신호를 저장하는 데이터베이스 유형과 같을 수 있지만별로 멋지다고 할 필요는 없습니다. 특정 답변을 나타내는 키와 보통 숫자 인 값을 저장합니다.

들어오는 신호를 저장하는 데이터베이스를 말하는 구식 데이터웨어 하우징에서는 OLTP (온라인 트랜잭션 처리 용)라고하며 집계를 저장하는 데이터베이스를 OLAP (온라인 분석 처리 용)이라고합니다.OLTP는 삽입에 최적화되어 있으며 OLAP은 쿼리에 최적화되어 있습니다. 용어는 오래되었고 사람들이 그 단어를들을 때 SQL과 별표와 그 모든 것을 즉시 생각하는 경향이 있습니다. 아마도 나는 그들을 사용해서는 안되지만, 그들은 편리한 용어입니다.

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

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

결론 : MongoDB와 Redis는 저에게 큰 도움이됩니다. MongoDB가 사용 사례에 매우 적합하다고 생각하지는 않습니다. 대신 기존 SQL 데이터베이스의 이점을 실제로 누릴 수 있다고 생각합니다. 그러나 데이터가 정말 단순하면 Redis를 항상 사용할 수 있습니다. 가장 중요한 것은 데이터를 하나의 데이터베이스에 보관하고 영원히 유지해야한다는 실수를 범하지 않는 것입니다. 집계와 오래된 데이터 버리기가 중요합니다.

관련 문제