Massive DBとmysql

Question

私たちが取り組んでいる新しいプロジェクトでは、多くのデータ分析が必要でしたが、これは非常に遅いと感じています。ソフトウェアやハードウェアでアプローチを変更する方法を探しています。我々は現在のAmazon EC2インスタンス（Linux）の上で実行されている

：

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) 

することができますように：デシベルの

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 

一部は記事やエンティティと例えばリンクテーブルです下記の表から、1日あたり10万以上の率で成長する多くの物質があることを確認してください。

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

以下のような単純なクエリでは、我々は、ルックアップ時間を改善するために何を考慮しなければならない

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

あまりにも多くの時間（12秒）を取っていますか？異なるDBストレージ？異なるハードウェア

Answer 1

クエリのパフォーマンスに関して重要な点は、次の3つです。

インデックス。 メモリ。 他のすべて。

最初に行うことは、インデックスを確認することです。クエリーでEXPLAINを実行して、MySQLがどのように処理しているかを調べてください。

それが賢明なら、次はメモリをチェックすることです。あなたの合計データベースの量はどれくらいですか？メモリは最近安く、メモリから実行されるクエリは、ディスクから読み取らなければならないクエリよりはるかに高速です。

パフォーマンスをまだ見ていない場合は、他のオプションも検討する必要があります。

Answer 2

キーでchar（36）を使用するのは、MySQLでできる最速の方法ではありません。可能であれば、キーにはINT型を使用してください。 CHARカラムのインデックスを作成すると、インデックスは（BIG）INTインデックスに比べて非常に大きくなります（正しく作成されていない場合）

ただし、カラム値が数値でない場合、CHARカラムVARCHARよりも高速ですが、大きな索引を作成することができます）。

キー/インデックスのパラメータを確認するためにテーブルのSHOW CREATE TABLEを指定してください。また、前の回答で述べたように、問題のクエリのEXPLAINを使用するとより良い回答が得られます。

PS。テーブルのインデックス（およびデータ）サイズを確認するにはSHOW TABLE STATUS LIKE '{table_name}'を使用してください。

Answer 3

私があなたのテーブルの実際のインデックスを見ることができるように、SHOW CREATE TABLE articles_entitiesを提供してください。

MySQLのドキュメントからノート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

だからrelevanceがマルチカラムインデックスの一部ですが、そのインデックスの左端の列でない場合、インデックスがクエリに使用されていないと。

これはよく見落とされる一般的な問題です。