MySQL: Есть ли жизнь после 1 млрд. записей.

Post on 28-Nov-2014

725 views 1 download

description

Роман Лаухин, Lead Software developer at Positrace.

Transcript of MySQL: Есть ли жизнь после 1 млрд. записей.

MySQL:

Есть ли жизнь после

1млрд. записей?

Лаухин Роман

R&D Lead

Global Fleet Management

О компании

Global Fleet Management Inc.

#301 - 7 West 7th Avenue

Vancouver, BC, Canada

http://www.positrace.com

О компании

Проблема

Рост числа сообщений

Проблема

Рост числа сообщений

~0.9 млн. сообщений в сутки

Проблема

Рост числа сообщений

~0.9 млн. сообщений в сутки

~30 млн. в месяц

Проблема

Рост числа сообщений

~0.9 млн. сообщений в сутки

~30 млн. в месяц

~360 млн. в год

Проблема

Рост числа сообщений

~0.9 млн. сообщений в сутки

~30 млн. в месяц

~360 млн. в год

+ 15%

Проблема

На "вчерашний" день:

rows data size idx size total size

GPS_log 1163.45M 105.94G 75.28G 181.21G

Проблема

На "вчерашний" день:

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

Пути решения

Хранить точки как массив объектов

(JSON, Protobuf, etc)

Пути решения

Хранить точки как массив объектов

(JSON, Protobuf, etc)

плюсы:

- контролируемый рост числа записей

Пути решения

Хранить точки как массив объектов

(JSON, Protobuf, etc)

плюсы:

- контролируемый рост числа записей

- информация о поездке в 1-2 записях

Пути решения

Хранить точки как массив объектов

(JSON, Protobuf, etc)

минусы:

- много изменений в коде

Пути решения

Хранить точки как массив объектов

(JSON, Protobuf, etc)

минусы:

- много изменений в коде

- усложняется работа с точками

Пути решения

Использовать "Partitioning"

Пути решения

Использовать "Partitioning"

плюсы:

- контролируемый рост

Пути решения

Использовать "Partitioning"

плюсы:

- контролируемый рост

- ускорение выполнения запросов

Пути решения

Использовать "Partitioning"

плюсы:

- контролируемый рост

- ускорение выполнения запросов

- не требует изменений в коде

(теоретически)

Пути решения

Использовать "Partitioning"

минусы:

- ограничения, связанные с разделами

Пути решения

Использовать "Partitioning"

минусы:

- ограничения, связанные с разделами

- нет опыта

Пути решения

Использовать "Partitioning"

минусы:

- ограничения, связанные с разделами

- нет опыта

- страшно :)

Реализация

Анализ ограничений

(PK, FK)

Реализация

Анализ ограничений

(PK, FK)

План разбиения на разделы

(дата - ключевой параметр)

Реализация

ALTER TABLE ???

Реализация

ALTER TABLE !!!

Реализация

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));

Реализация

Копирование данных в новую таблицу.

Реализация

Копирование данных в новую таблицу.

- внешним скриптом

- малыми порциями

(INSERT LOW_PRIORITY ...)

Реализация

RENAME TABLE

messages TO messages_old,

messages_new TO messages;

Реализация

Анализ первого опыта:

Реализация

Анализ первого опыта:

- не без проблем

(тестовое окружение != production)

Реализация

Анализ первого опыта:

- не без проблем

(тестовое окружение != production)

- скорость выполнения запросов

(возросла ~100 раз)

Реализация

Анализ первого опыта:

- не без проблем

(тестовое окружение != production)

- скорость выполнения запросов

(возросла ~100 раз)

(связано с partitioning только косвенно)

Реализация

Повторили предыдущие шаги для GPS_log и

связанных таблиц

Алгоритм известен -

соли и специй добавить по вкусу :)

Реализация

Удаление старых таблиц

Реализация

Удаление старых таблиц

DROP TABLE

Реализация

Удаление старых таблиц

DROP TABLE

Реализация

Удаление старых таблиц

- внешним скриптом

Реализация

Удаление старых таблиц

- внешним скриптом

- малыми порциями

(DELETE LOW_PRIORITY)

Реализация

Удаление старых таблиц

- внешним скриптом

- малыми порциями

(DELETE LOW_PRIORITY)

- OPTIMIZE TABLE

(в период с минимальной нагрузкой)

Реализация

Удаление старых таблиц

- внешним скриптом

- малыми порциями

(DELETE LOW_PRIORITY)

- OPTIMIZE TABLE

(в период с минимальной нагрузкой)

- DROP TABLE

Итоги

На сегодняшний день:

rows data size idx size total size

GPS_log 1321.81M 94.11G 112.63G 206.74G

Итоги

Код, таки, пришлось менять :)

Итоги

Код, таки, пришлось менять :)

Ограничение по дате (dt) обязательно

Итоги

Код, таки, пришлось менять :)

Ограничение по дате (dt) обязательно

Не забывать расширять последний раздел

Итоги

Код, таки, пришлось менять :)

Ограничение по дате (dt) обязательно

Не забывать расширять последний раздел

Помнить про файловую систему

Полезности

EXPLAIN PARTITIONS ....

Полезности

EXPLAIN PARTITIONS ....

id select_type table partitions type .... Extra

1 SIMPLE l p0xx,p1202 ALL ... Using where; Using filesort

Полезности

INFORMATION_SCHEMA - наш друг

Полезности

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;

Полезности

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

Вопросы?

Ресурсы

MySQL 5.1 Reference Manual :: 18 Partitioning

http://dev.mysql.com/doc/refman/5.1/en/partitioning.html