방대한 DB와 mysql

Question

우리가 작업하고있는 새로운 프로젝트는 많은 데이터 분석이 필요했지만 매우 느린 것으로 밝혀졌으며 소프트웨어 또는 하드웨어로 접근 방식을 변경할 방법을 찾고 있습니다.

우리는 현재 (리눅스)는 아마존 EC2 인스턴스에서 실행중인

:

mysql> DESCRIBE articles_entities; 
+------------+--------------+------+-----+---------+-------+ 
| Field  | Type   | Null | Key | Default | Extra | 
+------------+--------------+------+-----+---------+-------+ 
| id   | char(36)  | NO | PRI | NULL |  | 
| article_id | char(36)  | NO | MUL | NULL |  | 
| entity_id | char(36)  | NO | MUL | NULL |  | 
| created | datetime  | YES |  | NULL |  | 
| modified | datetime  | YES |  | NULL |  | 
| relevance | decimal(5,4) | YES | MUL | NULL |  | 
| analysers | text   | YES |  | NULL |  | 
| anchor  | varchar(255) | NO |  | NULL |  | 
+------------+--------------+------+-----+---------+-------+ 
8 rows in set (0.00 sec) 

당신이 할 수 :

DB를의

High-CPU Extra Large Instance 

7 GB of memory 
20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each) 
1690 GB of instance storage 
64-bit platform 
I/O Performance: High 
API name: c1.xlarge 


processor  : 7 
vendor_id  : GenuineIntel 
cpu family  : 6 
model   : 26 
model name  : Intel(R) Xeon(R) CPU   E5506 @ 2.13GHz 
stepping  : 5 
cpu MHz   : 2133.408 
cache size  : 4096 KB 

MemTotal:  7347752 kB 
MemFree:  728860 kB 
Buffers:   40196 kB 
Cached:  2833572 kB 
SwapCached:   0 kB 
Active:  5693656 kB 
Inactive:  456904 kB 
SwapTotal:   0 kB 
SwapFree:   0 kB 

한 부분은 기사와 기업 및 예를 들어, 링크 테이블 아래의 표를 보면 우리는 하루에 10 만회 이상의 비율로 성장하는 많은 물질을 가지고 있습니다.

mysql> SELECT count(*) FROM articles_entities; 
+----------+ 
| count(*) | 
+----------+ 
| 2829138 | 
+----------+ 
1 row in set (0.00 sec) 

아래와 같은 간단한 쿼리가 너무 많은 시간 (12 초)을 복용

mysql> SELECT count(*) FROM articles_entities WHERE relevance <= .4 AND relevance > 0; 
+----------+ 
| count(*) | 
+----------+ 
| 357190 | 
+----------+ 
1 row in set (11.95 sec) 

우리는 우리의 조회 시간을 개선하기 위해 고려되어야한다 무엇

? 다른 DB 스토리지? 다른 하드웨어.

Answer 1

쿼리 성능과 관련하여 중요한 점은 다음과 같습니다.

인덱스. 메모리. 그 밖의 모든 것.

먼저 색인을 확인하십시오. 질의에 대해 EXPLAIN을 수행하여 MySQL이 어떻게 처리하는지 알아보십시오.

그게 합리적으로 보이면 다음으로 메모리를 확인하는 것입니다. 총 데이터베이스의 크기는 얼마나됩니까? 요즘엔 메모리가 저렴하며 메모리에서 실행되는 쿼리는 디스크에서 읽어야하는 쿼리보다 훨씬 빠릅니다.

성능을 여전히 느린 경우 다른 옵션을 고려해야 할 때가 있습니다.

Answer 2

키로 char (36)을 사용하는 것이 MySQL에서 가장 빠르지 않습니다. 가능한 경우 키에 INT 유형을 사용하십시오. CHAR 컬럼을 인덱싱하면 (BIG) INT 인덱스에 비해 인덱스가 매우 큽니다. (적절히 생성되지 않은 경우)

그러나 열 값이 숫자가 아닌 경우 CHAR 열 VARCHAR보다 여전히 빠르지 만 큰 인덱스를 생성 할 수 있음).

키/색인 매개 변수를 보려면 SHOW CREATE TABLE 개의 표를 제공하고 앞의 대답에서 말한 것처럼 질문에 대한 EXPLAIN을 사용하면 더 나은 답변을 얻을 수 있습니다.

추신. 테이블의 인덱스 (및 데이터) 크기를 보려면 SHOW TABLE STATUS LIKE '{table_name}'을 사용하십시오.

Answer 3

mrorigo가 묻는대로 SHOW CREATE TABLE articles_entities을 제공하여 테이블의 실제 색인을 볼 수 있습니다. relevance 멀티 컬럼 인덱스의 일부이지만 해당 인덱스의 가장 왼쪽 열이 아닌 경우 http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

If the table has a multiple-column index, any leftmost prefix of the index can be used by the optimizer to find rows. 
For example, if you have a three-column index on (col1, col2, col3), you have indexed search capabilities on (col1), (col1, col2), and (col1, col2, col3). 

MySQL cannot use an index if the columns do not form a leftmost prefix of the index

그래서 MySQL의 문서에서 메모로

다음 인덱스는 쿼리에 사용되지 않습니다 .

자주 간과되는 공통적 인 문제입니다.