А в чем, по-Вашему, заключается дороговизна реализации? Я не стал рассказывать о технических аспектах, посчитав их несущественными. В наши дни идеи ценятся дороже. Но если интересно, то вкратце, технически это выглядит следующим образом.
У нас 7 датацентров и порядка 150 серверов, регистрирующих события, связанные с показом рекламы. В день — несколько терабайт сырых логов. В каждом датацентре логи с серверов попадают на специальный мультиплексирующий сервер. Этот сервер «знает» обо всех экземплярах/инстансах хранилища из базы данных конфигурации, а также о ETL серверах, которые обслуживают эти инстансы. Мультиплексирующий сервер «размножает» логи и раскладывает их по ETL серверам так, что на каждый инстанс попадает своя копия, и логи с разных рантайм серверов определенным образом «размазываются» по ETL серверам. Это основная точка «клонирования». Обработка логов детерминирована, то есть одни и те же логи обрабатываются на разных серверах одинаково, даже если они туда попадают в разное время.
Остальные источники данных клонировать проще. Для онтологии и описания кампаний у нас в каждом датацентре стоит одна или несколько read-only реплик с мастер-базы. База не очень большая, и это вполне приемлимо. ETL-сервера читают с этих реплик. Нагрузка небольшая, так как читаются только изменения, и масштабировать легко, если что. Внешние источники попадают на один из серверов, а потом отдельной процедурой разбрасываются по остальным. Объем тут тоже небольшой и несравним с логами.
Ключевое отличие Вертики и других специализированных колонко-ориентированных баз данных в том, что таблица на диске не лежит, как таблица. Она лежит, если так можно выразиться, в виде набора колонок. Каждая колонка в своих файлах. Колонки между собой довольно хитро связаны, чтобы можно было восстановить цельную запись. Поэтому пустые поля места не занимают, или занимают, но минимально (один бит плюс число повторений на блок)
Не уверен, что Вы правильно поняли. Возможно, я не совсем хорошо написал.
Я не пишу о продуктах. Я пишу о различных архитектурных или инфраструктурных подходах. Наша компания не делает программные продукты и не предоставляет IT услуги. Мы решаем свое собственные проблемы. И мы для себя решили проблему резервирования хранилища данных таким образом, как я описал, проанализировав стандартные альтернативы и признав их неприемлимыми. Другим это может быть полезна как идея, которая реально работает. Не более того.
Наверное, надо сказать о природе тех данных, которые попадают в хранилище посредством ETL. Это данные из нескольких типов источников:
— логи с веб серверов
— онтология и описание рекламных компаний
— данные с внешних источников
Все эти типы источников мультиплексируются по-разному, чтобы получить одинаковый слепок данных в нескольких независимых экзмеплярах системы. Фактически, мы вынесли проблему масштабируемости и резервирования вне базы данных. Это универсальный подход.
Статья о подходе и собственном опыте. Проблема резервирования больших данных может возникать у многих, и возможно, наш опыт окажется кому-то полезным. Обычные рекомендации — это делать бэкапы или hot-standby через репликацию того или иного рода. Мы же делаем не репликацию базы данных, а репликацию исходных данных, которые попадают в ETL. Это оказывается гораздо проще и эффективнее и дает дополнительные преимущества.
Мы, конечно, рассчитывали на InfoBright и InfiniDB, потому что они используют MySQL протокол, что упростило бы миграцию.
Насколько я помню, основное принципиальное ограничение InfoBright — это невозможность масштабирования. Это односерверная система. Поэтому мы его серьезно не рассматривали.
InfiniDB мы смотрели более внимательно, концепция выглядела очень многообещающе. В некоторых тестах по производительности он был сравним с GreenPlum, но проигрывал Вертике. Однако на тот момент система была очень сырая (мы пробовали версию 1.0.1-RC1), в частности SQL был не полностью реализован, не поддерживались сабселекты, а также было не возможно использовать в одном селекте и IniniDB, и не-InfninDB (например, InnoDB) таблицы. Возможно, что сейчас продукт стал лучше. Хотя я отслеживаю новости по теме аналитических баз данных, и InfiniDB там давно не встречался.
Если говорить о Вертике, то удалять колонки просто нельзя. Но это не является большой проблемой, так как можно просто перестать записывать данные в «ненужные» колонки, и тогда они не занимают места на диске.
Я как раз хочу дать более общую информацию, так как кейсы у всех разные. Но уже опубликовав статью я понял, что даже не написал, что именно за данные мы обрабатываем и как они используются. Исправлюсь в следующей статье.
Не совсем так. Бинарный лог — он на то и бинарный, что это не текст. Его формат для MySQL, впрочем, не является секретом. Но в конечном итоге из лога можно, конечно, восстановить исходный SQL-statement. На хабре есть хорошие статьи про MySQL-репликацию, там об этом подробно рассказано.
csv файлы используются для промежуточного результата перед загрузкой в OLAP базу данных. В данном случае использовалась Вертика, но это может быть что угодно. То есть процесс примерно такой:
mysql binlog -> reduction -> csv -> vertica
Почему так? Потому что большинство баз данных, а аналитические всегда, поддерживают быструю загрузку из csv-файлов. В последних стандартах SQL для этого есть оператор COPY.
Отвечая на вопросы:
1. Наверное через файл. Данные достаточно большие, чтобы имело смысл городить весь этот огород. Рискну предположить, что речь шла о сотнях миллионах или нескольких миллиардах записей. Для MySQL это уже проблема.
2. Влезает ли объем изменений в файл? Странный вопрос. В файл может влезть все, что угодно. Здесь надо ставить вопрос, насколько велик поток изменений. Но можно предположить, что MySQL вряд ли выдерживает постоянно больше нескольких тысяч транзакций в секунду, а в Вертику данные можно загружать со скоростью в десятки и сотни тысяч записей в секунду, и при необходимости процесс загрузки неплохо масштабируется.
У нас 7 датацентров и порядка 150 серверов, регистрирующих события, связанные с показом рекламы. В день — несколько терабайт сырых логов. В каждом датацентре логи с серверов попадают на специальный мультиплексирующий сервер. Этот сервер «знает» обо всех экземплярах/инстансах хранилища из базы данных конфигурации, а также о ETL серверах, которые обслуживают эти инстансы. Мультиплексирующий сервер «размножает» логи и раскладывает их по ETL серверам так, что на каждый инстанс попадает своя копия, и логи с разных рантайм серверов определенным образом «размазываются» по ETL серверам. Это основная точка «клонирования». Обработка логов детерминирована, то есть одни и те же логи обрабатываются на разных серверах одинаково, даже если они туда попадают в разное время.
Остальные источники данных клонировать проще. Для онтологии и описания кампаний у нас в каждом датацентре стоит одна или несколько read-only реплик с мастер-базы. База не очень большая, и это вполне приемлимо. ETL-сервера читают с этих реплик. Нагрузка небольшая, так как читаются только изменения, и масштабировать легко, если что. Внешние источники попадают на один из серверов, а потом отдельной процедурой разбрасываются по остальным. Объем тут тоже небольшой и несравним с логами.
Я не пишу о продуктах. Я пишу о различных архитектурных или инфраструктурных подходах. Наша компания не делает программные продукты и не предоставляет IT услуги. Мы решаем свое собственные проблемы. И мы для себя решили проблему резервирования хранилища данных таким образом, как я описал, проанализировав стандартные альтернативы и признав их неприемлимыми. Другим это может быть полезна как идея, которая реально работает. Не более того.
Наверное, надо сказать о природе тех данных, которые попадают в хранилище посредством ETL. Это данные из нескольких типов источников:
— логи с веб серверов
— онтология и описание рекламных компаний
— данные с внешних источников
Все эти типы источников мультиплексируются по-разному, чтобы получить одинаковый слепок данных в нескольких независимых экзмеплярах системы. Фактически, мы вынесли проблему масштабируемости и резервирования вне базы данных. Это универсальный подход.
Насколько я помню, основное принципиальное ограничение InfoBright — это невозможность масштабирования. Это односерверная система. Поэтому мы его серьезно не рассматривали.
InfiniDB мы смотрели более внимательно, концепция выглядела очень многообещающе. В некоторых тестах по производительности он был сравним с GreenPlum, но проигрывал Вертике. Однако на тот момент система была очень сырая (мы пробовали версию 1.0.1-RC1), в частности SQL был не полностью реализован, не поддерживались сабселекты, а также было не возможно использовать в одном селекте и IniniDB, и не-InfninDB (например, InnoDB) таблицы. Возможно, что сейчас продукт стал лучше. Хотя я отслеживаю новости по теме аналитических баз данных, и InfiniDB там давно не встречался.
Я как раз хочу дать более общую информацию, так как кейсы у всех разные. Но уже опубликовав статью я понял, что даже не написал, что именно за данные мы обрабатываем и как они используются. Исправлюсь в следующей статье.
csv файлы используются для промежуточного результата перед загрузкой в OLAP базу данных. В данном случае использовалась Вертика, но это может быть что угодно. То есть процесс примерно такой:
mysql binlog -> reduction -> csv -> vertica
Почему так? Потому что большинство баз данных, а аналитические всегда, поддерживают быструю загрузку из csv-файлов. В последних стандартах SQL для этого есть оператор COPY.
Отвечая на вопросы:
1. Наверное через файл. Данные достаточно большие, чтобы имело смысл городить весь этот огород. Рискну предположить, что речь шла о сотнях миллионах или нескольких миллиардах записей. Для MySQL это уже проблема.
2. Влезает ли объем изменений в файл? Странный вопрос. В файл может влезть все, что угодно. Здесь надо ставить вопрос, насколько велик поток изменений. Но можно предположить, что MySQL вряд ли выдерживает постоянно больше нескольких тысяч транзакций в секунду, а в Вертику данные можно загружать со скоростью в десятки и сотни тысяч записей в секунду, и при необходимости процесс загрузки неплохо масштабируется.