현재 (현재) 약 15,000 개의 제품에 대한 통계 데이터를 가져올 응용 프로그램을 구축 중입니다. 현재, 하나의 소스에서 매일 통계에 대해 하나의 데이터베이스 테이블을 유지한다면, 하루에 15,000 행의 데이터 (행 당 5-10 개의 필드가 주로 float, int라고 함)가 증가합니다. 분명히 1 년에 5 백만 건이 넘는 레코드를 하나의 테이블로 동일시합니다.트렌드 데이터를 저장하는 가장 좋은 방법은 무엇입니까?
다른 소스의 데이터를 가져 와서 새로운 소스마다 5 백만 개의 레코드 크기를 늘릴 생각만큼 큰 문제는 아닙니다.
이제 데이터는 통계/추세 기반 데이터이며 기본적으로 레코드 당 1 회 쓰기 및 많은 읽기가 발생합니다. 비행보고 및 그래프 작업을 위해 규칙 (날짜 범위, 값 범위 등)을 기반으로 데이터의 하위 집합에 대한 빠른 액세스가 필요합니다.
데이터 (MySQL InnoDb 테이블)를 저장하는 가장 좋은 방법은 무엇입니까, 아니면 통계/경향 데이터를 저장하고 처리하는 더 좋은 방법이 있습니까?
기타 옵션 나는이 시점에서 버렸습니다. 1. 여러 데이터베이스 (제품 당 하나). 각 데이터 소스마다 별도의 테이블이 있습니다. 2. 하나의 데이터베이스, 여러 테이블 (각 제품/데이터 소스에 하나씩) (즉, 데이터베이스 : 제품, 테이블 : ProductA_SourceA, ProductA_SourceB) (데이터베이스 : ProductA, 테이블 : Source_A, Source_B, Source_C) 등) 3. factual 또는 데이터베이스의 특정 제품 정보 및 statistical의 데이터가 모두 csv, xml, json (별도의 디렉토리에있는 플랫 파일)입니다.
지금까지는 이러한 옵션 중 아무 것도 관리하기가 쉽지 않으며 각 옵션마다 장단점이 있습니다. 개발 단계의 알파 단계로 넘어 가기 전에 합리적인 해결책이 필요합니다.
컬럼 기반 엔진을 사용하여 MySQL에 대해 이야기하는 PDF를 찾았습니다. http://forge.mysql.com/w/images/5/54/MySQLColumnDatabases.pdf,이 옵션을 좀 더 살펴 보겠습니다. 전에 컬럼 기반 스토리지에 대해 들어 본 적이 없었는데, 이것은 내가 찾고있는 것일 수 있습니다. –