Работа с диском в резидентных СУБД на примере Memgraph и Redis

архитектура данных, курсы NoSQL HBase Redis Memgraph Neo4j примеры курсы обучение, Apache HBase Hadoop администратор кластера курс, NoSQL курсы примеры обучение, Школа Больших Данных Учебный центр Коммерсант

Недавно мы писали про резидентную графовую СУБД Memgraph, которая хранит данные в оперативной памяти. Сегодня рассмотрим, как выгрузить граф знаний из Memgraph на диск с помощью библиотеки GQLAlchemy, а также поговорим про персистентность другого популярного NoSQL-хранилища Redis, которое также является резидентным, но относится к семейству key-value. 

Как сохранить данные из памяти Memgraph на диск с GQLAlchemy

Напомним, Memgraph — это высокопроизводительная графовая СУБД с открытым исходным кодом, которая хранит и обрабатывает данные в памяти. Потребление памяти для хранения графа в Memgraph зависит от множества переменных, но это можно оценить. Пустой экземпляр Memgraph в Ubuntu x86 потребляет около 75 МБ памяти из-за базовых накладных расходов во время выполнения. После загрузки набора данных потребление памяти возрастает до 260 МБ. Во время активной работы графовой СУБД память используется для хранения графа и выполнения запросов к нему. Потребление памяти для выполнения запроса монотонно увеличивается во время выполнения и освобождается после его завершения. Рекомендуется иметь в два раза больше оперативной памяти, чем объем, который занимает фактический набор данных графа.

Впрочем, хранить данные в памяти не всегда удобно, поскольку размер ОЗУ всегда ограничен. Поэтому имеет смысл хранить на диске свойства графа, которые напрямую не задействованы в графовых алгоритмах. Для этого в Memgraph есть Python-библиотека с открытым исходным кодом GQLAlchemy.

GQLAlchemy представляет собой средство сопоставления графов и объектов (Object Graph Mapper, OGM), обеспечивая связь между объектами графовой СУБД и Python. Помимо Memgraph, GQLAlchemy также поддерживает и Neo4j. OGM позволяет разработчику вместо запросов Cypher писать объектно-ориентированный код, который OGM автоматически преобразует. На практике это очень удобно, поскольку в больших графах есть узлы с множеством метаданных, которые не используются в графовых вычислениях. Графовые СУБд вообще не очень эффективно работают с большими строками или Parquet-файлами. Обойти это ограничение можно, используя отдельную реляционную СУБд или NoSQL-хранилище типа key-value для связи больших свойств с идентификатором узла. Это простое решение легко реализовать, но сложно поддерживать. Вместо этого проще использовать библиотеку GQLAlchemy, которая с версии 1.1 позволяет определить, какие свойства хранить в графовой базе данных, а какие — в постоянном хранилище на диске. Это можно задать однократно в определении модели и больше не беспокоиться о том, правильно ли сохранены или загружены свойства из нужного источника.

Библиотека GQLAlchemy построена на основе Pydantic и обеспечивает моделирование объектов, проверку, сериализацию и десериализацию данных. Она позволяет определить классы Python, которые сопоставляются с объектами графа, такими как узлы и отношения в графовой базе. Каждый такой класс имеет свойства или поля, содержащие данные об объектах графа. Если нужно, чтобы свойство было сохранено на диске, а не в резидентной базе данных, это указывается с помощью аргумента on_disk. Таким образом, граф будет занимать меньше места в памяти, а графовые алгоритмы будут работать быстрее.

Персистентность Redis

Рассмотрим другую резидентную NoSQL-СУБД – Redis, которая тоже хранит данные в памяти в структурах ключ/значение, о чем мы писали здесь. Redis предоставляет возможность записи данных в постоянное хранилище на жесткий диск, используя следующие варианты сохранения данных:

  • RDB (Redis DataBase) – сохранение моментальных снимков набора данных на определенный момент через определенные промежутки времени. Файлы RDB очень компактны и идеально подходят для резервного копирования. Этот вариант имеет очень высокую производительность и позволяет быстрее перезапускать большие наборы данных.
  • AOF (Append Only File) – регистрация каждой операции записи, полученной сервером. Затем эти операции можно воспроизвести снова при запуске сервера, реконструируя исходный набор данных. Команды регистрируются в том же формате, что и сам протокол Redis.
  • RDB + AOF – комбинация обоих вариантов в одном экземпляре. Этот вариант пригодится, когда нужна степень безопасности данных, сравнимая с той, которую может предоставить PostgreSQL.

