시계열 : SQL 또는 NoSQL?

SQL과 NoSQL의 일반적인 차이점 (또는 전통적인 차이점)에 대해서는 신경 쓰지 않습니다.

현재 내부 시계열의 저장 공간을 변경하려고합니다. 여기에는 여러 가지 다른 출처의 재무 데이터가 포함되어 있습니다. 현재 데이터를 독점 데이터베이스에 저장하고 있습니다. 자체 쿼리 언어가있는 것은 NoSQL입니다.

커뮤니티 입력에 관심이 있습니다. SQL 데이터베이스에 데이터를 어떻게 저장 하시겠습니까? NoSQL에서 SQL을 사용할 때 특히 시계열에 어떤 장점이 있습니까? 이것을 SQL에 저장하는 것을 고려해 본 적이 있습니까?

우리의 데이터 세트는 수백만 개의 시계열로 구성되며이 중 약 10 %는 각각 수백만 개의 레코드를 포함합니다. 시계열은 계층 적으로 구성됩니다. / Market / Instrument / Value / Frequency, 여기서 :

• 시장은 증권 거래소 등 기본적으로 상품의 모음이며 일반적으로 유사한 상품입니다.
• 기기는 기기입니다. 지표 (Brent Crude), 주식 (GOOG) 등이 될 수 있습니다.
• 값은 장비에 대한 여러 유형의 데이터 중 하나입니다. 이것은 근접, 높음, 낮음 등일 수 있습니다.
• 빈도는 특정 시계열 값의 빈도입니다. 매주, 매일, 매월, 진드기, 임의 등

데이터는 SQL DB에 어떻게 저장됩니까? 하나의 큰 테이블 (어쩌면 무언가에 의해 분할 될 수 있음), 시장 또는 계측기 당 하나의 테이블, 시계열 당 하나의 테이블.

미리 감사드립니다.

일반적으로 이러한 구조화 된 데이터 세트의 경우 대부분의 일상 작업 (즉, 임의의 시간에서 작은 데이터 가져 오기)에 대해 더 빠른 사용자 정의 데이터 형식을 작성할 수 있다고 생각합니다. 표준 DB 도구로 전환하면 이점은 임시 쿼리, 다중 액세스, 복제, 가용성 등과 같은 일부 추가 기능에있을 수 있습니다. 표준 기반 데이터 저장소를 유지 관리하는 데 도움을주는 것도 더 쉽습니다.

해당 데이터를 저장하기 위해 데이터베이스를 설정하라는 요청을 받으면 다음을 수행합니다.

제안 된 스키마

(1) 코어 데이터는 각각 두 개의 열을 포함하는 수많은 (1000) 개별 테이블에 배치됩니다.

1. 시간 : SQL DATETIME 데이터 유형 또는 일부 신기원의 숫자 유형 (기본 키)
2. 값 : 데이터에 맞게 입력하십시오. 기본적으로 단 정밀도 부동 소수점을 사용하지만 고정 소수점 데이터 유형이 금융 거래에 더 적합 할 수 있습니다. 이것은 아마도 색인화되지 않은 것입니다.

이 테이블은 상당히 커질 수 있으며 연도별로 수동으로 파티션을 나눌 수 있습니다. 그러나 시스템 성능을 확인하고 적절하게 조정해야합니다.

이 테이블에는 고유 한 이름이 필요하며 몇 가지 옵션이 있습니다. 그것들은 사람이 읽을 수 있거나 (예 : nyse_goog_dailyhighs_2010) 또는 (내 선호도) 무작위 일 수 있습니다. 어떤 방법 으로든 메타 데이터 테이블 세트가 필요하고 임의의 테이블 이름을 사용하면 개발자가 의도하지 않은 이름으로 이름을 추론 할 수 없습니다.

(2) 메타 데이터는 응용 프로그램의 요구에 따라 별도의 테이블에 저장됩니다 .

메타 데이터를 추적하려면 추가 테이블 또는 테이블 세트가 필요합니다. 이 표에는 교환, 기기, 가치, 빈도, 날짜 범위, 출처 (데이터 출처) 및 기타 필요한 정보가 포함됩니다. 이들은 데이터 테이블 이름에 매핑됩니다.

충분한 데이터가있는 경우이 조회는 실제로 테이블 이름과 데이터베이스 이름을 제공하여 자체 구현 된 데이터 샤딩 (용어의 올바른 사용 인 경우)을 허용합니다. 그러나 나는 그것을 준비 상태로 유지할 것입니다.

그런 다음 응용 프로그램 계층에서 메타 데이터 테이블을 쿼리하여 내 데이터의 위치를 ​​확인한 다음 빅 데이터 테이블에서 비교적 간단한 쿼리를 수행하여 데이터를 가져옵니다.

장점 :

• 내 (상대적으로 제한된) 경험은 데이터베이스가 일반적으로 적은 수의 큰 테이블보다 많은 수의 작은 테이블을 쉽게 처리 할 수 ​​있다는 것입니다. 이 방법을 사용하면 유지 관리가 더 쉬워집니다 (예 : 오래된 데이터 제거, 손상된 테이블 재 구축, 백업 생성 / 재로드, 새 항목 추가). 예를 들어, 데이터 속도가 다르거 나 다른 데이터 유형이 필요한 경우 다른 종류의 데이터가 완전히 분리됩니다.

