MySQL: Есть ли жизнь после 1 млрд. записей.
0 likes•611 views
Документ обсуждает проблемы, связанные с растущим объемом данных в базе данных MySQL, конкретно в компании Global Fleet Management, которая сталкивается с ~0.9 млн. сообщений в день. Приводятся возможные решения, такие как хранение данных в виде массивов объектов и использование разбиений для управления объемом записей и ускорения выполнения запросов. В заключении описываются результаты оптимизации, включая улучшение скорости запросов и необходимость изменения кода.
MySQL: Есть ли жизнь после 1 млрд. записей.
- 1. MySQL: Есть ли жизнь после 1млрд. записей? Лаухин Роман R&D Lead Global Fleet Management
- 2. О компании Global Fleet Management Inc. #301 - 7 West 7th Avenue Vancouver, BC, Canada http://www.positrace.com
- 3. О компании
- 5. Проблема Рост числа сообщений ~0.9 млн. сообщений в сутки
- 6. Проблема Рост числа сообщений ~0.9 млн. сообщений в сутки ~30 млн. в месяц
- 7. Проблема Рост числа сообщений ~0.9 млн. сообщений в сутки ~30 млн. в месяц ~360 млн. в год
- 8. Проблема Рост числа сообщений ~0.9 млн. сообщений в сутки ~30 млн. в месяц ~360 млн. в год + 15%
- 9. Проблема На "вчерашний" день: rows data size idx size total size GPS_log 1163.45M 105.94G 75.28G 181.21G
- 10. Проблема На "вчерашний" день: rows data size idx size total size GPS_log 1163.45M 105.94G 75.28G 181.21G Events 22.22M 2.17G 2.36G 4.53G Trips 16.02M 1.71G 1.62G 3.33G
- 11. Пути решения Хранить точки как массив объектов (JSON, Protobuf, etc)
- 12. Пути решения Хранить точки как массив объектов (JSON, Protobuf, etc) плюсы: - контролируемый рост числа записей
- 13. Пути решения Хранить точки как массив объектов (JSON, Protobuf, etc) плюсы: - контролируемый рост числа записей - информация о поездке в 1-2 записях
- 14. Пути решения Хранить точки как массив объектов (JSON, Protobuf, etc) минусы: - много изменений в коде
- 15. Пути решения Хранить точки как массив объектов (JSON, Protobuf, etc) минусы: - много изменений в коде - усложняется работа с точками
- 17. Пути решения Использовать "Partitioning" плюсы: - контролируемый рост
- 18. Пути решения Использовать "Partitioning" плюсы: - контролируемый рост - ускорение выполнения запросов
- 19. Пути решения Использовать "Partitioning" плюсы: - контролируемый рост - ускорение выполнения запросов - не требует изменений в коде (теоретически)
- 20. Пути решения Использовать "Partitioning" минусы: - ограничения, связанные с разделами
- 21. Пути решения Использовать "Partitioning" минусы: - ограничения, связанные с разделами - нет опыта
- 22. Пути решения Использовать "Partitioning" минусы: - ограничения, связанные с разделами - нет опыта - страшно :)
- 24. Реализация Анализ ограничений (PK, FK) План разбиения на разделы (дата - ключевой параметр)
- 27. Реализация CREATE TABLE messages_new .... PRIMARY KEY (id, dt) ... PARTITION BY RANGE (TO_DAYS(dt)) ( PARTITION p0801 VALUES LESS THAN (TO_DAYS('2008-02-01')), PARTITION p0802 VALUES LESS THAN (TO_DAYS('2008-03-01')), PARTITION p0803 VALUES LESS THAN (TO_DAYS('2008-04-01')), ... PARTITION p1212 VALUES LESS THAN (MAXVALUE));
- 28. Реализация Копирование данных в новую таблицу.
- 29. Реализация Копирование данных в новую таблицу. - внешним скриптом - малыми порциями (INSERT LOW_PRIORITY ...)
- 30. Реализация RENAME TABLE messages TO messages_old, messages_new TO messages;
- 32. Реализация Анализ первого опыта: - не без проблем (тестовое окружение != production)
- 33. Реализация Анализ первого опыта: - не без проблем (тестовое окружение != production) - скорость выполнения запросов (возросла ~100 раз)
- 34. Реализация Анализ первого опыта: - не без проблем (тестовое окружение != production) - скорость выполнения запросов (возросла ~100 раз) (связано с partitioning только косвенно)
- 35. Реализация Повторили предыдущие шаги для GPS_log и связанных таблиц Алгоритм известен - соли и специй добавить по вкусу :)
- 37. Реализация Удаление старых таблиц DROP TABLE
- 38. Реализация Удаление старых таблиц DROP TABLE
- 39. Реализация Удаление старых таблиц - внешним скриптом
- 40. Реализация Удаление старых таблиц - внешним скриптом - малыми порциями (DELETE LOW_PRIORITY)
- 41. Реализация Удаление старых таблиц - внешним скриптом - малыми порциями (DELETE LOW_PRIORITY) - OPTIMIZE TABLE (в период с минимальной нагрузкой)
- 42. Реализация Удаление старых таблиц - внешним скриптом - малыми порциями (DELETE LOW_PRIORITY) - OPTIMIZE TABLE (в период с минимальной нагрузкой) - DROP TABLE
- 43. Итоги На сегодняшний день: rows data size idx size total size GPS_log 1321.81M 94.11G 112.63G 206.74G
- 44. Итоги Код, таки, пришлось менять :)
- 45. Итоги Код, таки, пришлось менять :) Ограничение по дате (dt) обязательно
- 46. Итоги Код, таки, пришлось менять :) Ограничение по дате (dt) обязательно Не забывать расширять последний раздел
- 47. Итоги Код, таки, пришлось менять :) Ограничение по дате (dt) обязательно Не забывать расширять последний раздел Помнить про файловую систему
- 49. Полезности EXPLAIN PARTITIONS .... id select_type table partitions type .... Extra 1 SIMPLE l p0xx,p1202 ALL ... Using where; Using filesort
- 50. Полезности INFORMATION_SCHEMA - наш друг
- 51. Полезности INFORMATION_SCHEMA - наш друг SELECT concat(table_schema,'.',table_name), concat(round(table_rows/1000000,2),'M') rows, concat(round(data_length/(1024*1024*1024),2),'G') DATA, concat(round(index_length/(1024*1024*1024),2),'G') idx, concat(round((data_length+index_length)/(1024*1024*1024),2),'G') total_size, round(index_length/data_length,2) idxfrac FROM information_schema.TABLES ORDER BY data_length+index_length DESC LIMIT 20;
- 52. Полезности INFORMATION_SCHEMA - наш друг name rows data idx total table_1 1329.84M 94.29G 112.84G 207.13G table_2 1314.38M 105.94G 75.28G 181.21G table_3 221.73M 34.86G 17.09G 51.96G table_4 161.92M 13.02G 10.19G 23.21G table_5 8.07M 18.58G 0.16G 18.74G
- 53. Вопросы?
- 54. Ресурсы MySQL 5.1 Reference Manual :: 18 Partitioning http://dev.mysql.com/doc/refman/5.1/en/partitioning.html