초고속 데이터베이스에서 10 억 행 스캔

배경

로컬 데이터베이스에는 거의 13 억 개의 고유 한 행이 있습니다. 각 행은 특정 위도 및 경도 (위치)와 간접적으로 연결됩니다. 각 행에는 날짜 스탬프가 있습니다.

사용 사례

문제는 다음과 같습니다.

1. 사용자는 시작 / 종료 날짜 및 값 범위 (예 : 100-105)를 설정합니다.
2. 시스템은 주어진 날짜와 일치하는 모든 행을 위치별로 그룹화합니다.
3. 시스템은 해당 날짜 동안 지정된 값 범위에 속할 통계적 가능성이있는 위치를 결정합니다.
4. 시스템은 모든 일치하는 위치를 사용자에게 표시합니다.

이것은 속도와 규모의 문제입니다.

질문

그러한 시스템이 5 초 안에 사용자에 대한 결과를 검색 할 수있는 가장 저렴한 솔루션 아키텍처는 무엇입니까?

현재 시스템

현재 환경은 다음과 같습니다.

• PostgreSQL 8.4 (업그레이드 가능, 데이터베이스 전환은 옵션이 아님)
• R과 PL / R
• XFS
• WD 벨로시 랩터
• 8GB RAM (Corsair G.Skill; 1.3GHz)
• 쿼드 코어 GenuineIntel 7 (2.8GHz)
• 우분투 10.10

하드웨어 업그레이드가 가능합니다.

업데이트-데이터베이스 구조

수십억 개의 행이 다음과 같은 테이블에 있습니다.

id | taken | location_id | category | value1 | value2 | value3

• id-기본 키
• taken-행에 지정된 날짜
• location_id-위도 / 경도에 대한 참조
• category-데이터 설명
• value1 .. 3-사용자가 쿼리 할 수있는 다른 값

이 taken열은 일반적으로 일별 연속 날짜 location_id이며, 때로는 각 위치에 1800에서 2010까지의 데이터가 있습니다 (약 77,000 개의 날짜가 있으며 각 위치에 동일한 날짜 범위의 데이터가 있으므로 이들 중 다수가 복제 됨).

7 개의 범주가 있으며 테이블은 이미 범주별로 분할되어 있습니다 (자식 테이블 사용). 각 범주에는 ~ 1 억 9 천만 개의 행이 있습니다. 가까운 시일 내에 범주 당 행 수가 10 억을 초과 할 것입니다.

대략 20,000 개의 위치와 70,000 개의 도시가 있습니다. 위치는 위도와 경도로 도시와 상관됩니다. 각 도시를 특정 도시에 할당한다는 것은 도시의 경계를 찾는 것을 의미합니다. 이는 사소한 작업이 아닙니다.

아이디어

내가 가진 몇 가지 아이디어는 다음과 같습니다.

• 데이터베이스를 호스팅 할 클라우드 서비스를 찾으십시오.
• 만들기 SSD를 RAID 스트라이프 (큰 비디오).
• 도시별로 모든 위치를 통합하는 테이블을 만듭니다 (사전 계산).

감사합니다!

가장 중요한 것은 데이터베이스를 전환 할 수 없으므로 지정된 수의 대표 요청에 대해 병목 현상이 발생하는 위치를 절대적으로 확인하는 것입니다.

전체 테이블 스캔을 수행하는 경우 적절한 색인이 필요합니다.

I / O를 기다리는 경우 캐싱을위한 추가 메모리가 필요합니다 (Jeff Atwood는 최근 데스크톱 시스템에서 24Gb 시스템에 도달 할 수 있다고 언급했습니다).

CPU를 기다리는 경우 계산을 최적화 할 수 있는지 확인해야합니다.

여기에는 뾰족한 DBA 모자와 운영 체제 모자가 필요하지만 올바른 트리를 짖는 데 가치가 있습니다.

날짜 스탬프를 기준으로 다른 호스트에있는 여러 조각으로 테이블을 분할하는 것은 어떻습니까? 이것은 수평 확장이 가능하며 충분한 수의 상자가 있으면 이러한 설정 위에 작은 집계 엔진을 작성할 수 있습니다.

날짜 스탬프가 너무 많이 변하는 경우 위치를 기준으로 분할 할 수 있으며 다시 수평으로 확장 가능합니다. (다행스럽게도 위도 / 경도를 더 추가하지 않습니다!)

최악의 시나리오는 날짜 범위가 데이터베이스의 모든 날짜를 포함한다는 것입니다.

