Массивные БД и MySQL

Question

Новый проект, над которым мы работаем, потребовал много анализа данных, но мы считаем, что он ОЧЕНЬ медленный, мы ищем способы изменить наш подход с помощью программного и / или аппаратного обеспечения.

В настоящее время мы используем экземпляр amazon ec2 (linux):

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

Одна часть базы данных - это статьи, сущности и таблица ссылок, например:

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)

Как вы можете видеть из таблицы ниже, у нас есть множество предложений, растущих со скоростью 100 000+ в день

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)

Что нам следует подумать, чтобы улучшить время поиска?Различная БД для хранения?Разное железо.

Answer 1

Как спросил mrorigo, укажите 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 является частью многостолбцового индекса, но не является самым левым столбцом этого индекса, тогда индекс не используется для вашего запроса.

Это распространенная проблема, которую часто упускают из виду.

Answer 2

Использование char (36) для ключей - не самое быстрое использование MySQL.Используйте INT-типы для ключей, если это возможно.Если вы индексируете столбцы CHAR, индексы будут ОЧЕНЬ большими по сравнению с (БОЛЬШИМ) индексом INT (если не «правильно» создан)

Однако, если значения столбцов не являются числовыми, вы застряли в столбцах CHAR(которые все еще быстрее, чем VARCHAR, но могут создавать большие индексы).

Пожалуйста, предоставьте SHOW CREATE TABLE таблиц для просмотра ключевых / индексных параметров, а также, как было сказано в предыдущем ответе, EXPLAIN для рассматриваемых запросов может помочь дать лучший ответ.

PS,Используйте SHOW TABLE STATUS LIKE '{table_name}', чтобы увидеть размеры индекса (и данных) таблицы.

Answer 3

Для производительности запросов важны три вещи:

Индексы.Объем памяти.Все остальное.

Первое, что нужно сделать, это проверить ваши индексы.Сделайте EXPLAIN для ваших запросов, чтобы узнать, как MySQL обрабатывает их.

Если это выглядит разумно, то в следующем случае следует проверить память.Насколько велика ваша общая база данных?В наши дни память дешева, и запросы, выполняемые из памяти, будут намного, намного быстрее, чем запросы, которые должны считываться с диска.

После того, как вы их изучите, если производительность все еще низкая, тогда это может бытьвремя рассмотреть другие варианты.