Как ускорить запросы к большой таблице из 220 миллионов строк (данные 9 ГБ)?

Проблема:

У нас есть социальный сайт, где участники могут оценивать друг друга для совместимости или соответствия. Эта user_match_ratingsтаблица содержит более 220 миллионов строк (данные по 9 ГБ или почти 20 ГБ по индексам). Запросы к этой таблице обычно отображаются в slow.log (порог> 2 секунды) и являются наиболее часто регистрируемым медленным запросом в системе:

Query_time: 3  Lock_time: 0  Rows_sent: 3  Rows_examined: 1051
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 395357 group by rating;"

Query_time: 4  Lock_time: 0  Rows_sent: 3  Rows_examined: 1294
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 4182969 group by rating;"

Query_time: 3  Lock_time: 0  Rows_sent: 3  Rows_examined: 446
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 630148 group by rating;"

Query_time: 5  Lock_time: 0  Rows_sent: 3  Rows_examined: 3788
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 1835698 group by rating;"

Query_time: 17  Lock_time: 0  Rows_sent: 3  Rows_examined: 4311
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 1269322 group by rating;"

Версия MySQL:

• версия протокола: 10
• версия: 5.0.77-log
• версия bdb: Программное обеспечение Sleepycat: Беркли DB 4.1.24: (29 января 2009 г.)
• машина компиляции версии: x86_64 version_compile_os: redhat-linux-gnu

Информация о таблице:

SHOW COLUMNS FROM user_match_ratings;

дает:

╔═══════════════╦════════════╦════╦═════╦════════╦════════════════╗
║ id            ║ int(11)    ║ NO ║ PRI ║ NULL   ║ auto_increment ║
║ rater_user_id ║ int(11)    ║ NO ║ MUL ║ NULL   ║                ║
║ rated_user_id ║ int(11)    ║ NO ║ MUL ║ NULL   ║                ║
║ rating        ║ varchar(1) ║ NO ║     ║ NULL   ║                ║
║ created_at    ║ datetime   ║ NO ║     ║ NULL   ║                ║
╚═══════════════╩════════════╩════╩═════╩════════╩════════════════╝

Пример запроса:

select * from mutual_match_ratings where id=221673540;

дает:

╔═══════════╦═══════════════╦═══════════════╦════════╦══════════════════════╗
║ id        ║ rater_user_id ║ rated_user_id ║ rating ║ created_at           ║
╠═══════════╬═══════════════╬═══════════════╬════════╬══════════════════════╣
║ 221673540 ║ 5699713       ║ 3890950       ║ N      ║ 2013-04-09 13:00:38  ║
╚═══════════╩═══════════════╩═══════════════╩════════╩══════════════════════╝

Индексы

Таблица имеет 3 настроенных индекса:

1. единый индекс на rated_user_id
2. составной индекс на rater_user_idиcreated_at
3. составной индекс на rated_user_idиrater_user_id

показать индекс из user_match_ratings;

дает:

╔════════════════════╦════════════╦═══════════════════════════╦══════════════╦═══════════════╦═══════════╦═════════════╦══════════╦════════╦═════════════════════════╦════════════╦══════════════════╗
║ Table              ║ Non_unique ║ Key_name                  ║ Seq_in_index ║ Column_name   ║ Collation ║ Cardinality ║ Sub_part ║ Packed ║ Null                    ║ Index_type ║ Comment          ║
╠════════════════════╬════════════╬═══════════════════════════╬══════════════╬═══════════════╬═══════════╬═════════════╬══════════╬════════╬═════════════════════════╬════════════╬══════════════════╣
║ user_match_ratings ║ 0          ║ PRIMARY                   ║ 1            ║ id            ║ A         ║ 220781193   ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
║ user_match_ratings ║ 1          ║ user_match_ratings_index1 ║ 1            ║ rater_user_id ║ A         ║ 11039059    ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
║ user_match_ratings ║ 1          ║ user_match_ratings_index1 ║ 2            ║ created_at    ║ A         ║ 220781193   ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
║ user_match_ratings ║ 1          ║ user_match_ratings_index2 ║ 1            ║ rated_user_id ║ A         ║ 4014203     ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
║ user_match_ratings ║ 1          ║ user_match_ratings_index2 ║ 2            ║ rater_user_id ║ A         ║ 220781193   ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
║ user_match_ratings ║ 1          ║ user_match_ratings_index3 ║ 1            ║ rated_user_id ║ A         ║ 2480687     ║ NULL     ║ NULL   ║ BTREE                   ║            ║                  ║
╚════════════════════╩════════════╩═══════════════════════════╩══════════════╩═══════════════╩═══════════╩═════════════╩══════════╩════════╩═════════════════════════╩════════════╩══════════════════╝