하나의 물리적 시스템에서 5 초 이내에 13 억 개의 레코드를 읽고 각 레코드와 입력 된 값에 대해 일종의 분석을 수행하려고합니다. 결과는 모든 위치에 있거나 전혀 없을 수 있습니다. 사전에 아무것도 모릅니다.

이러한 매개 변수가 주어지면 불가능하다고 말할 것입니다.

하드 드라이브를 살펴보십시오. 최대 지속 속도는 150MB / s 미만입니다. 13 억 개의 레코드를 읽는 데 5 초 이상이 걸립니다. CPU 측면에서는 5 초 동안 13 억 개의 레코드에 대해 어떠한 종류의 통계 분석도 수행 할 수 없습니다.

유일한 희망 (tm :-))은 사용자가 입력 한 값을 기반으로 검색을 좁힐 수있는 몇 가지 검색 기능을 찾는 것입니다. 이 조회 기능을 오프라인으로 계산할 수 있습니다. 정확한 일치 기준에 대해 더 많이 알지 못하면 누구나 그렇게하는 방법을 말할 수 있다고 생각하지 않지만 예제는 값 범위를 이산 간격으로 분할하고 해당 간격의 모든 레코드를 제공하는 조회를 만드는 것입니다. 간격이 충분히 작 으면 사용자가 입력 한 값과 일치하지 않는 항목을 제거하는 등 실제 작업을 수행 할 수 있습니다. 기본적으로 시간 거래 공간.

메모리의 모든 레코드 (또는 적어도 중요한 부분)를 보유 할 수 있습니다. 아마 8GB가 아닙니다. 메모리 대역폭조차도 5 초 안에 모든 것을 검색하기에는 충분하지 않지만 디스크 I / O 부분을 제거 할 수 있습니다. 어쨌든 이것은 이러한 종류의 응용 프로그램 속도를 높이는 또 다른 기술입니다 (이전 제안과 결합).

클라우드 서비스 사용을 언급했습니다. 예, 충분한 CPU 및 IO 비용을 지불하고 많은 서버에서 데이터베이스를 분할하는 경우 강제 / 분열하여 정복 할 수 있습니다.

두 번째 질문에 대한 rwong의 의견 : PostgreSQL은 적절한 색인 유형 및 도구 (GIST 색인, GIN 색인, Postgis, 기하학 유형)를 제공하여 지리 데이터 및 날짜 시간 관련 데이터를 많은 문제없이 해당 기준에 따라 검색 할 수 있도록합니다.

이러한 기준에 대한 쿼리에 몇 초가 걸리면 해당 인덱스가 사용되지 않는 것입니다. 적절하게 조사했음을 확인할 수 있습니까?

PostgreSQL 및 위도 / 경도 데이터를 사용하는 경우 PostGIS도 사용해야합니다. 이렇게하면 데이터베이스에 GiST 공간 인덱스를 추가하여 작업 속도를 높일 수 있습니다.

나는 당신보다 훨씬 작은 구성 (2 코어 및 거의 2Gb RAM)을 가진 그러한 테이블 (350k 행)을 가지고 있지만 검색에는 1 초도 걸리지 않습니다.

Essbase가 OLAP 아키텍처를 사용한 것처럼 관계형 모델을 깨뜨릴 수도 있습니다. Essbase Wikipedia

의미하는 것은 도시 당 하나의 테이블을 생성하여 1000 개 이상의 테이블로 끝나는 것입니다. 당신과 같은 하나의 테이블이 아니라 많은 테이블이 제안되었습니다. 날짜와 위치별로 각 테이블을 색인화하십시오. 많은 테이블, 많은 인덱스-> 더 빠름.

데이터베이스를 호스팅 할 클라우드 서비스를 찾는 것에 대한 아이디어는 아직 SimpleGeo를 경험 한 적이 있습니까? 그들은 "실제로 데이터를 저장하고 쿼리하는 속도가 엄청나게 빠르다"는 스토리지 서비스에서 리본을 잘라 냈다. 수십억 개 이상의 행에 대해 저장하고 쿼리하는 비용으로 인해이 방법을 실현할 수는 없을 것이다.

고속도로에서 자전거를 타기를 기대하고 있습니다. 현재이 문제를 해결하기위한 해결책을 찾고 있는데, 20 억 개의 레코드가 있다면 어떻게해야합니까? 확장 성을 다루어야합니다. 대답은 간단한 사용 개체 데이터베이스입니다. 예 : 인터 시스템 캐시

내가 당신을 믿습니다.