Моделирование данных графа с помощью Azure Cosmos DB для Apache Gremlin
ПРИМЕНИМО К:
Гремлин
В этой статье приведены рекомендации по использованию моделей графовых данных. Эти рекомендации крайне важны для обеспечения масштабируемости и производительности системы графовой базы данных по мере развития данных. Эффективная модель данных особенно важна для крупномасштабных графов.
Требования
Процесс, описанный в этом руководстве, исходит из следующих предположений:
- Сущности в проблемной области определены. Эти сущности предназначены для использования атомарным образом для каждого запроса. Другими словами, система базы данных не предназначена для получения данных одной сущности в нескольких запросах.
- Существует понимание требований к чтению и записи для системы баз данных. Эти требования помогут оптимизировать модель графовых данных.
- Принципы стандарта графа свойства Apache Tinkerpop хорошо понятны.
Зачем нужна графовая база данных?
Решение графовой базы данных можно оптимально использовать, если сущности и связи в домене данных имеют следующие характеристики:
- Сущности являются часто подключаемыми через описательные связи. Преимуществом этого сценария является то, что связи сохраняются в хранилище.
- Существуют циклические связи или сущности, ссылающиеся на самих себя. Этот шаблон часто является сложной задачей при использовании реляционных баз данных или баз данных документов.
- Между сущностями есть динамически развивающиеся связи. Этот шаблон хорошо подходит для иерархических или древовидных данных с несколькими уровнями.
- Между сущностями есть связи "многие ко многим".
- Существуют требования к записи и чтению для сущностей и связей.
Если приведенные выше критерии выполнены, подход к графовой базе данных, скорее всего, обеспечивает преимущества для сложности запросов, масштабируемости модели данных и производительности запросов.
На следующем шаге нужно определить, будет ли использоваться граф в целях аналитики или транзакций. Если граф предназначен для больших рабочих нагрузок вычислений и обработки данных, стоит изучить соединитель Spark Cosmos DB и библиотеку GraphX.
Как использовать объекты графов
Стандарт графа свойств Apache Tinkerpop определяет два типа объектов: вершины и ребра.
Ниже приведены рекомендации по свойствам объектов графа.
| Объект | Свойство | Тип | Примечания |
|---|---|---|---|
| Вершина | ID | Строка | Уникально применяется на секцию. Если значение не предоставляется при вставке, сохраняется автоматически созданный GUID. |
| Вершина | Метка | Строка | Это свойство используется для определения типа сущности, которую представляет вершина. Если значение не указано, используется вершина значения по умолчанию. |
| Вершина | Свойства | String, boolean, numeric | Список отдельных свойств, которые хранятся в виде пар "ключ — значение", в каждой вершине. |
| Вершина | Ключ раздела | String, boolean, numeric | Это свойство определяет, где хранятся вершины и ее исходящие ребра. Узнайте больше о секционировании графов. |
| Edge | ID | Строка | Уникально применяется на секцию. Автоматически создается по умолчанию. Ребра обычно не требуют уникального извлечения идентификатором. |
| Edge | Метка | Строка | Это свойство используется для определения типа связи двух вершин. |
| Edge | Свойства | String, boolean, numeric | Список отдельных свойств, которые хранятся в виде пар "ключ — значение", в каждом ребре. |
Примечание
Ребрам не требуется значение ключа секции, так как значение назначается автоматически на основе их исходной вершины. Дополнительные сведения см. в статье Использование секционированного графа в Azure Cosmos DB.
Рекомендации по моделированию сущностей и связей
Следующие рекомендации помогут вам при подходе к моделированию данных для базы данных графов Azure Cosmos DB для Apache Gremlin . Эти инструкции предполагают наличие определения домена данных и запросов для него.
Примечание
Следующие шаги представлены в виде рекомендаций. Необходимо оценить и протестировать окончательную модель, прежде чем рассматривать ее как готовую к использованию в рабочей среде. Кроме того, рекомендации относятся к реализации API Gremlin в Azure Cosmos DB.
Моделирование вершин и свойств
Первым шагом для создания модели данных графов является сопоставление каждой идентифицируемой сущности с объектом вершины. Сопоставление "один к одному" всех сущностей с вершинами должно быть начальным шагом и может быть изменено.
Сопоставление свойств одной сущности в качестве отдельных вершин является одной из распространенных ошибок. Рассмотрим следующий пример, в котором один и тот же объект представлен двумя разными способами:
Свойства на основе вершин: при таком подходе для описания свойств сущности используются три отдельных вершины и два ребра. Хотя при таком подходе может уменьшиться избыточность, он увеличивает сложность модели. Это может привести к дополнительной задержке, увеличению сложности запросов и повышению вычислительных затрат. Эта модель также может вызвать трудности при секционировании.
Вершины с внедренными свойствами: в этом подходе для представления всех свойств сущности внутри вершины используется список пар "ключ — значение". Такой подход снижает сложность модели, что приводит к упрощению запросов и более экономичному обходу.
Примечание
На предыдущих схемах показана упрощенная графовая модель, которая сравнивает только два способа разделения свойств сущности.
Шаблон вершин с внедренными свойствами обычно обеспечивает более производительный и масштабируемый подход. Подход по умолчанию к новой модели данных графа должен тяготеть к этому шаблону.
Однако существуют сценарии, в которых ссылка на свойство может предоставить преимущества. Например, если свойство, на которое указывает ссылка, обновляется часто. Используйте отдельную вершину, чтобы представить свойство, которое постоянно изменяется, чтобы свести к минимуму объем операций записи, необходимых для обновления.
Модели отношений с пограничными маршрутами
После моделирования вершин можно добавить ребра для обозначения связей между ними. Первый аспект, который необходимо оценить, — это направление связи.
Объекты Edge имеют направление по умолчанию, за которым следует обход при использовании out() функций или outE() . При использовании естественного направления повышается эффективность операции, так как все вершины хранятся с исходящими от них ребрами.
Однако обход в противоположном направлении ребра с помощью in() функции всегда приводит к запросу между секциями. Узнайте больше о секционировании графов. Если нужно постоянно выполнять обход с использованием функции in(), мы рекомендуем добавить ребра в обоих направлениях.
Направление ребра можно определить с помощью .to() предикатов или .from() с .addE() шагом Gremlin. либо используя библиотеку массового исполнителя для API Gremlin.
Примечание
Объекты ребер имеют направление по умолчанию.
Метки связей
Использование описательных меток для связи может повысить эффективность операций разрешения ребер. Этот шаблон можно применить следующими способами:
- Создание меток для связи с использованием условий, не являющихся универсальными.
- Связывание метки исходной вершины с меткой целевой вершины с использованием имени связи.
Чем точнее метка, которую обходщик использует для фильтрации ребер, тем лучше. Это решение также может оказать значительное влияние на стоимость запросов. Затраты на запрос можно оценить в любое время с помощью шага executionProfile.
Дальнейшие действия
- Ознакомьтесь со списком поддерживаемых шагов Gremlin.
- Узнайте больше о секционировании графовых баз данных, чтобы обрабатывать крупномасштабные графы.
- Оцените запросы Gremlin с помощью шага профиля выполнения.
- Модель данных для разработки графов сторонних разработчиков.