2014-07-08 2 views
1

저는 데이터베이스 전문가가 아니므로 조금만 도와 드리겠습니다. 나는 측정 된 데이터를 가지고 있으며 데이터 조작에 도움을 원한다. 여기 내 상황이 있습니다 : cca 10 개의 방송국이 매일 측정됩니다. 매일, cca 3000 행 (cca 15 열 포함)의 데이터가 생성됩니다. 매일 모든 스테이션에서 중앙 서버로 데이터를 다운로드해야합니다. 이는 cca 30 000이 매일 데이터베이스에 삽입 된 행을 의미합니다. (매일 카운트가 바뀔 수 있습니다)bigdata 용 MySQL 데이터베이스 디자인

이제 저는 지난 몇 년 동안의 데이터를 얻었습니다. 따라서 모든 스테이션에 대해 몇 백만 개의 행이 있습니다. 또한 cca 20 "dead"스테이션이 있습니다. 더 이상 작동하지 않지만 몇 년 후의 데이터가 있습니다. 이 값을 모두 합하면 cca가 30 개 스테이션에서 생성되고 50,000,000 개 행이 생성되고 cca 30,000 행은 매일 삽입됩니다. 먼저 데이터베이스에 100 만 개의 행을 가정 해 봅시다.

제 질문은 분명합니다.이 데이터를 어떻게 저장 하시겠습니까? 측정 값 (열)은 숫자 (int 또는 double + datetime)입니다. 텍스트 또는 전체 텍스트 검색은 기본적으로 필요한 유일한 인덱스는 DATETIME입니다. 데이터가 업데이트되거나 삭제되지 않습니다. (예 : 1.1.2010에서 3.2.2010까지)

그래서 제가 썼을 때, 제가 가장 잘 알고있는 데이터베이스이기 때문에 저는 MySQL을 사용하고 싶습니다. 나는이 양의 데이터를 쉽게 처리해야한다는 것을 읽었지만, 아직도이 상황에 대한 어떤 제안도 고맙게 생각합니다. 는 다시 :

  • 10 연, 하루에 3000 개 행이 각 => 하루 CCA (30 개) 000 삽입 아직 행의 40 ~ 50 개 수백만 바이너리 파일
  • 에서 삽입 할
  • CCA는
  • DB는 증가 할 것입니다 (100 만 개가 넘는 행)
  • 필요한 것은 가능한 한 빨리 데이터를 선택하는 것입니다.

내가 아는 한, MySQL은이 양의 데이터를 처리해야합니다. 나는 또한 내 유일한 인덱스가 DATETIME 타입의 날짜와 시간이 될 것이라는 것을 알고있다. (더 빠르게해야한다.) 내가 결정할 수없는 것은 50+ 수백만 개의 행을 가진 하나의 거대한 테이블을 만들지 여부이다. 스테이션 ID로), 또는 모든 스테이션에 대해 별도로 테이블을 생성하십시오. 기본적으로이 스테이션에서 JOIN을 수행 할 필요가 없습니다. 시간의 일치가 필요한 경우 스테이션에서 동일한 시간 범위를 선택할 수 있습니다. 이러한 접근법에 불만이 있습니까?

누구든지 내 생각을 확인/거절 할 수 있습니까? 더 나은 해결책이 있다고 생각하십니까? 도움이나 토론에 감사드립니다.

+1

이 CCA 란 무엇입니까? –

+1

나는 그가 "주변"또는 "대략"에 대한 라틴어 인 "circa"를 의미한다고 생각한다. –

+0

1 백만 행은 작지는 않지만 요즘에는 "큰 데이터"로 간주되지 않습니다.) –

답변

0

MySQL이이를 잘 처리 할 수 ​​있어야합니다. 대신 색인 당신의 DATETIME 열, 나는 다음과 같이 두 개의 복합 인덱스를 생성 제안 :

(datetime, station) 
(station, datetime) 

그 반대의 경우도 마찬가지 스테이션 또는 날짜 범위 및 그룹을 선택 쿼리를 가속화 할 것이다 장소에 두 가지 인덱스를 가졌어요. 첫 번째 색인은 색인 생성 datetime이 제공하는 목적에도 부합합니다.

일반적인 검색어가 무엇인지 알려주지 않았습니다. 또한 오래된 데이터를 삭제할지 여부를 알려주지 않았습니다. 데이터는 범위 파티셔닝 (http://dev.mysql.com/doc/refman/5.6/en/partitioning-range.html)의 확실한 후보이지만 실행 가능한 파티셔닝 기준을 설계하는 데 도움이되는 정보가 더 필요합니다.

의견을 읽은 후을 편집하십시오.

이 시스템을 구축 할 때 염두에 두어야 할 몇 가지 사항이 있습니다.

먼저 파티션을 신경 쓰지 마십시오.

둘째, 모든 테이블을 하나의 테이블로 처리 할 수 ​​있습니다. 역이나 해에 물건을 나누지 마십시오. 자신이 MySQL 서버에 사용할 수있는 가장 빠른 디스크 스토리지 시스템과 많은 RAM을 확보하십시오.

셋째로 잠시 휴식을 취하여 OPTIMIZE TABLE을 수행하십시오. 이것은 귀하의 색인이 좋은지 확인합니다.

넷째, 표의 모든 열이 필요하다는 점을 알지 못한다면 SELECT *을 사용하지 마십시오. 왜?

 SELECT datetime, station, temp, dewpoint 
     FROM table 
     WHERE datetime >= DATE(NOW() - INTERVAL 60 DAY) 
     ORDER BY station, datetime 

는 랜덤 액세스 테이블에

 (station, datetime, temp, dewpoint) 

반면
 SELECT * 
     FROM table 
     WHERE datetime >= DATE(NOW() - INTERVAL 60 DAY) 
     ORDER BY station, datetime 

필요에 인덱스를 포함하는 화합물로 순차 액세스에서 직접 만족시킬 수 있기 때문이다. 복합재 커버 인덱스에 대해 읽어야합니다.

다섯째, WHERE 절에 열 이름이있는 함수를 사용하지 마십시오. 말하지 마시오.

 WHERE YEAR(datetime) >= 2003 

또는 그와 비슷한 내용을 말하지 마십시오. MySQL은 그러한 종류의 쿼리에 대해 인덱스를 사용할 수 없습니다. 대신 색인을 이용할 수 있도록

 WHERE datetime >= '2003-01-01' 

이라고 말하십시오.

+0

내 일반적인 쿼리는'SELECT * FROM station1_data WHERE datetime BETWEEN'입니다. 모든 것이 거대한 테이블이라면,'SELECT * FROM data WHERE datetime BETWEEN ... AND station_id = 1'입니다. 오래된 데이터를 오래된 것으로 간주해서는 안됩니다. 그들은 여기에 있으며 새로운만큼 유용합니다. 사람들은 데이터를 처리하고 사용 가능한 모든 것을 원합니다. 아시다시피 station_id가있는 거대한 테이블 하나를 제안 하시겠습니까? 칭찬은 흥미 롭습니다. 나는 그것에 대해 몰랐습니다. station_id에서 파티셔닝하는 것이 도움이 될까요? –

관련 문제