2014-06-12 9 views
2

필자는 일종의 데이터 저장소에 영구적으로 저장해야하는 과학 측정 데이터가 있습니다.시계열 데이터 용 데이터 저장

나는 100000 센서의 측정 값을 저장하는 방법을 찾고 있는데, 측정 데이터가 수년에 걸쳐 누적되어 센서 당 약 1 000 000 측정 값이됩니다. 각 센서는 매분 1 회 또는 더 적은 횟수로 판독 값을 생성합니다. 따라서 데이터 흐름은 그리 크지 않습니다 (전체 시스템에서 초당 약 200 회 측정). 센서가 동기화되지 않았습니다.

데이터 자체는 [timestamp] [sensor #] [value]의 세 쌍의 스트림으로 제공되며 모든 값은 32 비트 값으로 나타낼 수 있습니다.

가장 간단한 형식에서이 스트림은있는 그대로 3 개의 단일 열 테이블로 저장됩니다. 다음 쿼리는 다음과 같습니다 데이터 질량이 크고, 우리가 원하는 데이터가 그것으로 거의 균일하게 분산으로

SELECT timestamp,value 
    FROM Data 
    WHERE sensor=12345 AND timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp 

불행하게도, 행 기반의 DBMS와이, 매우 가난한 성능을 제공합니다. (수십억 개의 레코드에서 수십만 개의 레코드를 선택하려고합니다.) 성능면에서 필요한 것은 사람이 소비 할 수있는 적절한 응답 시간입니다 (데이터는 사용자에게 그래프로 표시됩니다). 즉 몇 초에 데이터 전송을 더한 것입니다.

또 다른 접근법은 한 센서의 데이터를 하나의 테이블에 저장하는 것입니다. 그런 다음 쿼리가 될 것입니다 : 결과가 상대적으로 작은 (보통 미만 백만 이상의 행) 테이블에서 연속 행의 수를 것 같은

SELECT timestamp,value 
    FROM Data12345 
    WHERE timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp 

은 좋은 읽기 성능을 제공한다.

그러나 RDBMS에는 몇 분 안에 100,000 개의 테이블이 있어야합니다. 이것은 일반적인 시스템에서는 불가능한 것처럼 보입니다. 반면에 RDBMS는 데이터에 관계가 없으므로 올바른 도구로 보이지 않습니다.

나는 하나의 서버는 다음 미키 마우스 시스템을 사용하여 부하에 대처할 수 있음을 입증 할 수 있었다 :

  1. 각 센서는 파일 시스템에 자신의 파일이 있습니다.
  2. 데이터가 도착하면 해당 파일이 열리고 데이터가 추가되고 파일이 닫힙니다.
  3. 쿼리는 해당 파일을 열고 데이터의 시작 지점과 끝 지점을 찾고 그 사이의 모든 내용을 읽습니다.

매우 적은 코드 행. 성능은 시스템 (스토리지 유형, 파일 시스템, OS)에 따라 다르지만 큰 장애물은없는 것 같습니다.

그러나이 길로 가면 파티션, 백업, 스토리지 (클라우드)에서 이전 데이터를보다 깊게 이동하는 등의 코드를 작성하게됩니다. 그러면 내 자신의 DBMS를 롤링하는 것처럼 들립니다. (다시) 바퀴를 reinventing 같은 소리.

데이터 형식을 저장하는 표준 방법이 있습니까? 일부 영리한 NoSQL 트릭?

+0

예, 이것은 정말 문제가되지 않지만 흥미 롭습니다. "프로그래머"또는 "컴퓨터 과학"과 같은 http://stackexchange.com/sites의 다른 모든 사이트를 확인하십시오. 나는 당신이 원하는 것이 매우 고성능이라고 말하고 싶습니다. SQL Server 또는 Oracle과 같은 "바닐라"시스템으로이 작업을 수행 할 수 있습니다. 그러나 속도 목표는 어렵습니다. 3 초 만에 10 억 개의 행 == 엄청난 처리 능력 및 고급 하드웨어 및 논리적 병렬 처리. 클라우드 시스템은 또한 전선에서 너무 느릴 것입니다. 약간의 속도를 포기할 수 있다면 이미 알고있는 것처럼 간단한 데이터 구조가 도움이되기 때문에 그렇게 힘들지 않습니다. –

+1

문제를 더 명확하게 설명하기 위해 질문을 바꾸려고했습니다. 출력 대역폭은 문제가되지 않습니다. 한 번에 한 센서에서 적당한 양의 데이터 만 가져와야하기 때문입니다. 일반적인 쿼리는 20 000 데이터 포인트를 반환합니다. 멋진 하드웨어는 필요하지 않습니다. 적어도 예비 벤치 마크에서는 단일 서버로이를 수행 할 수 있다고 제안합니다. – DrV

+0

니스. 이 경우 구현이 어떤 시스템보다 더 중요 할 것입니다. 데이터 아키텍처는 항상 핵심입니다. :) 재미있어! –

답변

1

정말 쉬운 문제처럼 보입니다. 1 천억 개의 레코드, 12 바이트의 레코드 -> 1.2TB로, 이것은 현대의 HDD에도 큰 볼륨이 아닙니다. LMDB에서 센서 당 subDB를 사용하는 것을 고려할 것입니다. 그런 다음 키/값은 32 비트 타임 스탬프/32 비트 센서 읽기이며 모든 데이터 검색은 키에 대한 간단한 범위 스캔입니다.LMDB를 사용하여 초당 50M 레코드의 순서로 쉽게 검색 할 수 있습니다. (단지 SkyDB 친구들이 https://groups.google.com/forum/#!msg/skydb/CMKQSLf2WAw/zBO1X35alxcJ을 수행함을 참조하십시오.)

+0

전문가의 의견에 감사드립니다! LMDB가 완료되는 방식을 좋아합니다.이 응용 프로그램에서이 기능을 사용하려고 생각했지만 subDB 사용에 대해서는 생각하지 않았습니다. 나는 그들에 대한 나의 무지를 인정하고 각각 200 개의 subDB, 하나의 데이터베이스와 100,000 개의 subDB를 가진 500 개의 데이터베이스를 사용하는 것에 차이가 있는지 물어야 만한다. (50,000 000 레코드/초는 정말 인상적이지만 유감스럽게도 내 데이터는 디스크에 저장 될 것이므로 내 걱정은 읽거나 쓰는 임의의 페이지 수입니다.) – DrV

+1

LMDB는 단일 작성자 디자인이므로 500 명의 동시 작성자를 지원하기 위해 500 개의 데이터베이스로 분할하는 것을 고려하십시오. 그 외에도 동시에 열려야하는 subDB 수에 대한 질문이 있습니다. 첫 번째 mdb_dbi_open()은 실제로 열린 DBI 테이블에서 선형 검색을 수행하므로 100,000에서 느릴 수 있습니다. (그러나 이것은 또한 중요하지 않을 수 있습니다. 오픈은 한 번 실행될 때마다 수행되어야하기 때문입니다.) 실제 퍼프 (perf) 차이는 제외하고. – hyc

+1

InfluxDB는 LMDB를 사용할 수있는 시계열 데이터베이스입니다. http://influxdb.com/blog/2014/06/20/leveldb_vs_rocksdb_vs_hyperleveldb_vs_lmdb_performance.html LMDB의 Sorted Duplicates 기능을 사용하면 시간과 공간을 절약 할 수 있습니다. 그들의 게시물. – hyc