Даже с индексами эти запросы медленные.

Мой вопрос:

Будет ли разделение этой таблицы / данных в другой базе данных на сервере, на котором достаточно оперативной памяти для хранения этих данных в памяти, ускорит ли это эти запросы? Есть ли что-то в таблицах / индексах, которые мы можем улучшить, чтобы сделать эти запросы быстрее?

В настоящее время у нас есть 16 ГБ памяти; однако мы рассматриваем либо модернизацию существующей машины до 32 ГБ, либо добавление новой машины, по крайней мере, с таким большим, может быть, твердотельным накопителем.

Мысли по этому вопросу, выброшенные в случайном порядке:

• Очевидный индекс для этого запроса: (rated_user_id, rating). Запрос, который получает данные только для одного из миллиона пользователей и требует 17 секунд, делает что-то не так: читает из (rated_user_id, rater_user_id)индекса, а затем читает из таблицы (от сотен до тысяч) значений для ratingстолбца, чего ratingнет в любом индексе. Таким образом, запрос должен прочитать много строк таблицы, которые расположены в разных местах диска.

• Прежде чем приступить к добавлению многочисленных индексов в таблицы, попробуйте проанализировать производительность всей базы данных, весь набор медленных запросов, еще раз проверить выбор типов данных, используемый вами механизм и параметры конфигурации.

• Подумайте о переходе на более новую версию MySQL, 5.1, 5.5 или даже 5.6 (также: версии Percona и MariaDB.) Несколько преимуществ, поскольку исправлены ошибки, улучшен оптимизатор, и вы можете установить низкий порог для медленных запросов менее 1 секунды. (как 10 миллисекунд). Это даст вам гораздо лучшую информацию о медленных запросах.

• Выбор типа данных ratingстранный. VARCHAR(1)? Почему нет CHAR(1)? Почему нет TINYINT? Это сэкономит вам немного места, как в таблице, так и в индексах, которые (будут) включать этот столбец. Столбцу varchar (1) требуется еще один байт по сравнению с char (1), и если они имеют значение utf8, столбцам (var) char потребуется 3 (или 4) байта вместо 1 (tinyint).

Я занимался таблицами для правительства Германии, иногда с 60 миллионами записей.

У нас было много этих таблиц.

И нам нужно было много раз узнать общее количество строк в таблице.

Поговорив с программистами Oracle и Microsoft, мы не были так счастливы ...

Таким образом, мы, группа программистов баз данных, решили, что в каждой таблице есть запись, всегда одна запись, в которой хранится общее количество записей. Мы обновили это число, в зависимости от строк INSERT или DELETE.

Мы перепробовали все другие способы. Это, безусловно, самый быстрый способ.

Мы используем этот способ с 1998 года и никогда не имели неправильного количества строк во всех наших многомиллионных таблицах записей.

Я постараюсь разделить на рейтинговые типы, как:

mutat_match_ratings_N, mutat_match_ratings_S и т. д.

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

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

Если это так, вам следует искать другой подход или поддерживать две копии таблицы (исходную таблицу и секционированные), если это доступно с точки зрения пространства и удобства обслуживания (или логики приложения).