많은 수의 열을 저장하는 좋은 방법은 무엇입니까?

이 데이터를 데이터베이스에 저장하는 방법을 결정하는 데 문제가 있습니다. 가장 좋은 방법은 무엇입니까? 나는 데이터베이스에 대해 많은 것을 알지 못한다.

형식이 지정된 데이터가 있지만 4가 아닌 열 수는 약 240이므로 각 날짜에는 240 개의 고유 값이 있습니다.

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

또한 행은 DataSites와 연관됩니다.

내 첫 번째 생각은 DataID (pk), DataSiteID, ParameterID, Date, Value, DataSite, Parameter 및 Date에 대한 인덱스가있는 테이블을 갖는 것입니다. ParameterID는 입력 열 헤더 (200,00 202,50 205,00 ...)를 저장하는 다른 테이블을 나타냅니다.

나의 두 번째 생각은 단순히 240- 홀수 열이 모두있는 테이블을 갖는 것이었다. 나는 몇 가지 다른 방법을 생각해 냈지만 꽤 불만족 스럽다.

첫 번째 솔루션에 대한 문제 (거대한 문제는 아니지만 마음에 들지 않음)는 Date 및 DataSiteID가 해당 입력 행의 모든 ​​240 값에 대해 반복되므로 상당히 많이 사용한다는 것입니다 여분의 공간.

매년 약 40GB의 데이터가 위의 텍스트 형식으로 제공되며 DataSite, Parameter 및 Date로 데이터를 검색합니다. 들어오는 데이터의 양은 1 년 정도 4 배가 될 것입니다.

좋은 아이디어가 있습니까? 고마워, 제임스

편집 : 열이 다른 파장에서 측정되는 시계열 데이터입니다. 데이터는 비교적 좁은 범위의 파장 내에서 분석되기를 원할 것입니다. 향후 어느 시점에 추가 파장이 추가 될 수도 있습니다.

편집 : 답변을 주셔서 감사합니다, 정말 고맙습니다 :) 아마 500gb 정도의 테스트 데이터로 실험을 실행할 시간을 찾을 수 있다고 생각합니다. 나는 어떤 결론으로 ​​다시 게시 할 것이다.;)

어느 쪽이든 사례를 만들 수는 있지만 데이터를 분석에 사용하고 종종 해당 데이터에서 여러 열을 동시에 보려면 넓은 테이블로 이동하십시오. 데이터베이스 열 수량 및 행 크기 제한을 알고 있어야합니다. 데이터 유형이 올바른지 확인하십시오. 많은 열이 null이면 SQL Server를 통해 해당 테이블을 최적화 할 수 있습니다. 이 유형의 데이터 분석을 위해 NOSQL (SQL뿐만 아니라) 솔루션 사용을 고려할 수도 있습니다.

이 데이터가 분석에 덜 사용되는 경우 질문에 명시된대로 데이터를 정규화 할 수 있습니다.

나는 당신과 매우 비슷한 상황을 겪었습니다. 일년에 30-50GB의 257 개의 필드가 들어 왔습니다. SQL Server에서 하나의 긴 큰 보이 테이블을 간단하게 유지했습니다. 내 데이터는 공정하게 쿼리되었지만 주로 날짜에 따라 잘 작동했습니다.

나는 데이터를 논리적으로 작은 척 (50 개 정도의 그룹)으로 나눌 수 있었지만이 경우 실제로 이점이별로 없었기 때문에 귀찮게했습니다.

내가 지금 기분이 좋으면 이론에 더 적합한 NoSQL 옵션을 고려할 수도 있지만, 미션 크리티컬 데이터를 사용하여 새로운 것을 시도하는 것이 항상 신경에 좋은 것은 아닙니다.

따라서 시간을내어 여유 시간을 얻었을 때 500GB의 데이터로 테스트 테이블을 채우고 테이블을 다음과 같이 정리했습니다.

내 첫 번째 생각은 DataID (pk), DataSiteID, ParameterID, Date, Value, DataSite, Parameter 및 Date에 대한 인덱스가있는 테이블을 갖는 것입니다. ParameterID는 입력 열 헤더 (200,00 202,50 205,00 ...)를 저장하는 다른 테이블을 나타냅니다.

데이터베이스 설정은 3GB 램이있는 구형 듀얼 코어 머신에 표준 PostgreSQL 설치였습니다. DataSite Date 및 ParameterID로 데이터를 선택하고 1 시간, 1 일 동안 데이터를 평균화하고 새로운 데이터 청크를 삽입하는 수십 가지 쿼리를 실행했습니다. 메모리에서 모든 쿼리를 실행하는 데 1 초도 걸리지 않았습니다. 그것은 내가 예상했던 것보다 훨씬 빠르며 꽤 유용했습니다. 내가 생각하지 않은 한 가지 방법은 테이블이 인덱스 된 인덱스 파일의 크기가 거의 500GB이므로 240 열 너비의 테이블을 사용하면 많은 디스크 공간을 절약 할 수 있다는 것입니다.

Postgres에서는 Oracle 의 배열 유형 또는 varray를 사용 하여이 문제를 우아하게 해결합니다 .

그것이 귀하의 문제에 유용한 지 모르겠지만 열에 대해서는 직접 요청을 할 필요가 없으며 (내 위치에 넣지 않은 콜) 일부는 모든 정보를 원할 때만 정보를 제공합니다 특정 행을 블로그 형식 JSON 형식으로 결합합니다.

쿼리 된 parameter_ids의 분포에 따라 디자인의 최종 결정을 내릴 것입니다. 즉, 거의 독점적으로 쿼리되는 parameter_id가 몇 개 있으면 값을 핫 테이블 에, 나머지 값을 다른 콜드 테이블에 넣 습니다 .

Otoh, 쿼리 배포가 다소 균등 한 경우 레코드 / db 블록 간의 비율이 무엇인지 확인하기 위해 하나의 레코드가 모든 값을 유지하는 테이블에 며칠 가치있는 샘플 세트를로드합니다. 도있다 체인 행 ) 가능성이 문제는. 이에 따라 추가 설계 결정을 내릴 것입니다.

글쎄, 그것을 읽은 후에는 아마도 두 가지 접근법을 동시에 병렬로 수행 할 것입니다.

나는 질문을 다시 읽었습니다.이 정확한 경우 입력으로 얻는 각 레코드마다 다른 값이 추적됩니다 (ParameterID에 따라).

ParameterID는 입력 열 헤더 (200,00 202,50 205,00 ...)를 저장하는 다른 테이블을 나타냅니다.

... 데이터와의 상호 작용 방식에 대해 잘 모르겠지만 다른 옵션을 사용하는 경향이 있습니다. 각 매개 변수 ID에 대해 별도의 테이블이 있고 필요한 경우보기가 있습니다. 날짜와 위치별로 다양한 매개 변수를 더 넓은 (240 열) 테이블에 결합합니다. 뷰에서 DataID를 액세스 가능하게 유지해야하는 경우을 사용하는 UNION대신을 사용할 수 JOIN있지만 열이 희소하게 채워집니다.