질문 : 높은 중복성으로 강력한 해시로 인덱싱 된 매우 큰 (멀티 테라 바이트) 데이터베이스를 처리 할 때 어떤 솔루션이나 팁이 필요합니까?대용량 데이터베이스를 만드는 데 유용한 팁
어떤 종류의 거꾸로 저장 하시겠습니까?
Postgres로 할 수있는 것이 있습니까?
필요한 경우 내 저장 공간을 준비 할 준비가되었습니다.
(힌트 : 오픈 소스, 아니 자바를해야합니다, 리눅스에서 실행해야 선호, C/C++/파이썬 디스크 기반해야 함) : 나는 매우를 만들 필요가
세부 사항 대규모 데이터베이스의 각 레코드는 보유 여기서 일부 기본 키
- 어떤 임의의 메타 데이터 (텍스트 필드) (128 비트 해시 강한 MD5 같은) ,617,
기록의 양은 내가 꽤 큰 것으로 간주되는 것입니다 : 몇 10-1 억의 수십억). 행 전반에 걸쳐 중요한 중복이 있습니다 (레코드의 40 % 이상이 다른 레코드와 공유되는 해시를 가지며 일부 해시는 100K 레코드에 있음)
주로 해시로 조회 한 다음 메타 데이터. 두 번째 용도는 기본 키로 조회 한 다음 메타 데이터를 검색하는 것입니다.
이것은 분석 유형 데이터베이스이므로 전체로드가 보통, 대부분 읽기, 거의 쓰기가 아니라 대부분 일괄 쓰기입니다.
현재 접근법은 기본 키에 대한 색인과 해시 열에 대한 색인과 함께 Postgres를 사용하는 것입니다. 테이블이 일괄 적으로로드되고 해시 인덱스가 해제됩니다.
모든 색인은 btree입니다. 해시 열의 인덱스가 테이블 자체보다 크거나 커질 정도로 커지고 있습니다. 120GB의 테이블에서는 색인을 다시 생성하는 데 약 하루가 소요됩니다. 쿼리 성능은 꽤 좋습니다.
문제는 전체 대상의 약 10 %를 나타내는 400GB의 더 작은 데이터 세트를 사용하는 테스트를 기준으로 대상 데이터베이스의 예상 크기가 4TB를 초과한다는 것입니다. Postgres에로드되면 저장소의 50 % 이상이 해시 열의 SQL 색인에 의해 불행히도 사용됩니다.
이것은 너무 큽니다. 그리고 해시의 중복성은 적은 양을 저장할 수있는 기회라고 생각합니다.
이 부분에서는 문제에 대해 설명하지만 작성해야하는 테이블이 몇 가지 있습니다.
요즘에는 128 비트 해시가 암호화 등급이 아닙니다. 인덱스를 사용하지 않고 해시의 처음 8 비트를 기준으로 파티셔닝 했습니까? –
@Tyler 128 비트 MD5 또는 truncated SHA1은 저에게 훌륭한 암호화입니다. 적어도 키 범위를 잘 사용합니다.색인을 사용하지 않고 조회 성능이 끔찍합니다. 핵심 파티셔닝에 대해 자세히 설명해 주시겠습니까? –
그래서 인덱스를 사용하고 디스크 공간을 적중하십시오. 속도 나 공간을 최적화하여 하나를 선택하십시오. –