https://www.yangdb.org/
вики
Информация о версии
Примечания к выпуску
Лиор Перри
Роман Марголис
Моти Коэн
Элад Вис
Шимон Беношти
Сообщение, представляющее нашу новую инициативу с открытым исходным кодом для создания масштабируемой распределенной графовой базы данных на основе Opensearch https://www.linkedin.com/pulse/making-db-lior-perry/
Еще одно использование Opensearch в качестве графовой базы данных https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622.
Мир графовых баз данных оказал огромное влияние за последние несколько лет, особенно в отношении социальных сетей и их влияния на нашу повседневную деятельность.
Некогда могущественная (и одинокая) СУБД теперь вынуждена освободить место для нового и все более важного партнера в центре обработки данных: графовой базы данных.
Его используют Twitter, Facebook, даже сайты знакомств используют его; они используют графики отношений. В конце концов, социальное есть социальное, и, в конечном счете, все дело в отношениях.
Есть два основных элемента, которые отличают графовую технологию: хранение и обработка.
Хранилище графов обычно относится к структуре базы данных, содержащей данные графов.
Такое хранилище графов во многих аспектах оптимизировано для графов, гарантируя эффективное хранение данных, сохраняя узлы и связи близко друг к другу на реальном физическом уровне.
Хранилище графов классифицируется как неродное, если оно поступает из внешнего источника, например, из реляционной, столбчатой или любого другого типа базы данных (в большинстве случаев хранилище NoSQL предпочтительнее).
Неродные графовые базы данных обычно состоят из существующих реляционных хранилищ, хранилищ документов и значений ключей, адаптированных для сценариев запросов графовой модели данных.
Обработка графа включает в себя доступ к графу, обход вершин и ребер и сбор результатов.
Обход — это способ запроса графа, переход от начальных узлов к связанным узлам, следуя связям в соответствии с некоторыми правилами.
найти ответы на такие вопросы, как «какая музыка нравится моим друзьям, которой у меня еще нет?»
Одной из наиболее популярных моделей представления графа является модель свойств.
Эта модель содержит связанные сущности (узлы), которые могут содержать любое количество атрибутов (пар ключ-значение).
Узлы имеют уникальный идентификатор, а список атрибутов представляет их функции и содержимое.
Узлы могут быть помечены метками, обозначающими их различные роли в вашем домене. Помимо свойств отношений, метки также могут предоставлять метаданные по элементам графа.
Узлы часто используются для представления сущностей, но в зависимости от доменных отношений могут использоваться и для этой цели.
Связь представлена исходным и целевым узлом, который они соединяют, а в случае нескольких связей между одними и теми же вершинами — дополнительной меткой свойства для различения (тип связи).
Отношения организуют узлы в произвольные структуры, позволяя графу напоминать список, дерево, карту или составной объект, любой из которых может быть объединен в еще более сложные структуры.
Очень похоже на внешние ключи между таблицами в реляционной модели БД. В графовой модели отношения описывают отношения между вершинами.
Одним из основных отличий этой модели (по сравнению со строгой реляционной схемой) является то, что эта структура без схемы позволяет добавлять/удалять связи между вершинами без каких-либо ограничений.
Дополнительной графовой моделью является модель Resource Description Framework (RDF).
Наш вариант использования находится в сфере социальных сетей. Очень большой социальный график, который необходимо часто обновлять и который доступен для обоих:
простой (в основном текстовый) поиск
запросы на основе графов.
Все операции чтения и записи выполняются одновременно с разумным временем отклика и постоянно растущей пропускной способностью.
Первое требование было выполнено с использованием Opensearch — хорошо известной и зарекомендовавшей себя системы поиска и хранения документов NoSql, способной содержать очень большие объемы данных.
Что касается второго требования , мы решили, что лучшим решением будет использование Opensearch в качестве неродного уровня хранения графовой базы данных .
Как упоминалось ранее, уровень хранения графовой базы данных может быть реализован с использованием неродного хранилища, такого как хранилище NoSql.
В дальнейшем обсуждении я подробно расскажу, почему самая популярная в сообществе альтернатива графовой базе данных — Neo4J — не соответствует нашим потребностям.
Первая наша задача — разработать модель данных, представляющую граф как набор вершин и ребер.
С помощью Opensearch мы можем использовать его мощные возможности поиска для эффективного получения документов узлов и связей в соответствии с фильтрами запросов.
В Opensearch каждый индекс можно описать как таблицу для конкретной схемы, сам индекс разделен на общие, что обеспечивает масштабирование и избыточность (с репликами) в кластере.
Документ направляется к определенному сегменту индекса по следующей формуле:
shard_num = хеш(_routing) % num_primary_shards
Каждый индекс имеет схему (в Opensearch называемую типом), которая определяет структуру документов (в Opensearch она называется сопоставлением). Каждый индекс может содержать только один тип сопоставления (начиная с Opensearch 6).
Индекс вершин будет содержать документы вершин со свойствами, индекс ребер будет содержать документы ребер с их свойствами.
Как мы описываем перемещение по графику (источник данных)
Существует несколько графоориентированных языков запросов:
Cypher — это язык запросов для графовой базы данных Neo4j (см. инициативу openCypher).
Gremlin — это язык обхода графов Apache Software Foundation для графовых систем OLTP и OLAP.
SPARQL — это язык запросов для графов RDF.
Некоторые языки в большей степени основаны на шаблонах и декларативны, некоторые более императивны — все они описывают логический способ прохождения данных.
Давайте рассмотрим Cypher — декларативный язык на основе SQL для визуального описания шаблонов в графиках с использованием синтаксиса ascii-art.
Это позволяет нам указать, что мы хотим выбрать, вставить, обновить или удалить из данных нашего графика, не требуя от нас точного описания того, как это сделать.
После получения логического запроса нам необходимо преобразовать его на физический уровень хранилища данных, которым является Opensearch.
В Opensearch есть DSL запросов, который ориентирован на поиск и агрегацию — а не на перемещение, нам нужен дополнительный этап трансляции, который будет учитывать схематическую структуру графа (и базовые индексы).
Преобразование логического запроса в физический — это процесс, состоящий из нескольких шагов:
проверка запроса на соответствие схеме
перевод меток в реальные объекты схемы (индексы)
создание физического запроса Opensearch
Это процесс в обзоре высокого уровня, на практике — этапов, оптимизирующих логический запрос, будет больше; в некоторых случаях можно создать несколько физических планов (планов выполнения) и ранжировать их в соответствии с некоторой стратегией эффективности (стоимости), например количеством элементов, необходимых для выборки...
Мы начали с обсуждения цели БД графов в современных сценариях использования в бизнесе и рассмотрели различные модели представления графа. Понимание фундаментальных логических строительных блоков, из которых должна состоять потенциальная графовая БД, и обсуждение существующего кандидата NoSql для удовлетворения требований уровня хранения.
Выбрав Opensearch в качестве уровня хранения, мы взяли графовую модель LDBC Social Network Benchmark и упростили ее для оптимизации в этом конкретном хранилище. Мы обсудили фактическую схему хранилища с избыточными свойствами и рассмотрели язык шифрования для запроса хранилища на языке шаблонов графов, подобном sql.
Мы продолжили наблюдать фактическое преобразование зашифрованного запроса в запрос физического выполнения, который будет выполняться Opensearch.
В последнем разделе мы взяли простой запрос к графу и углубились в детали стратегий выполнения и механизма формирования объемов.
Руководство по установке:
Учебник по созданию схемы:
Учебное пособие по загрузке данных:
Запросите учебник по графику:
Учебное пособие по материализации и подсчету проекций: