73 억 행의 시장 데이터를 저장하는 방법 (읽기 위해 최적화 됨)?

1998 년 이후로 1,000 개의 주식에 대한 1 분 데이터의 데이터 세트가 있는데, 그 총합은 (2012-1998)*(365*24*60)*1000 = 7.3 Billion행입니다.

대부분 (99.9 %)의 경우 읽기 요청 만 수행 합니다.

이 데이터를 db에 저장하는 가장 좋은 방법은 무엇입니까?

• 7.3B 행이있는 큰 테이블 1 개?
• 각각 730 만 개의 행이있는 1000 개의 테이블 (각 주식 기호에 대해 하나씩)?
• 데이터베이스 엔진에 대한 권장 사항이 있습니까? (Amazon RDS의 MySQL을 사용할 계획입니다)

저는 이렇게 큰 데이터 세트를 다루는 데 익숙하지 않으므로 이것은 제가 배울 수있는 좋은 기회입니다. 많은 도움과 조언에 감사드립니다.

편집하다:

다음은 샘플 행입니다.

'XX', 20041208, 938, 43.7444, 43.7541, 43.735, 43.7444, 35116.7, 1, 0, 0

열 1은 주식 기호, 열 2는 날짜, 열 3은 분, 나머지 열은 시가-고가-저가-종가, 거래량 및 3 개의 정수 열입니다.

대부분의 쿼리는 "2012 년 4 월 12 일 12:15에서 2012 년 4 월 13 일 12:52 사이에 AAPL의 가격을 알려주세요"와 같습니다.

하드웨어 정보 : Amazon RDS를 사용할 계획이므로 유연하게 사용할 수 있습니다.

쿼리 및 하드웨어 환경에 대해 알려주십시오.

나는 아주 아주 갈 유혹 될 수 없는 NoSQL을 사용하여, 하둡 만큼 당신이 병렬 처리를 활용할 수있는, 또는 비슷한.

최신 정보

좋아, 왜?

우선, 내가 질문에 대해 물었다는 것을 주목하십시오. 워크로드가 어떤 것인지 모른 채 이러한 질문에 답할 수는 없습니다. (이에 대한 기사가 곧 나타날 것입니다.하지만 오늘은 연결할 수 없습니다.) 그러나 문제 의 규모 는 Big Old Database에서 멀어 질 것을 생각하게합니다.

• 유사한 시스템에 대한 경험에 따르면 액세스는 큰 순차 (일종의 시계열 분석 계산)이거나 매우 유연한 데이터 마이닝 (OLAP) 일 것입니다. 순차적 데이터는 순차적으로 더 좋고 더 빠르게 처리 할 수 ​​있습니다. OLAP는 많은 시간 또는 많은 공간이 소요되는 많은 인덱스를 계산하는 것을 의미합니다.

• 그러나 OLAP 세계의 많은 데이터에 대해 효과적으로 큰 실행을 수행하는 경우 열 기반 접근 방식이 가장 좋습니다.

• 무작위 쿼리, 특히 교차 비교를 수행하려는 경우 Hadoop 시스템이 효과적 일 수 있습니다. 왜? 때문에

  • 비교적 작은 상용 하드웨어에서 병렬 처리를 더 잘 활용할 수 있습니다.
  • 또한 높은 안정성과 중복성을 더 잘 구현할 수 있습니다.
  • 이러한 문제 중 다수는 자연스럽게 MapReduce 패러다임에 적합합니다.

하지만 사실은 우리가 여러분의 작업량을 알 때까지 확실한 말을 할 수 없다는 것입니다.

따라서 데이터베이스는 지속적으로 변경되는 크고 복잡한 스키마가있는 상황을위한 것입니다. 간단한 숫자 필드로 가득 찬 하나의 "테이블"만 있습니다. 나는 이렇게 할 것이다 :

레코드 형식을 보유 할 C / C ++ 구조체를 준비합니다.

struct StockPrice
{
    char ticker_code[2];
    double stock_price;
    timespec when;
    etc
};

그런 다음 sizeof (StockPrice [N])를 계산합니다. 여기서 N은 레코드 수입니다. (64 비트 시스템에서) 몇 백 기가 여야하고 50 달러 HDD에 맞습니다.

그런 다음 파일을 해당 크기로 자르고 mmap (리눅스에서는 또는 Windows에서는 CreateFileMapping 사용)을 메모리에 저장합니다.

//pseduo-code
file = open("my.data", WRITE_ONLY);
truncate(file, sizeof(StockPrice[N]));
void* p = mmap(file, WRITE_ONLY);

mmaped 포인터를 StockPrice *로 캐스팅하고 배열을 채우는 데이터를 전달합니다. mmap을 닫으면 나중에 다시 mmap 할 수있는 파일에 하나의 큰 이진 배열에 데이터가 있습니다.

StockPrice* stocks = (StockPrice*) p;
for (size_t i = 0; i < N; i++)
{
    stocks[i] = ParseNextStock(stock_indata_file);
}
close(file);

이제 모든 프로그램에서 다시 읽기 전용으로 mmap 할 수 있으며 데이터를 쉽게 사용할 수 있습니다.

file = open("my.data", READ_ONLY);
StockPrice* stocks = (StockPrice*) mmap(file, READ_ONLY);

// do stuff with stocks;

이제 메모리 내 구조체 배열처럼 처리 할 수 ​​있습니다. "쿼리"에 따라 다양한 종류의 인덱스 데이터 구조를 만들 수 있습니다. 커널은 디스크와의 데이터 교환을 투명하게 처리하므로 엄청나게 빠릅니다.

특정 액세스 패턴 (예 : 연속 날짜)이있을 것으로 예상되는 경우 배열을 순서대로 정렬하여 디스크에 순차적으로 도달하도록하는 것이 가장 좋습니다.

나는 1000 개의 주식에 대한 1 분 데이터의 데이터 셋을 가지고있다. [...] 대부분의 (99.9 %) 내가 수행 할 시간 읽기 요청 .

한 번 저장하고 여러 번 시간 기반 숫자 데이터를 읽는 것은 "시계열"이라는 사용 사례입니다. 다른 일반적인 시계열은 사물 인터넷의 센서 데이터, 서버 모니터링 통계, 애플리케이션 이벤트 등입니다.

이 질문은 2012 년에 제기되었으며 그 이후로 여러 데이터베이스 엔진이 시계열 관리를위한 기능을 특별히 개발해 왔습니다. 나는 훌륭한 결과를 얻었습니다오픈 소스이고 Go로 작성되었으며 MIT 라이센스를받은 InfluxDB를 .

InfluxDB는 시계열 데이터를 저장하고 쿼리하도록 특별히 최적화되었습니다. 시계열을 저장하는 데 매우 좋다고 종종 선전되는 Cassandra보다 훨씬 더 많습니다.

시계열 최적화에는 특정 장단점이 포함되었습니다. 예를 들면 :

기존 데이터에 대한 업데이트는 거의 발생하지 않으며 논쟁적인 업데이트는 발생하지 않습니다. 시계열 데이터는 주로 업데이트되지 않는 새로운 데이터입니다.

장점 : 업데이트에 대한 액세스를 제한하면 쿼리 및 쓰기 성능이 향상됩니다.

단점 : 업데이트 기능이 크게 제한됨

에서 열린 소싱 벤치 마크 ,

InfluxDB는 27 배 더 큰 쓰기 처리량으로 세 가지 테스트 모두에서 MongoDB를 능가하는 반면, 84 배 더 적은 디스크 공간을 사용하고 쿼리 속도면에서 비교적 동일한 성능을 제공했습니다.

쿼리도 매우 간단합니다. 행이 다음 <symbol, timestamp, open, high, low, close, volume>과 같으면 InfluxDB를 사용하여 저장 한 다음 쉽게 쿼리 할 수 ​​있습니다. 지난 10 분 동안의 데이터에 대해

SELECT open, close FROM market_data WHERE symbol = 'AAPL' AND time > '2012-04-12 12:15' AND time < '2012-04-13 12:52'

ID, 키, 만들 조인이 없습니다. 많은 흥미로운 집계를 수행 할 수 있습니다 . PostgreSQL처럼 테이블 을 수직으로 분할 하거나 MongoDB처럼 스키마를 초 단위로 변환 할 필요가 없습니다 . 또한 InfluxDB는 압축이 매우 잘되는 반면 PostgreSQL은 보유한 데이터 유형에 대해 압축을 수행 할 수 없습니다 .

좋아, 그래서 이것은 다른 답변과 다소 거리가 있지만 ... 파일 시스템 (아마도 파일 당 하나의 스톡)에 고정 된 레코드 크기로 데이터가 있으면 데이터를 얻을 수 있다고 생각합니다. 정말 쉽게 : 특정 주식 및 시간 범위에 대한 쿼리가 주어지면 올바른 위치를 찾고 필요한 모든 데이터를 가져오고 (정확히 몇 바이트인지 알 수 있음) 데이터를 필요한 형식으로 변환 할 수 있습니다. 저장 형식에 따라 매우 빠릅니다.)

Amazon 스토리지에 대해서는 아무것도 모르지만 직접 파일 액세스와 같은 것이 없다면 기본적으로 Blob을 가질 수 있습니다. 큰 Blob의 균형을 맞춰야합니다 (레코드는 적지 만 각각 필요한 것보다 더 많은 데이터를 읽을 수 있음). 시간) 작은 blob으로 (더 많은 레코드가 더 많은 오버 헤드를 제공하고 아마도 더 많은 요청을 가져 오지만 매번 반환되는 쓸모없는 데이터는 적습니다).

다음으로 캐싱을 추가합니다. 예를 들어 다른 서버에 처리 할 다른 주식을 제공하는 것이 좋습니다. 메모리에서 거의 제공 할 수 있습니다. 충분한 서버에 충분한 메모리를 확보 할 수 있다면 "요청시로드"부분을 건너 뛰고 시작시 모든 파일을로드하십시오. 이는 시작 속도가 느린 비용으로 상황을 단순화 할 수 있습니다 ( 특정 재고에 대해 항상 두 개의 서버를 보유 할 수있는 여유가없는 경우 도움이되는 경우).

각 레코드에 대해 주식 기호, 날짜 또는 분 을 저장할 필요가 없습니다. 로드중인 파일과 파일 내 위치에 암시 적이기 때문입니다. 또한 각 값에 필요한 정확도와이를 효율적으로 저장하는 방법을 고려해야합니다. 질문에 6SF를 제공하여 20 비트로 저장할 수 있습니다. 64 비트 저장소에 3 개의 20 비트 정수를 저장할 수 있습니다.이를 a long(또는 64 비트 정수 값이 무엇이든간에) 로 읽고 마스킹 / 시프트를 사용하여 3 개의 정수로 되돌립니다. 물론 사용할 스케일을 알아야합니다. 일정하게 만들 수없는 경우 여분의 4 비트로 인코딩 할 수 있습니다.

다른 세 개의 정수 열이 어떤 것인지는 말하지 않았지만,이 세 가지에 대해 64 비트를 사용할 수 있다면 전체 레코드를 16 바이트로 저장할 수 있습니다. 그것은 전체 데이터베이스에 대해 ~ 110GB에 불과합니다.

편집 : 고려해야 할 다른 사항은 아마도 주식이 주말 동안 또는 실제로 밤새 변경되지 않는다는 것입니다. 주식 시장이 하루에 8 시간, 주당 5 일만 열려 있다면 168 대신 주당 40 개의 값만 필요합니다.이 시점에서 파일에 약 28GB의 데이터 만 남게 될 수 있습니다. 원래 생각했던 것보다 훨씬 작습니다. 메모리에 많은 데이터가있는 것은 매우 합리적입니다.

편집 : 이 접근 방식이 여기에 적합한 이유에 대한 설명을 놓친 것 같습니다. 주식 시세 표시기, 날짜 및 시간과 같은 데이터의 상당 부분에 대해 매우 예측 가능한 측면이 있습니다. 티커를 한 번 (파일 이름으로) 표현하고 날짜 / 시간을 데이터 위치 에 완전히 암시 적으로두면 전체 작업을 제거하는 것입니다. a String[]와 a 의 차이와 비슷 Map<Integer, String>합니다. 배열 인덱스가 항상 0에서 시작하여 배열 길이까지 1 씩 증가한다는 것을 알면 빠른 액세스와보다 효율적인 스토리지가 가능합니다.

HDF5 는 하나의 잠재적 인 응용 프로그램으로 재고 데이터의 시계열 저장을 위해 특별히 설계 되었다는 것이 제 이해입니다 . 동료 스태커들은 HDF5가 염색체 , 물리학 등 많은 양의 데이터에 유용하다는 것을 입증했습니다 .

다음은 무료 오픈 소스 프로젝트 인 OLAP 분석에 좋은 Microsoft SQL Server 2012 데이터베이스 위에 Market Data Server를 생성하려는 시도입니다.

http://github.com/kriasoft/market-data

첫째, 연중 365 일 거래일이 없으며, 공휴일 52 주 주말 (104) = 250 x 누군가가 말한 것처럼 실제 하루 시장이 열리는 시간이며,이 기호를 기본 키로 사용하는 것은 좋은 생각이 아닙니다. 기호가 변경되기 때문에 기호가 A 또는 GAC-DB-B.TO와 같을 수 있으므로 기호 (char)와 함께 k_equity_id (숫자)를 사용하면 가격 정보의 데이터 테이블에 7.3의 추정치가 있습니다. 10 억은 14 년 동안 심볼 당 행이 약 170 만 개에 불과하기 때문에 지나치게 계산되었습니다.

k_equity_id k_date k_minute

및 EOD 테이블의 경우 (다른 데이터에 비해 1000 배 표시됨)

k_equity_id k_date

둘째, 1 년 동안 pnf 또는 꺾은 선형 차트를보고자하는 사람은 누구나 by에 관심이 없기 때문에 분 단위 데이터를 및 EOD 테이블 (하루 종료)과 동일한 DB 테이블에 저장하지 마십시오. 분 정보.

특정 문제에 이상적이라고 생각되는 apache solr을 살펴볼 것을 권장합니다 . 기본적으로 먼저 데이터를 인덱싱합니다 (각 행은 "문서"임). Solr은 검색에 최적화되어 있으며 기본적으로 날짜에 대한 범위 쿼리를 지원합니다. 명목상의 쿼리,

"Give me the prices of AAPL between April 12 2012 12:15 and April 13 2012 12:52"

다음과 같이 번역됩니다.

?q=stock:AAPL AND date:[2012-04-12T12:15:00Z TO 2012-04-13T12:52:00Z]

"stock"이 주식 이름이고 "date"가 인덱싱시 입력 데이터의 "date"및 "minute"열에서 생성 된 "DateField"라고 가정합니다. Solr은 믿을 수 없을 정도로 유연하며 나는 그것에 대해 충분한 좋은 말을 할 수 없습니다. 예를 들어 원본 데이터의 필드를 유지해야하는 경우 쿼리 (또는 필터)의 일부로 "DateField"를 동적으로 만드는 방법을 찾을 수 있습니다.

모든 주요 RDBMS가 이것을 처리 할 것이라고 생각합니다. 원자 수준에서 올바른 파티셔닝이있는 하나의 테이블이 합리적으로 보입니다 (고정 된 경우 데이터 사용량을 기반으로 파티션-이것은 기호 또는 날짜 일 가능성이 높습니다).