Также можно отключить персистентность вообще, что полезно при кэшировании.

На репликах RDB поддерживает частичную повторную синхронизацию после перезапуска и отработки отказа. Но RDB не подходит, если нужно свести к минимуму вероятность потери данных. RDB необходимо часто выполнять системный вызов fork(), чтобы сохранить данные на диске с помощью дочернего процесса. Этот системный вызов может занимать много времени для большого набора данных, что чревато остановкой в обслуживании клиентов на несколько миллисекунд или даже на одну секунду. AOF также выполняет вызовы fork(), но намного реже, и можно настроить частоту перезаписи журналов без влияния на персистентность.

По умолчанию Redis сохраняет моментальные снимки набора данных на диске в двоичном файле с именем dump.rdb. Можно настроить Redis так, чтобы он сохранял набор данных каждые несколько секунд, если в наборе данных есть определенное количество изменений, или вручную вызывать команды SAVE или BGSAVE.

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

AOF содержит журнал всех операций одну за другой в простом для понимания и разбора формате. AOF-файл можно экспортировать, например, даже при очистке базы данных с помощью команды FLUSHALL, если за это время не была выполнена перезапись журнала, все равно можно сохранить свой набор данных, просто остановив сервер, удалив последнюю команду и перезапустив Redis снова.

Архитектура Данных

Код курса
ARMG
Ближайшая дата курса
7 октября, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.

Однако, AOF-файлы обычно больше, чем эквивалентные RDB-файлы для того же набора данных. Также AOF может быть медленнее RDB, в зависимости от конкретной политики системного вызова fsync(). RDB может предоставить больше гарантий максимальной задержки даже в случае огромной нагрузки записи.

В Redis до версии 7.0 AOF-процесс потреблял много памяти, если во время перезаписи в базу данных выполнялись записи, которые буферизировались в памяти и потом записывались в в новый AOF-файл. При этом все команды записи, поступившие во время перезаписи, записывались на диск дважды. Redis может заморозить запись и синхронизацию этих команд записи в новый AOF-файл в конце перезаписи.

Если частичная потеря данных в течение нескольких минут в случае сбоев, вызванных отключением электронергии, можно использовать только RDB-сохранение. Впрочем, даже при AOF-варианте, целесообразно периодически делать снимок RDB, что подходит для резервного копирования базы данных, более быстрого перезапуска и выручит в случае ошибок в механизме AOF. В этом случае пригодятся Amazon S3, Apache HBase и другие подобные сервисы внешнего хранения данных, чтобы реализовать систему аварийного восстановления. Достаточно перенести ежедневные или ежечасные RDB-снимок в такое хранилище в зашифрованном виде, зашифрованные в режиме симметричного шифрования с помощью команды gpg -c. Для повышения безопасности данных рекомендуется использовать несколько служб хранения.

Безопасно перенести RDB-снимки на удаленные серверы можно с помощью SCP (часть SSH), получив небольшой VPS в удаленном месте. Далее там нужно установить ssh и сгенерировать клиентский ssh-ключ без кодовой фразы, а затем добавить его в файл author_keys удаленного VPS, чтобы передавать резервные копии в автоматическом режиме. Для большей эффективности можно использовать минимум два VPS от двух разных провайдеров. Проверить корректность работы этой схемы поможет сопоставление размеров скопированного и исходного файлов, а также дайджест SHA1 при использовании VPS. Также следует реализовать независимую систему оповещения, если передача свежих резервных копий по какой-то причине не работает.

Освойте тонкости работы с NoSQL-СУБД и лучшие практики их использования в реальных проектах аналитики больших данных на специализированных курсах нашего лицензированного учебного центра обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://memgraph.com/docs/memgraph
  2. https://medium.com/memgraph/using-on-disk-storage-with-an-in-memory-graph-database-467689813efe
  3. https://redis.io/docs/management/persistence/
Поиск по сайту