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

Мой друг Роберт Ходжес на днях опубликовал статью про репликацию из 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 — очень хороший инструмент для этого. Знаю не понаслышке.
  • +10
  • 4,5k
  • 8
LifeStreet Media
32,24
Компания
Поделиться публикацией

Комментарии 8

    0
    Спасибо за статью.

    Заинтересовался, каким образом данные в бинарном логе выглядят могут выглядеть как текст. Из следующей статьи стало понятно, что лог MySQL сохраняется в видет CSV файла. Отсюда два вопроса:

    1. Первичная репликация из источника проводилась также через файл? Какого размера были данные в БД?
    2. Примерный объем данных, которые нужно анализировать, видимо, достаточно велик, чтобы для анализа использовать специализированную Вертику. Влезает ли объем изменений в файл?
      0
      Не совсем так. Бинарный лог — он на то и бинарный, что это не текст. Его формат для MySQL, впрочем, не является секретом. Но в конечном итоге из лога можно, конечно, восстановить исходный SQL-statement. На хабре есть хорошие статьи про MySQL-репликацию, там об этом подробно рассказано.

      csv файлы используются для промежуточного результата перед загрузкой в OLAP базу данных. В данном случае использовалась Вертика, но это может быть что угодно. То есть процесс примерно такой:
      mysql binlog -> reduction -> csv -> vertica

      Почему так? Потому что большинство баз данных, а аналитические всегда, поддерживают быструю загрузку из csv-файлов. В последних стандартах SQL для этого есть оператор COPY.

      Отвечая на вопросы:
      1. Наверное через файл. Данные достаточно большие, чтобы имело смысл городить весь этот огород. Рискну предположить, что речь шла о сотнях миллионах или нескольких миллиардах записей. Для MySQL это уже проблема.
      2. Влезает ли объем изменений в файл? Странный вопрос. В файл может влезть все, что угодно. Здесь надо ставить вопрос, насколько велик поток изменений. Но можно предположить, что MySQL вряд ли выдерживает постоянно больше нескольких тысяч транзакций в секунду, а в Вертику данные можно загружать со скоростью в десятки и сотни тысяч записей в секунду, и при необходимости процесс загрузки неплохо масштабируется.
        0
        Спасибо за ответ, я именно об этом и спрашивал. Насчет влезания в файл — видимо, что-то я недоформулировал.
          0
          Что значит сила open-source. Чтобы проделывать такое с логами, скажем, Oracle, нужно за большие деньги покупать отдельный продукт или опцию.
            0
            Это сила не Open Source, а сила открытого протокола. Tungsten может делать, кстати, репликацию из MySQL в Oracle тоже, но я не знаю детали.
          0
          Sybase это делает через in-memory database в репликационном сервере, после чего делает булк лоад в OLAP, при этом отбрасывая «промежуточные мусорные запросы»
            0
            В MS SQL Server 2008 появился механизм Change Tracking, который всё это делает на уровне ядра. Каждое целостное состояния данных в таблице характеризуется своим номером версии, указав две разных версии можно получить полноценный diff (PK записи и тип действия I/U/D которое нужно совершить). При этом, цепочка событий Insert + Update + Update превращается в один Insert.
              0
              Извините, ответ предназначается автору поста.

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

            Самое читаемое