Pull to refresh
0

Резервирование больших данных

Reading time 4 min
Views 5.1K
При проектировании и эксплуатации нашего хранилища данных, несколько раз возникал вопрос, как делать бэкапы или репликацию. Я на него неизменно давал один и тот же ответ — никак. Объясню немного почему.

Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.

Иногда для поддержания резервной системы используют репликацию. Но надо понимать, что репликация довольно сильно просаживает производительность, так как требует записи бинарного лога, а если репликация синхронная, то и синхронизации. В аналитических приложениях с большим потоком данных, когда требуется постоянно грузить в базу данных тысячи или десятки тысяч записей в секунду, это может быть неприемлимо.

Что же делать? Довольно давно мы придумали и реализовали механизм клонирования или мультиплексирования систем, которое происходит не на уровне базы данных, а на уровне источника. Мы поддерживаем несколько «почти» идентичных систем, которые между собой никак не связаны, но загружают в себя одинаковые данные одинаковым образом. Поскольку в аналитические базы данных пользователи напрямую никогда ничего не пишут, это возможно сделать. Такое клонирование имеет еще одно важное преимущество: можно иметь одну или несколько тестовых систем с настоящими боевыми данными и нагрузкой. Еще одно преимущество — staging deployment и QA. Поведение системы с новой функциональностью можно сравнить с текущей боевой, и вовремя выловить ошибки.

Итак, клонирование дает возможность:
  • Иметь постоянно готовую живую резервную систему или несколько
  • Иметь идентичные системы разного предназначения или для распределения нагрузки
  • Иметь системы с одинаковыми данными, но разными настройками (например, оптимизированные под легкие или тяжелые запросы)
  • Иметь тестовую систему с боевыми данными и нагрузкой
  • Проводить постепенный деплоймент новой функциональности, уменьшая риск ошибок
  • Восстанавливать одну систему данными с другой (копированием)
  • Прозрачно всем этим управлять

И все это без штрафов по производительности, и с минимальными рисками. Однако, есть и сложности, о которых надо упомянуть:
  • Контроль целостности данных между системами
  • Запуск новой системы «с нуля»

Обе эти проблемы довольно трудно решить со 100% точностью, но она нам не требовалась. Достаточно, чтобы финансово значимая статистика совпадала, а детальные данные могли незначительно различаться или даже отсутствовать. В обоих случаях, синхронизация данных может быть произведена путем копирования значимых данных с живой системой. Тем самым у нас всегда был полный контроль и пространства для выбора, хотим ли мы получить точную копию, но через несколько дней, или менее точную, но быстрее.

Описанный подход многократно нам очень помогал. Более того, он позволял нам иметь системы на разных базах данных (разных вендоров), но работающие по одинаковым алгоритмам. Тем самым упрощая миграцию с одной базы данных на другую.

Update: После получения комментариев, появилось необходимость в некоторых разъяснениях


Наверное, с этого стоило начать и написать о том, какого рода данные мы обрабатываем. Я уверен, что предложенный подход работает в разных случаях, но конкретика не помешает.

Мы обрабатываем и загружаем в хранилище данные с нескольких типов источников. Это:
  • Логи с рантайм серверов, регистрирующих статистику и контекст показов рекламных кампания
  • Онтология и описание, позволяющие правильным образом интерпретировать логи
  • Данные с сайтов наших партнеров

Все эти данные загружаются в хранилище, и используются нашими клиентами, партнерами, собственными пользователями, и различными алгоритмами, которые на основе данных принимают решение, что, где и как показывать. Отказ базы данных означает не только остановку бизнеса и потерю денег, но и то, что потом придется накопившиеся во время отказа данные «догонять». А оперативность очень существенна. Поэтому вопрос о резервной системе не праздный.

Объем данных большой. Сырые логи занимают несколько терабайт в день, хотя в обработанном виде сильно меньше. Боевая база стабильно растет, и сейчас занимает несколько терабайт.

Клонирование или мультиплексирование на уровне источника — это, как нам кажется, хороший, простой и относительно недорогой способ решить проблему резервирования, который к тому же имеет и еще ряд преимуществ. Целью данной статьи было описание работающей идеи, а не конкретной реализации. Применимость этой идеи достаточно универсальна в тех случаях, когда данные в хранилище загружаются только через ETL.

Tags:
Hubs:
-3
Comments 17
Comments Comments 17

Articles

Information

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