2013-11-01 2 views
-1

약 6 백만 개의 레코드가있는 데이터 세트가 있습니다. 각 레코드의 필드 수는 같습니다.특정 요구 사항에 대한 최상의 SQL NoSQL 솔루션?

ID Title Color Date1 Date2 Date3 Date4... 

제목 및 모든 날짜 필드 (또는 RDBMS의 측면에서, '열')에 의해 이러한 레코드를 필터링 할 수있는 방법이 있어야합니다 : 완전히 8 개 필드가 있습니다.

데이터의 크기는 그리 크지 않으며 몇 기가 바이트 정도입니다. 우리는 긴 텍스트 필드 등을 가지고 있지 않습니다 (우리는 아키텍처를 생성하는 동안 그것들을 제거했습니다, 그래서 우리는 데이터 세트에서 정말로 중요한 필드만을가집니다).

백엔드 읽기 &은 상당히 집중적으로 데이터를 씁니다. 가능한 한 많은 읽기/쓰기 (그리고 필드로 필터링) 속도를 높이고 싶습니다. 현재 우리는 Postgres를 사용하고 있으며 신뢰성이 좋지만 실제로는 그렇게 빠른 것은 아닙니다. 예, 우리는 약간의 조정과 최적화, 인덱스 추가, 32GB RAM 머신에 설치 및 필요한 모든 설정을했습니다. 다른 말로하면, 그것은 효과가 있지만 여전히 좋을지 모른다. 우리가 필요로하는 것은 속도입니다 : 날짜와 제목으로 레코드를 필터링하는 것은 빠르고 빠르며 빠릅니다. 데이터 삽입이 느려질 수 있습니다. 백엔드는 처리되지 않은 모든 레코드를 필터링하여 처리하고 날짜 플래그 (처리 된 날짜 시간)를 설정합니다. 5 백 -10 초마다 50 명의 백엔드 '근로자'가 실행되므로 DB는 매우 빠르게 수행 할 수 있어야합니다. 또한 우리는 DB 반복 (일종의 map/reduce 작업)을 수행하므로 DB 솔루션이 이러한 종류의 작업을 수행 할 수 있어야합니다 (RDBMS는 여기서는별로 좋지 않습니다).

우리는 조인을하지 않았으므로 데이터는 이미 큰 데이터 솔루션에 최적화되어 있습니다. 오직 하나의 '큰 테이블'.

우리는 단일 노드 또는 많은 작은 인스턴스에서 실행하려고합니다. 데이터는 그다지 중요하지 않습니다. 그러나 값 비싼 솔루션을 피하기 위해 Postgres보다 저렴한 저렴한 하드웨어에서 SQL 또는 NoSQL 솔루션을 찾고 있습니다.

나는 약 1, 2 년 전에 MongoDB를 사용했었다. 내가 기억하는 바로는, 필터링은 그 순간 너무 빨랐습니다. 카산드라는 더 좋았지 만 필터링 쿼리의 작은 하위 집합 만 수행 할 수 있다는 것을 기억합니다. Riak은 좋지만 많은 기계가있는 큰 클러스터에만 적합합니다. 이 솔루션 중 하나가 훌륭한 기능을 수행한다는 사실을 알고 계신다면 매우 기본적인 경험입니다. 또는 다른 해결책을 제안하십시오.

감사합니다.

+3

"데이터 크기가 그리 크지 않고 몇 기가 바이트 정도입니다." Postgres를위한 작은 그것. 성능상의 문제없이 천 배나 큰 데이터베이스를 처리 할 수 ​​있습니다. 현재 사용하고있는 것에 충실하십시오. 그것을 더 잘 사용하는 법을 배웁니다. –

답변

1

데니스와 동의합니다. 포스트그레스에 동의해야합니다. 필자의 경험에 비추어 볼 때, 관계형 데이터베이스는 정확하게 튜닝되면 매우 빠른 결과를 얻습니다. 아니면 다른 방법으로 ... 나는 SQL Server와 MySQL을 튜닝하는 것보다 10ms 이내에 반환되는 복잡한 쿼리를 얻기 위해 Mongo를 조정하는 것이 훨씬 더 힘들다는 것을 알게되었습니다.

더 조정하는 방법에 대한 아이디어는 http://use-the-index-luke.com/ 웹 사이트를 참조하십시오. 그 남자는 또한 당신에게 유용할만한 책을 썼습니다.

데니스 (Denis)와 마찬가지로 데이터 크기가 크지 않아 NoSQL 솔루션을 처음부터 시작하는 것이 가치가 있습니다.

+0

참고로 바닐라 PostgreSQL은 수십 TB 크기의 데이터베이스를 처리하며 Postgres-XC 또는 연합 스토리지와 같은 방식을 사용하면 잠재적으로 그 크기보다 훨씬 많은 시간을 얻을 수 있습니다. 또한 대형 데이터 병목의 주요 병목 현상이 해결 될 것으로 예상되므로 크기를 고려하지 않을 것입니다. –

2

위의 Ryan과 동의합니다. PostgreSQL을 고수하십시오.

쓰기로드가 실제로 어떤 것인지 설명하지 않았습니다. (여기저기서 몇 가지 레코드를 업데이트하지만 병렬 쿼리가 많이 있습니까?) 적은 수의 병렬 쿼리로 업데이트하지만 한 번 등). 그래서 더 많은 속도를 내기 위해해야 ​​할 일을 말할 수는 없습니다.

그러나 귀하의 질문과 지금까지 시도한 바를 토대로 컨설턴트를 고용하여 DB를보고 신선한 환경을 보며 새로운 것을 제안하고 개선을 제안하는 것이 좋습니다. 내 생각 엔 당신은 많은 것들을 계속해서 최적화 할 수 있으며, 새로운 환경으로 전환하는 것보다 그러한 최적화에 훨씬 덜 소비 할 것입니다.

관련 문제