Комментарии 8
Спасибо за статью.
Заинтересовался, каким образом данные в бинарном логе выглядят могут выглядеть как текст. Из следующей статьи стало понятно, что лог MySQL сохраняется в видет CSV файла. Отсюда два вопроса:
1. Первичная репликация из источника проводилась также через файл? Какого размера были данные в БД?
2. Примерный объем данных, которые нужно анализировать, видимо, достаточно велик, чтобы для анализа использовать специализированную Вертику. Влезает ли объем изменений в файл?
Заинтересовался, каким образом данные в бинарном логе выглядят могут выглядеть как текст. Из следующей статьи стало понятно, что лог MySQL сохраняется в видет CSV файла. Отсюда два вопроса:
1. Первичная репликация из источника проводилась также через файл? Какого размера были данные в БД?
2. Примерный объем данных, которые нужно анализировать, видимо, достаточно велик, чтобы для анализа использовать специализированную Вертику. Влезает ли объем изменений в файл?
Не совсем так. Бинарный лог — он на то и бинарный, что это не текст. Его формат для MySQL, впрочем, не является секретом. Но в конечном итоге из лога можно, конечно, восстановить исходный SQL-statement. На хабре есть хорошие статьи про MySQL-репликацию, там об этом подробно рассказано.
csv файлы используются для промежуточного результата перед загрузкой в OLAP базу данных. В данном случае использовалась Вертика, но это может быть что угодно. То есть процесс примерно такой:
mysql binlog -> reduction -> csv -> vertica
Почему так? Потому что большинство баз данных, а аналитические всегда, поддерживают быструю загрузку из csv-файлов. В последних стандартах SQL для этого есть оператор COPY.
Отвечая на вопросы:
1. Наверное через файл. Данные достаточно большие, чтобы имело смысл городить весь этот огород. Рискну предположить, что речь шла о сотнях миллионах или нескольких миллиардах записей. Для MySQL это уже проблема.
2. Влезает ли объем изменений в файл? Странный вопрос. В файл может влезть все, что угодно. Здесь надо ставить вопрос, насколько велик поток изменений. Но можно предположить, что MySQL вряд ли выдерживает постоянно больше нескольких тысяч транзакций в секунду, а в Вертику данные можно загружать со скоростью в десятки и сотни тысяч записей в секунду, и при необходимости процесс загрузки неплохо масштабируется.
csv файлы используются для промежуточного результата перед загрузкой в OLAP базу данных. В данном случае использовалась Вертика, но это может быть что угодно. То есть процесс примерно такой:
mysql binlog -> reduction -> csv -> vertica
Почему так? Потому что большинство баз данных, а аналитические всегда, поддерживают быструю загрузку из csv-файлов. В последних стандартах SQL для этого есть оператор COPY.
Отвечая на вопросы:
1. Наверное через файл. Данные достаточно большие, чтобы имело смысл городить весь этот огород. Рискну предположить, что речь шла о сотнях миллионах или нескольких миллиардах записей. Для MySQL это уже проблема.
2. Влезает ли объем изменений в файл? Странный вопрос. В файл может влезть все, что угодно. Здесь надо ставить вопрос, насколько велик поток изменений. Но можно предположить, что MySQL вряд ли выдерживает постоянно больше нескольких тысяч транзакций в секунду, а в Вертику данные можно загружать со скоростью в десятки и сотни тысяч записей в секунду, и при необходимости процесс загрузки неплохо масштабируется.
Sybase это делает через in-memory database в репликационном сервере, после чего делает булк лоад в OLAP, при этом отбрасывая «промежуточные мусорные запросы»
В MS SQL Server 2008 появился механизм Change Tracking, который всё это делает на уровне ядра. Каждое целостное состояния данных в таблице характеризуется своим номером версии, указав две разных версии можно получить полноценный diff (PK записи и тип действия I/U/D которое нужно совершить). При этом, цепочка событий Insert + Update + Update превращается в один Insert.
Извините, ответ предназначается автору поста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Репликация из OLTP в OLAP базу данных