Pull to refresh

Репликация из OLTP в OLAP базу данных

«LifeStreet Media» corporate blogMySQL
Sandbox
Мой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.

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

Этот подход плохо работает с OLAP-специфичными, и особенно, колонко-ориентированными базами данных, которые хранят данные физически не по строкам, а по колонкам. Такие базы данных оптимизированы на запись, чтение и сортировку больших массивов данных, что типично для аналитических задач, но не на маленькие операции на единичных записях, потому что любая операция затрагивает много колонок, которые физически хранятся в разных файлах (а иногда и разных дисках). Хуже всего обстоит дело с изменением данных. Конечно, все базы данных поддерживают стандарт SQL и оператор UPDATE, но на физическом уровне он, как правило, транслируется в то, что обновляемая запись помечается как удаленная, а вместо нее вставляется измененная копия. Потом, когда-нибудь, «сборщик мусора» перетрясет таблицу и удаленные записи удалятся навсегда. Помимо плохой эффективности, отсюда следует, что частые удаления и обновления приводят к «засорению» базы данных, что снижает ее производительность в том числе и на чтение.

Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.

Во-первых, вместо репликации отдельных изменений или таблиц, предлагается делать репликацию довольно большими кусками или пакетами данных. Это естественно для загрузки данных в OLAP-базы данных. Например, все изменения за какой-то период времени: минута, 5 минут и т.д. Во-вторых, все изменения, попадающие в пакет, разбиваются по таблицам. Затем, каждый UPDATE переводится в пару DELETE и INSERT. И, наконец, для каждой таблицы производится редукция по определенным правилам: для каждого ключа оставляется только один DELETE, и для каждого ключа оставляется только последний INSERT, если за ним не следует DELETE. Эта редукция превращает поток изменений в минимальный набор (множество) операций типа DELETE и INSERT, причем DELETE выполняется перед INSERT. Например:

image

Три операции в бинарном логе перевелись в 4 операции на промежуточном этапе, а после редукции осталось лишь две последние.

Что это дает? Это дает максимально эффективный с точки зрения OLAP базы способ изменения данных: сначала удаляются все удаленные или измененные в пакете записи, и не более того, а потом одним куском для каждой таблицы — добавляются новые и измененные записи, что можно сделать очень эффективно через операторы пакетной загрузки данных. То есть строго упорядоченная линейная последовательность преобразуется в частично упорядоченное множество (в последовательность частично упорядоченных множеств). В этом фундаментальный смысл.

Очевидно, что есть и ограничение. Если UPDATE или DELETE в бинарном логе не включают условие на primary key таблицы, то этот подход не работает, и в таком случае придется реплицировать данные традиционным способом.

В заключение замечу, что это не пустая теория, а работающая реализация, о чем Роберт пишет в следующей статье. Зачем это нужно? Клиент захотел получить быструю аналитику для своих данных, хранящийся в MySQL. А Vertica — очень хороший инструмент для этого. Знаю не понаслышке.
Tags:MySQLVerticaTungstenрепликация
Hubs: «LifeStreet Media» corporate blog MySQL
Total votes 10: ↑10 and ↓0 +10
Views4.8K

Comments 8

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2005
Location
США
Website
www.lifestreetmedia.com
Employees
51–100 employees
Registered