Версия сайта для слабовидящих
Недавно мы писали про резидентную графовую СУБД 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
Ближайшая дата курса
22 апреля, 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 в Москве:
Источники
