무엇을 선택해야 합니까?MongoDB/Cassandra/Redis/CouchDB?
지금 정말 큰 프로젝트를 진행 중인데, 어떤 DB 백엔드를 선택해야 하는지 조언해 주실 수 있나요?
델의 시스템은 중앙 서버에 신호를 송신하고 서버가 신호 정보를 저장하는 1100개의 전자 장치로 구성되어 있습니다(신호의 길이는 약 35바이트).이들 디바이스는 각각 분당 약 3개의 신호를 송신합니다.따라서 디넘버를 실행하면 데이터베이스에 매일 4.752.000개의 새로운 레코드가 생성되고 총 142.560.000개의 새로운 레코드가 생성됩니다.
빠르고 안정적인 DB 백엔드가 필요합니다.물론 그 DB에서 복잡한 데이터 마이닝을 수행해야 합니다.MongoDB/Cassandra/Redis/CouchDB에 대해 조사 중이지만 문서 웹사이트는 아직 초기 단계에 있습니다.
도움이 필요하신가요?아이디어?
정말 고마워.
공간적 확장(1000대 이상의 디바이스)으로 인해 컴퓨팅 및/또는 스토리지 확장이 잘못되지 않도록 하십시오.로우엔드 하드웨어에서 실행 중인 메인스트림 DBMS에서는 초당 35바이트의 삽입이 수십 개에 달합니다.마찬가지로 인덱스를 포함한 압축 없이 매달 1억4천200만 개의 레코드가 약 1~10기가바이트의 스토리지 용량에 불과합니다.
질문 코멘트에서 다음과 같이 말씀하셨습니다.
「신뢰성, 확장성, 스피드가 중요합니다.노드 추가만으로 솔루션을 쉽게 확장(MongoDB 자동 저장)하는 것이 매우 중요하며 속도도 매우 중요합니다.
신뢰성?모든 주류 DBMS가 이를 보증할 수 있습니다(데이터가 손상되지 않고 크래시가 발생하지 않는다는 가정 하에 이 답변의 하단에 있는 CAP 정리에 대한 설명을 참조하십시오).속도? 한 대의 기계라도 10~100배의 작업부하는 문제 없습니다.확장성?현재 속도로는 압축되지 않은 데이터나 인덱스가 완전히 적용된 데이터도 100기가바이트의 디스크 공간 내에 쉽게 들어갈 수 있습니다(이미 삽입 속도는 문제가 되지 않는다는 것을 확인했습니다).
따라서 NoSQL과 같은 이국적인 솔루션이나 분산형 데이터베이스도 필요하지 않습니다. MySQL과 같은 단순하고 오래된 관계형 데이터베이스로도 충분합니다.페일오버가 우려되는 경우 마스터 슬레이브 구성으로 백업 서버를 설정하기만 하면 됩니다.현재 규모의 100배 또는 1000배에 해당하는 경우 데이터 수집 장치의 ID(예: {device index} = {device id} modulo {number of partitions})를 기준으로 몇 개의 인스턴스를 수평 분할하면 됩니다.
관계형 데이터베이스의 안전하고 편안한 한계를 벗어나면 표현 모델과 풍부한 도구 세트를 모두 포기하는 것을 의미합니다.이렇게 되면 "복잡한 데이터 관리"가 훨씬 더 어려워집니다. 데이터를 데이터베이스에 저장할 뿐만 아니라 데이터를 꺼내야 합니다.
MongoDB와 CouchDB는 도입과 조작이 매우 간단합니다.그들은 또한 매우 즐겁고 많은 사람들에게 당신을 더 매력적으로 만들어 줄 것입니다(프로그래머뿐만 아니라 경영진도!).
당신이 제안한 3가지 NoSQL 솔루션 중 Cassandra가 높은 인서트 볼륨(물론 비교적 높은 인서트 볼륨은 아니라고 생각합니다.이것은 Facebook에서 사용하도록 설계되어 있습니다)에 대응하고 있습니다.따라서 언급하지 않은 몇 가지 이상한 요구 사항이 없는 한 사용 사례에 대해 반대할 것을 권장합니다.
NoSQL 전개를 확실히 설정하고 있다면 CAP 정리를 고려해 보는 것이 좋습니다.MongoDB와 CouchDB 중 하나를 선택하는 데 도움이 됩니다.여기 좋은 링크가 있습니다.http://blog.nahurst.com/visual-guide-to-nosql-systems이 모든 것은, 「신뢰성」의 의미에 근거하고 있습니다.MongoDB는 일관성을 위해 가용성을 교환하고 CouchDB는 가용성을 위해 일관성을 유지합니다.(Cassandra는 쓰기/읽기를 성공시키기 위해 필요한 서버 수를 지정함으로써 쿼리별로 이 트레이드오프를 개선할 수 있습니다.업데이트: BigCouchDB도 마찬가지입니다!너무 신나요...)
당신의 프로젝트에 행운을 빌어요.
대부분의 답변은 수집된 후 원하는 작업에 따라 달라집니다.많은 데이터를 쉽게 저장할 수 있습니다.로그 파일에 덤핑하기만 하면 데이터베이스가 필요 없습니다.한편, 복잡한 분석 및 데이터 마이닝을 수행하려면 데이터베이스를 사용하는 것이 좋습니다.
다음 질문은 어떤 분석을 할 것인가입니다.특정 속성을 가진 데이터의 서브셋(지난 시간/일/주/월)에 대해서만 데이터를 집계하거나 미리 계산할 수 있습니까?즉, 데이터셋 전체를 수집한 형태로 액세스해야 합니까?데이터가 너무 오래되어 흥미를 끌지 못할 때 아카이브할 수 있습니까?데이터를 집계하고 집계에 대한 분석을 수행할 수 있습니까?
광고 분석(광고 노출에 대한 수십억 개의 데이터 포인트 수집)을 사용한 경험이 핵심입니다.원시 데이터를 수집하고 삭제한 후 MongoDB, Cassandra, MySQL 등의 데이터베이스에 저장하여 업데이트 및 쿼리를 수행할 수 있습니다.그런 다음 데이터를 정기적으로 집계하여 데이터베이스에서 제거합니다(단, 원시 데이터는 나중에 필요할 수 있음).
집약은 기본적으로 데이터에 대해 묻고 싶은 모든 질문을 하고 특정 질문에 대한 답변을 쉽게 검색할 수 있는 형식으로 저장합니다.X가 가장 많은 요일을 알고 싶다고 합니다.이 간단한 구현은 기록된 모든 신호를 큰 테이블에 보관하고 X가 있는 모든 행을 합산하는 쿼리를 실행하는 것입니다.수집된 신호의 수가 증가함에 따라 이 쿼리는 점점 더 오래 걸립니다.인덱싱, 샤딩 또는 최적화를 아무리 많이 실시해도 도움이 되지 않습니다.대신 매일/시간/분(정확한 사용 사례와 최신 보고서 작성 방법에 따라 다름)에 기록한 새로운 신호를 확인하고 X마다 월요일, 화요일인 경우 X 수를 추적하는 카운터를 늘립니다.그러면 나중에 요일별 카운트를 가져와 비교할 수 있습니다.응답할 수 있는 모든 질문에 대해 이 작업을 수행한 후 데이터베이스에서 신호를 제거합니다(단, 원시 데이터는 그대로 유지).
집계를 기록하는 데이터베이스 유형은 수신 신호를 저장하는 데이터베이스 유형과 동일할 수 있지만 매우 복잡할 필요는 없습니다.특정 답변을 나타내는 키와 보통 단순한 숫자 값을 저장합니다.
구식 데이터 웨어하우징에서는 착신 신호를 저장하는 데이터베이스를 OLTP(온라인 트랜잭션 처리용)라고 하며 집계를 저장하는 데이터베이스를 OLAP(온라인 분석 처리용)라고 합니다.OLTP는 삽입용으로 최적화되어 OLAP은 쿼리에 최적화되어 있습니다.이 용어는 오래되었고 사람들은 이 용어를 들으면 즉시 SQL이나 스타스마 같은 것을 떠올리는 경향이 있습니다.사용하지 않는 편이 좋을지도 모르지만, 편리한 용어입니다.
어쨌든 OLTP의 경우 데이터를 빠르게 삽입할 수 있을 뿐만 아니라 데이터를 인덱싱하고 검색할 수 있는 기능이 필요합니다.집약은 최대값과 최소값을 합산하고 찾는 작업의 절반을 수행하는 데이터베이스에 의해 크게 도움이 됩니다.MongoDB는 셋업과 작업이 매우 간단하기 때문에 매우 마음에 듭니다.제가 취급하는 데이터는 지저분한 경향이 있고, 모든 아이템이 같은 속성을 가지고 있는 것은 아니기 때문에 Mongo의 용서할 수 있는 계략이 장점입니다.한편, 데이터는 훨씬 균일하게 들리기 때문에 Mongo는 그다지 많은 이점을 제공하지 않을 수 있습니다.오래된 관계형 데이터베이스를 아직 간과하지 마십시오.많은 양의 합산 등을 수행할 경우 SQL은 뛰어난 성능을 발휘합니다. 그 목적을 위해 구축되었습니다.
OLAP의 경우 훨씬 더 간단한 기능을 위해 필요한 것은 키-밸류 저장소뿐입니다.Redis는 작업 및 셋업이 매우 간단하기 때문에 사용하고 있습니다.또한 스칼라 값 이상을 저장할 수 있어 편리합니다.대부분의 키 값 저장소에서 실제로 값이 목록 또는 해시일 수 있지만 이러한 값을 인코딩해야 하지만 Redis가 기본적으로 처리합니다.Redis의 단점은 쿼리를 수행할 수 없다는 것입니다(예: Y에 대해 이 값이 있는 모든 행을 제공해야 함). 직접 인덱스를 데이터에 보관해야 합니다.한편, 모든 질문에 대한 답변이 미리 계산되어 있기 때문에 색인은 그다지 필요하지 않습니다.그 질문에 의해 정의된 키로 답을 검색하기만 하면 됩니다.위의 질문에서 X가 가장 많은 요일은 월요일, 화요일 등으로 X 작업 횟수를 조회할 수 있습니다.아마 X:monday, X:tuesday 등으로 저장했을 것입니다.
결론:MongoDB랑 Redis랑 잘 어울려요.MongoDB는 사용 사례에 그다지 적합하지 않습니다.대신 기존 SQL 데이터베이스로부터 더 많은 이점을 얻을 수 있다고 생각합니다(단, 데이터가 정말 단순하다면 Redis를 계속 사용할 수도 있습니다).가장 중요한 것은 데이터를 하나의 데이터베이스에 보관하고 영원히 보관해야 한다고 착각하지 않는 것입니다.오래된 데이터를 집약하고 폐기하는 것이 중요합니다.
CouchDB는 매우 신뢰성이 높고 내구성이 뛰어나 CPU 부하가 매우 낮습니다.또한 온디맨드 또는 연속적으로 여러 노드 간에 복제하는 데도 탁월합니다.
레플리케이션 기능과 RESTful API(HTTP를 API로 사용) 덕분에 성숙한 툴을 사용하여 수평으로 쉽게 확장할 수 있습니다(역방향 프록시를 위한 Nginx 또는 Apache, HTTP 로드 밸런서 등).
JavaScript에서 map/reduce 함수를 작성하여 쿼리를 사전 계산합니다.결과는 디스크에 증분적으로 축적되므로 신호당 한 번만 계산하면 됩니다.즉, 쿼리를 마지막으로 실행한 이후 기록된 신호 데이터만 계산하면 되기 때문에 쿼리가 매우 빠를 수 있습니다.
CouchDB는 성능을 위해 디스크 공간을 교환하므로 많은 디스크 공간을 사용할 수 있습니다.쿼리를 올바르게 구현하면 매우 빠르게 쿼리를 실행할 수 있으며 Disk 공간을 절약할 수 있습니다.
대형 하드론 충돌기 과학자들이 BBC에서 CouchDB 및 CouchDB를 내결함성, 확장성, 다중 데이터 센터의 주요 가치 저장소로 사용하는 이유를 확인하십시오.
최대 3000개의 신호/분 = 50개의 쓰기/초이며, 이러한 시스템은 모두 쉽게 처리할 수 있습니다.
그러나 Cassandra는 메모리보다 데이터 세트가 커질 때 가장 잘 작동하며, Hadoop 통합은 데이터 마이닝에 도움이 될 것입니다.
데이터 관리를 위해 데이터를 중앙 DB에 저장하시겠습니까?온라인 거래 처리가 없습니까?
저는 MongoDB가 내구성 면에서 잘한다고 생각하지 않습니다.http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of 를 참조해 주세요.
analytics db Infobright를 사용할 수 있습니다.커뮤니티 에디션:http://www.infobright.org/?
"번개처럼 빠른" 쓰기(디스크에 데이터가 유지됨)를 허용하는 데이터스토어를 찾고 있으며, 데이터 마이닝은 이후 단계(이것이 읽기 주기)에서 수행됩니다.또, 당신이 말하는 수치를 고려하면, 당신은 하루에 159MB, 혹은 한 달에 약 5GB의 정보를 모두 수집할 수 있습니다.
이 경우 레디스를 보면 어떨까요?
매일의 Redis 데이터 파일을 어카이브 해, 나중에 참조할 수 있습니다(5 GB이상의 RAM 용량을 로드할 우려가 있는 경우는, 이 어카이브를 회피할 수 있습니다).
레디스는 그 사이트에 게재된 수치로 볼 때 상당히 빠르다.이게 도움이 됐으면 좋겠다.키란
Incanter의 MongoDB를 사용해 봤는데 마음에 들었어요.이러한 대규모 데이터셋에서는 속도를 말할 수 없지만, Incanter가 기반으로 하는 Clojure는 트랜잭션 관리 측면에서 매우 안정적입니다.Incanter는 뛰어난 분석 도구도 제공하고 있기 때문에 모든 데이터를 분석할 계획이라면 MongoDB + Incanter를 조합하는 것이 좋습니다.
처음부터 수평으로 확장할 수 있는 설계, 가용성에 대한 일관성 조정 등의 기능을 갖춘 Cassandra의 외관이 마음에 든다면 비슷한 기능 세트를 가지고 있지만 다른 접근 방식을 가진 Riak도 고려해 볼 수 있습니다.
언급URL : https://stackoverflow.com/questions/3478916/what-should-i-choose-mongodb-cassandra-redis-couchdb
'sourcecode' 카테고리의 다른 글
| com.sysml.syscl.syscind.exc를 지정합니다.인식할 수 없는 속성 예외:인식할 수 없는 필드 (0) | 2023.03.04 |
|---|---|
| 기본 MongoDB 쉘로 예쁘게 인쇄 (0) | 2023.03.04 |
| 플러그인에서 워드프레스 업로드 파일/이미지 코드를 사용하는 방법 (0) | 2023.02.27 |
| 각진 상태JS 진짜 MVC? (0) | 2023.02.27 |
| Oracle SQL: 다른 테이블의 데이터로 테이블 업데이트 (0) | 2023.02.27 |