2017-09-18 17 views
1

저는 아직 NoSQL 데이터베이스를 처음 사용하고 있으며 RDBMS (Oracle, MySQL)를 오랫동안 사용해 왔습니다. 이제는 데이터베이스 중 하나를 In-Memory NoSQL DB로 마이그레이션하는 것을 고려하고 있으며 최선의 설계 방식을 고수하고 있습니다.NoSQL (Redis) 디자인 조언

우리는 Redis를 고려하고 있지만, 다른 Key-Value 매장 (RocksBD 또는 LMDB)과 연계 될지 또는 단독으로 사용하는 것이 가장 적합한 지 여부는 내가 귀하로부터받는 조언을 기반으로합니다. (우리는 문제를 해결하는 완전히 다른 접근법에 대해 조언을 구할 수 있습니다.)

In-Memory NoSQL으로 마이그레이션 할 표에는 인구 통계 (예 : 성, 성, 주소, 생년월일, 출생 국가 등 약 40 개의 인구 통계 학적 필드)와 사진, 서명 및 모든 10 개의 지문과 같은 생체 인식 데이터 .

쿼리는 어디에 FIRSTNAME = '존스'와 LASTNAME = '앙드레'와 생년월일 (DateOfBirth)> 9월 13일 우리는 아주 쉽게 레디 스 키 - 값 저장소에 모든 것을 저장할 수 1984

(를 포함하여 사진을 검색하는 등의 인구 통계에 실행됩니다 , 서명, 지문 및 모든 인구 통계)가 있지만, DB가 최종적으로 약 2 억 건의 레코드로 증가 할 것이므로 특히 많은 양의 RAM이 필요하다고 걱정합니다. 따라서 자주 검색 할 인구 통계 (예 : 성, 성, 생년월일 등)를 저장 한 다음 나머지 데이터를 LMDB 또는 RocksDB와 같은 키 - 값 저장소에 저장하는 것이 고려되었습니다 redis보다 적은 메모리). 이 구현에서 firstname = jones 및 lastname = mark 위치에서 검색을 원할 때 redis를 검색하고 검색된 레코드의 ID를 얻은 다음 키 - 값 저장소 (lmdb 또는 rocksDB)에서 레코드를 다시 가져옵니다. 우리는 주로 쓰기 성능에 대해 거의 걱정하지 않고 읽기 성능에 신경 쓰고 있습니다. 우리는 매우 빠른 읽기를 원합니다.

  1. 이것은 좋은 디자인 접근 방법인가요? 아니면 누군가가 더 나은 성능을 이끌어 낼 수있는 더 나은 디자인 접근 방법을 조언 할 수 있습니까? 목표는 RAM 요구 사항을 최소화하고 아주 좋은 읽기 성능을 얻는 것임을 기억하십시오.

  2. 그런데 그런 식의 생체 인식을 메모리에 저장하는 것이 좋은 방법일까요?

  3. 어떻게 이런 challanges이

는 또한 우리는 인구 통계 학적,하고 검색의 하위 집합에 대해 쿼리 동안, 우리가 주로 전체 데이터 집합을 검색 있습니다 해결합니다. (즉, 인구 통계 및 생체 인식을 검색하는 각 일치하는 개인의 경우)

+0

더 빠른 답변을 얻기 위해 어떤 상황에서 "긴급한"또는 다른 유사한 문구를 추가 할 수 있습니까?] (// meta.stackoverflow.com/q/326569) - 요약하면 자원 봉사자를 대처하는 이상적인 방법이 아니며, 아마도 답을 얻는 데 비생산적입니다. 이 질문을 귀하의 질문에 추가하지 마십시오. – halfer

+0

name = 'jhon'&& last = 'doe'와 같은 조건이 키 - 값 저장소에 구현되는 방법을 잘 모르겠습니까? – ren

+0

예. redis 지원 그러한 검색 – SWILL

답변

0

멋진 저장소 및 색인 생성 도구이므로 Redis의 훌륭한 팬입니다. 지금까지 보았 듯이, 100 % NoSQL 디자인에서는 요구 사항이 실제로 잘 맞지 않습니다.

SQL에 데이터를 보관하고 Redis로 복합 색인을 작성하도록 제안 할 수 있습니다. PK-lookup 초고속 SQL (PostgreSQL)을 얻고 Redis에서 PK로 데이터 색인을 생성하십시오.메모리 사용에 아무런 문제가 없으며 대량의 데이터를 가져 오기 위해 여러 가지 PK 쿼리를 실행할 때 모든 것이 종료됩니다. 또는 CHARS 열만 색인화/캐시하고 이미지와 크기가 큰 값을 SQL로 유지하는 전략을 적용 할 수 있습니다. 또는 액세스 된 크기의 데이터를 임시 캐싱하고 최근 액세스하지 않은 데이터의 키를 축출합니다.

메모리에 관해서는 Redis Cluster를 사용하여 해결할 수 있습니다.

[업데이트] 일반적으로 색인화해야하는 모든 값에 대해 Redis 키를 만들려고합니다. 문자열을 색인화하려면 모노 스코어링 된 정렬 된 세트를 사용하고 ZINDEXBYRANGE을 사용하고, datetime의 경우 점수를 타임 스탬프로 설정하고 ZRANGEBYSCORE을 사용할 수 있습니다. 액세스/저장 패턴에 따라 데이터의 일부분을 저장하고 대량을 SQL에 남겨 둘 수 있습니다. 속도에 관해서는 키/값을 설계하는 방법과 태스크에 할당 할 수있는 RAM의 양에 따라 달라 지므로 실제로 말할 수는 없습니다.

+0

귀하의 의견을 많이 주셔서 감사합니다. 귀하의 제안은 RDBMS와 No-SQL DB 유지 보수를 수반합니다. 그게 최선의 방법이라면 그것은 고려 될 것입니다. Howerever, 나는 redis가 이러한 검색을 지원함을 알고 있습니다. 예를 들어, firstname = 'jones'및 lastname = 'eva'및 dateofbirth> 1989 년 12 월 12 일)와 같이 색인 된 경우 값에 따라 쿼리합니다. 그런 쿼리에서 redis가 잘 수행되지 않는다고 생각하십니까? 레코드를 가져 오기위한 두 번의 호출 (rdbms의 첫 번째 호출과 redix의 다른 호출)이 redis의 호출보다 성능이 좋을 것이라고 생각하십니까? – SWILL

+0

@SWILL 답장을위한 업데이트보기 – tuned

0

귀하의 요구 사항이 200 만 건의 레코드를 저장하고 최대한 다른 조건에서 검색하는 것이 가장 좋은 경우 가장 적합한 디자인을 결정하는 유일한 방법은 다음과 같습니다. 개념 증명으로 사용해보십시오.

비록 직관적으로, 적절한 인덱스가있는 관계형 데이터베이스가 최상의 선택입니다. 특히 경험이있는 경우에는 더욱 그렇습니다.

또 다른 옵션으로 여러 컴퓨터에서 데이터를 배포 할 수 있지만 어려운 방법입니다.

+0

귀하의 입력에 대단히 감사합니다 – SWILL