원자 수준 이상의 더 빠른 액세스를 위해 집계 된 테이블 작성을 살펴볼 수도 있습니다. 예를 들어 데이터가 하루에 있지만 종종 데이터를 wekk 또는 심지어 월 수준으로 되 돌리는 경우 집계 테이블에서 미리 계산할 수 있습니다. 일부 데이터베이스에서는 캐시 된 뷰를 통해 수행 할 수 있습니다 (다른 DB 솔루션에 대한 다양한 이름-기본적으로 원자 데이터에 대한 뷰이지만 실행되면 뷰가 고정 임시 테이블로 캐시 / 강화 됨-하위 시퀀스 일치 쿼리에 대해 쿼리 됨) . 메모리 / 디스크 공간을 확보하기 위해 간격을두고 삭제할 수 있습니다.)

데이터 사용량에 대한 아이디어로 더 많은 도움을 드릴 수있을 것 같습니다.

느린 솔루션을 단순 최적화 메모리 모델과 비교해야합니다. 압축되지 않은 경우 256GB RAM 서버에 적합합니다. 스냅 샷은 32K에 맞으며 날짜 및 주식에 위치별로 색인화하기 만하면됩니다. 그런 다음 특정 스냅 샷을 만들 수 있습니다. 하나를 여는 것은 종종 이전 스냅 샷을 닫는 것과 같습니다.

데이터베이스 (rdbms 또는 nosql)를 사용하는 것이 왜 합리적이라고 생각합니까? 이 데이터는 변경되지 않으며 메모리에 맞습니다. 이것은 dbms가 가치를 추가 할 수있는 사용 사례가 아닙니다.

하드웨어가 있다면 MySQL Cluster를 추천합니다 합니다. 익숙한 MySQL / RDBMS 인터페이스를 사용하고 빠르고 병렬로 쓰기를 수행 할 수 있습니다. 읽기는 네트워크 지연으로 인해 일반 MySQL보다 느리지 만 MySQL 클러스터 및 NDB 스토리지 엔진이 작동하는 방식으로 인해 쿼리 및 읽기를 병렬화 할 수 있다는 이점이 있습니다.

MySQL 클러스터 머신이 충분하고 각 머신에 대해 충분한 메모리 / RAM이 있는지 확인하십시오. MySQL 클러스터는 메모리 중심의 데이터베이스 아키텍처입니다.

또는 Redis , 읽기 / 쓰기에 대한 키-값 / NoSQL 인터페이스가 마음에 들지 않는다면. Redis에 충분한 메모리가 있는지 확인하십시오. 읽기 및 쓰기가 매우 빠르며 기본 쿼리를 수행 할 수 있지만 (비 RDBMS) 메모리 내 데이터베이스이기도합니다.

다른 사람들이 말했듯이 실행할 쿼리에 대해 더 많이 알면 도움이 될 것입니다.

열 테이블 / 데이터베이스에 저장된 데이터를 원할 것 입니다. Vertica 및 Greenplum과 같은 데이터베이스 시스템은 컬럼 형 데이터베이스이며 SQL Server는 이제 컬럼 형 테이블을 허용한다고 생각합니다. 이들은 매우 효율적입니다SELECT 매우 큰 데이터 세트에서 가져 오는 . 또한 큰 데이터 세트를 가져 오는 데에도 효율적입니다.

무료 컬럼 데이터베이스는 MonetDB 입니다.

사용 사례가 집계없이 단순 읽기 행인 경우 Aerospike 클러스터를 사용할 수 있습니다. 지속성을 위해 파일 시스템을 지원하는 메모리 데이터베이스에 있습니다. 또한 SSD에 최적화되어 있습니다.

사용 사례에 집계 된 데이터가 필요한 경우 날짜 범위 분할이있는 Mongo DB 클러스터로 이동하십시오. 샤드에서 클럽 연도 바이스 데이터를 사용할 수 있습니다.