• 이 스키니 테이블 개념은 또한 가장 일반적인 쿼리 인 단일 엔터티의 연속적인 데이터 범위에 대해 빠른 디스크 액세스를 허용해야합니다. 대부분의 데이터 응용 프로그램은 디스크 I / O가 제한되어 있으므로 고려해야합니다. 논평자가 이미 암시 한 것처럼, 이것은 열 지향 데이터베이스에 대한 이상적인 응용 프로그램이지만 아직 내 경력에 베팅하기에 충분히 주류 인 열 지향 제품을 찾지 못했습니다. 이 스키마는 매우 가까워집니다.

단점 :

• 디스크 공간의 약 절반은 타임 스탬프를 저장하는 데 사용됩니다. 솔직히 100 또는 1000 테이블의 타임 스탬프 열에 정확히 동일한 데이터가있을 때. (이것은 쉬운 테이블 조인을 수행하려는 경우의 요구 사항입니다).

• 테이블 이름을 저장하고 동적 조회를 수행하려면 많은 응용 프로그램 복잡성과 문자열 작업이 필요합니다. 그러나 여전히 대안보다 낫습니다 (아래에서 논의 됨).

고려 사항 :

• 시간 필드에서 반올림에주의하십시오. 값을 반올림하여 조인 (적절한 경우)을 가능하게 할 수 있지만 모호하지 않을 정도로 정확해야합니다.

• 시간대와 일광 절약 시간에주의하십시오. 이것들은 테스트하기가 어렵습니다. 데이터 저장소에 UTC 요구 사항을 적용하여 인기가 없을 수 있으며 응용 프로그램에서 변환을 처리합니다.

변형 :

내가 고려한 몇 가지 변형은 다음과 같습니다.

데이터 접기 : 시계열의 간격이 동일하면 하나의 타임 스탬프 열과 10 개의 데이터 열을 사용합니다. 타임 스탬프는 이제 첫 번째 데이터 열의 시간을 나타내며 othe 데이터 열은 해당 타임 스탬프와 다음 타임 스탬프 사이의 간격이 동일하다고 가정합니다. 이로 인해 이전에 타임 스탬프를 저장하는 데 사용되었던 많은 스토리지가 상당한 쿼리 및 / 또는 애플리케이션 복잡성의 비용으로 절약됩니다. 연속적인 범위의 단일 엔터티 쿼리는 이제 더 적은 디스크 액세스가 필요합니다.

멀티플렉싱 : 여러 시계열이 동일한 시계열을 사용하는 것으로 알려진 경우 위에서 설명한대로 하나의 타임 스탬프와 (예를 들어) 10 개의 데이터 열을 사용하십시오. 그러나 이제 각 열은 다른 시계열을 나타냅니다. 이를 위해서는 메타 데이터 테이블을 업데이트해야합니다. 메타 데이터 테이블은 테이블 및 열 이름을 조회하지 않습니다. 저장 공간이 줄어 듭니다. 쿼리는 단순하게 유지됩니다. 그러나 연속 범위의 단일 엔터티 쿼리에는 이제 훨씬 더 많은 디스크 액세스가 필요합니다.

메가 테이블 : "멀티플렉싱"개념을 최대한 활용하고 모든 데이터를 열당 한 번 시계열로 한 테이블에 넣습니다. 이를 위해서는 연속 범위의 단일 엔터티 쿼리에 많은 양의 디스크 액세스가 필요하며 유지 관리가 필요하지 않습니다. 예를 들어, 새 엔티티를 추가하려면 많은 TB 테이블에서 MODIFY TABLE 명령이 필요합니다.

이 형식에 대한 자세한 내용은 다음의 다양한 답변을 참조하십시오. MySQL에 너무 많은 열

완전 정규화 된 테이블 : 많은 2 열 테이블을 사용하는 대신 열이 시간, 데이터 ID 및 값인 3 열 테이블 하나를 사용할 수 있습니다. 이제 메타 데이터 테이블은 테이블 이름이나 열 이름이 아닌 ID 값만 조회하면되므로 응용 프로그램 계층이 아닌 SQL 쿼리에 더 많은 논리를 적용 할 수 있습니다.

정규화 열과 함께 약 2/3의 스토리지가 사용되므로 디스크 공간이 많이 사용됩니다.

빠른 연속 단일 엔티티 쿼리에 기본 키 순서 (dataid, timestamp)를 사용할 수 있습니다. 또는 빠른 삽입을 위해 기본 키 순서 (timestamp. dataid)를 사용할 수 있습니다.

그러나 이러한 변형을 고려한 후에도 다음 개발 계획은 각각 2 열씩 많은 테이블입니다. 또는 I :)보다 현명한 사람이 곧 게시 할 방법입니다.

MongoDB를 사용하면 컬렉션을 매우 빠르게 만들 수 있습니다. 데이터를 별도의 데이터베이스와 해당 데이터베이스 내의 컬렉션에 배열하는 것을 살펴보십시오. 빠른 검색이 필요한 경우 각 샤드를 시스템 메모리 내에 유지하기 위해 필요한 메모리 양을 고려하십시오. 사내 솔루션을 고수하는 어리석은 것이 필요한 라인을 따라 진화 할 새로운 것이 있다면. 좋은 이니셔티브처럼 들립니다.