Ну и для полноты ссылок, сам драфт: GQL Early Working Draft v2.2. Для меня скорее важно, что это будет тьюринг-полный язык и по сути это будут программы. Синтаксический сахар, как писать запросы - привыкнем)
Ключевое отличие TigerGraph от остальных графовых бд это MPP и ACID одновременно, т.е. она HTAP бд (новое поколение).
Согласен
Шардинг реализован как node-based (есть два основных вида - predicate-based когда мы шардируем грани, и node-based когда мы шардируем вершины с исходящими гранями). Проблема node-based шардинга в supernode problem (когда очень много граней у вершины).
На видео ниже можно посмотреть детали архитектуры и Native Graph Storage - вершины и рёбра распределяются по сегментам и хранятся на одной партиции:
Документация, да у них та еще, очень тяжело разобраться, видимо какой то особый образ мышления у китайцев. Это притом что я отлично знаю cypher и gremlin и знаю примерно каким должен быть запрос. Клиентам они говорят, купите лицензию, потом мы вам дадим наших инженеров и они все настроят и объяснят.
Видел много документаций, у TG вполне подробная и понятная документация, от сохи https://docs.tigergraph.com/. Можно найти довольно подбробную информацию - по Языку, алгоритмам и администрированию самой БД.
У каждого свои задачи, если начинаешь запускать графовые алгоритмы или нужно проанализировать связи с глубиной 6 или 10 - можно выбрать любой инструмент, но на каком-то этапе упереться в стену: по производительности, по масштабированию, по удобству работы и т.д.
Помимо синтаксического сахара в запросах, важно чтобы хранение данных было изначально графовое. Насколько могу судить по статье https://habr.com/ru/company/otus/blog/518586/ про MSSQLSERVER - получается монструозный "графовый" запрос и скорость работы на больших данных ожидаемо просядет (ибо JSON в таблицах).
Наш кейс умещается в 50GB сжатых данных. В нашем случае - данные и связи - это одно и то же, поэтому храним всё в одной БД. Тут наверно индивидуально всё, в целом подход: если данные нужны для анализа, подпадают под определеения вершины или ребра, тогда их используем.
С вендором общались и общаемся, в т.ч. по другим кейсам. Общаемся как по линии community, так и с инженерми напрямую. Уровнем и скоростью довольны, в TigerGraph пришли люди с большим опытом работы в других коммерческих БД, а таже практики из прикладных доменов.
Если Вы пробовали Neo4j или другие, тогда Вам точно стоит попробовать эту БД. С точки зрения производительности на графах - они как раз лидеры, остальные фоловеры (раз и два). С точки зрения стбильности - в продакшенах разных не первый год, у нас тоже стабильно.
Merkle Science’s cryptocurrency network graph, which currently contains over 2.5 TB of data and consists of 5 billion vertices and 36 billion edges, supports a complete extract, transfer and load (ETL) each day that takes under an hour, with near-instant streaming updates. “We reached out to TigerGraph as we’ve been trying to find an elegant way to visualize our investigative data over the last two years. Other incumbents in the graph database space weren’t able to process our vast amounts of data fast enough in order to generate graphs in real time. TigerGraph helped solve that issue for us
Если коротко - пользуемся сами, ставим и поддерживаем.
Изначально были задачи на графой аналитике, посмотрели что есть с точки зрения масштабирования/скорости, удобства и текущих заказчиков (=продакшен), остановились на этой БД.
Также подкупило наличие ready-to-go решений - с набором данных и готовыми алгоритмами = просто добавь свои данные.
Тут скорее идея в том, что бизнес-логику можно реализовать с помощью GSQL. Поскольку это полноценный язык программирования, мы можем сделать циклы, ветвления и т.д.:
REST Request --> GSQL + business logic --> JSON Result
Massive-write - это тоже случай для этой БД. Например кейсы с CyberSec аналитикой, когда у нас большой стрим данных.
The TigerGraph system also provides distributed system Sequential Consistency: every replica of the data performs the same operations in the same order. This is one of the strongest forms of consistency available, stronger than causal consistency, for example.
GSQL - есть готове к работе графовые алгоритмы, а также решения конкретных бизнес-задач. Алгоритмы открыты, их можно модифицировать и использовать как примеря для своих задач = например захочется чуть поправить PageRank.
Анализ связей на распределённом графе - одно из ключевых преимуществ. В отличие от Neo4j тут не надо сводить связанные данные в одну ноду: они могут быть реально распределены.
Как это сделано - тут лучшее посмотреть про архитектуру - коротко тут и видео "TigerGraph Architecture overview" - Why TigerGraph is 100x faster than the competition and provides the lowest cost of ownership
Статья является переводом и немного про другое - про аналитику. Что мне понравилось - наглядно показана разница между схемами реляционной БД и Графовой. Попробуйте сравнить Рисунок 1 и Рисунок 3, когда планируем схему - тут многие мыслят "традиционно" таблично.
В конце ссылки на сравнения по производительности. Более свежие сравнения:
Что касается миграции - есть готовые для MySQL и PG. Но если мы говорим про BigData - то TigerGraph часто используется поверх существующих хранилок (aka Spark) и реализует графовую аналитику на скоростях.
Тут Андрей вроде просто рекомендует попробовать другие настройки. С другой стороны дефолты на то и дефолты, что мейнтейнер считает их более универсальными/оптимальными. Тот же host-gw по сравнению с vxlan во flannel требует L2 связности между хостами, что часто является непозволимой роскошью… Как обычно, у любого вопроса есть несколько критериев принятия решения.
Это всего лишь анонс мероприятия, не претендующий на научную точность.
Можете поучаствовать и задать вопросы непосредственно спикерам.
Кроме того, количество докладчиков с научными степенями — зашкаливает.
Ну и для полноты ссылок, сам драфт: GQL Early Working Draft v2.2. Для меня скорее важно, что это будет тьюринг-полный язык и по сути это будут программы. Синтаксический сахар, как писать запросы - привыкнем)
Мне статья понравилась, в одном месте кратко собраны Use Cases с точки зрения бизнес задач. Ничто не ново под луною...
Спасибо! Это случайно не Ваша работа ;)?
Но всё таки, это труд хорошего студента и его отчёт о работе.
https://github.com/OlofMorra/GQL-parser/blob/main/src/main/resources/report/A Semantics of GQL; a New Query Language forProperty Graphs Formalized.pdf
"Moreover, the syntax of GQL is very similar as that of Cypher and PGQL (as expected, GQL is based on those two languages)"
В целом, в процесс вовлечено довольно много людей и есть разные рабочие группы https://ldbcouncil.org/gql-community/pgswg/, публикация намечена на конец 2023 года.
Обещают выпустить GQL стандарт в конце 2022, там видно будет;)
Согласен
На видео ниже можно посмотреть детали архитектуры и Native Graph Storage - вершины и рёбра распределяются по сегментам и хранятся на одной партиции:
Видел много документаций, у TG вполне подробная и понятная документация, от сохи https://docs.tigergraph.com/. Можно найти довольно подбробную информацию - по Языку, алгоритмам и администрированию самой БД.
А что именно сомнительно? мы успешно пишем алгоритмы, которые работают внутри БД, без внешних библиотек и костылей.
У каждого свои задачи, если начинаешь запускать графовые алгоритмы или нужно проанализировать связи с глубиной 6 или 10 - можно выбрать любой инструмент, но на каком-то этапе упереться в стену: по производительности, по масштабированию, по удобству работы и т.д.
Помимо синтаксического сахара в запросах, важно чтобы хранение данных было изначально графовое. Насколько могу судить по статье https://habr.com/ru/company/otus/blog/518586/ про MSSQLSERVER - получается монструозный "графовый" запрос и скорость работы на больших данных ожидаемо просядет (ибо JSON в таблицах).
Тут конечно нужно исходить от задачи, можно и генератор JOIN'ов написать. В целом - не очень удобно запускать класс графовых алгоритмов поверх таблиц.
Тут как раз графовая схема является альтернативой EAV (Рисунок 3), что может быть проще.
Наш кейс умещается в 50GB сжатых данных. В нашем случае - данные и связи - это одно и то же, поэтому храним всё в одной БД. Тут наверно индивидуально всё, в целом подход: если данные нужны для анализа, подпадают под определеения вершины или ребра, тогда их используем.
С вендором общались и общаемся, в т.ч. по другим кейсам. Общаемся как по линии community, так и с инженерми напрямую. Уровнем и скоростью довольны, в TigerGraph пришли люди с большим опытом работы в других коммерческих БД, а таже практики из прикладных доменов.
Если Вы пробовали Neo4j или другие, тогда Вам точно стоит попробовать эту БД. С точки зрения производительности на графах - они как раз лидеры, остальные фоловеры (раз и два). С точки зрения стбильности - в продакшенах разных не первый год, у нас тоже стабильно.
Из примеров масштабирования - недавно был пример задачи AML для Blockchain от Merkle Science:
Видео работы - особенно интересно с 6 минуты https://www.youtube.com/watch?v=_5Z6c8G-AFk
По бизнес логике - конечно если несколько БД, тут некуда деваться и транзакцию нужно делать уровнем выше, на уровне приложения.
По запросам - тут сложнее, мастер есть в рамках GSQL запроса. Реплика фактор 2 или другой позволяет обеспечить сохранность данных.
Эти вопросы хорошо будет осветить в отдельной статье, спасибо!
Если коротко - пользуемся сами, ставим и поддерживаем.
Изначально были задачи на графой аналитике, посмотрели что есть с точки зрения масштабирования/скорости, удобства и текущих заказчиков (=продакшен), остановились на этой БД.
Также подкупило наличие ready-to-go решений - с набором данных и готовыми алгоритмами = просто добавь свои данные.
Тут скорее идея в том, что бизнес-логику можно реализовать с помощью GSQL. Поскольку это полноценный язык программирования, мы можем сделать циклы, ветвления и т.д.:
REST Request --> GSQL + business logic --> JSON Result
Massive-write - это тоже случай для этой БД. Например кейсы с CyberSec аналитикой, когда у нас большой стрим данных.
Статья скорее для замученного
нарзаномАналитика, а не Администратора...Документация: https://docs.tigergraph.com/ (в разделе Resourses на сайте)
До 50 GB (~150GB сырых данных) - free edition
Основные Advantages перечислены на этой странице:
написана на С++ с нуля (в продакшене с 2012, публична с 2017),
DeepLink аналитика (10+ хопов) - особеннно важен,
MPP распределённая база,
быстрая загрузка больших датасетов, они сжаты и занимают меньше места в ОП,
ACID(OLTP)+OLAP = HTAP,
In-Database аналитика, тьюринг полный язык GSQL, который наиболее близок к грядущему GQL стандарту
GUI для моделирования и No-Code
Не только Batch, но и Real-Time аналитика на больших датасетах
Про ACID:
GSQL - есть готове к работе графовые алгоритмы, а также решения конкретных бизнес-задач. Алгоритмы открыты, их можно модифицировать и использовать как примеря для своих задач = например захочется чуть поправить PageRank.
Анализ связей на распределённом графе - одно из ключевых преимуществ. В отличие от Neo4j тут не надо сводить связанные данные в одну ноду: они могут быть реально распределены.
Как это сделано - тут лучшее посмотреть про архитектуру - коротко тут и видео "TigerGraph Architecture overview" - Why TigerGraph is 100x faster than the competition and provides the lowest cost of ownership
Для небольших данных - согласен.
Но когда у вас 100M+ вершин и 10B+ связей - тут клиент боюсь не справится...
Статья является переводом и немного про другое - про аналитику. Что мне понравилось - наглядно показана разница между схемами реляционной БД и Графовой. Попробуйте сравнить Рисунок 1 и Рисунок 3, когда планируем схему - тут многие мыслят "традиционно" таблично.
В конце ссылки на сравнения по производительности. Более свежие сравнения:
https://www.tigergraph.com/benchmark/
https://www.tigergraph.com/blog/truth-behind-neo4js-trillion-relationship-graph/
Что касается миграции - есть готовые для MySQL и PG. Но если мы говорим про BigData - то TigerGraph часто используется поверх существующих хранилок (aka Spark) и реализует графовую аналитику на скоростях.
Добрый! Пользуюсь услугами.
Репликацию делаете с помощью DRBD? Если да, то синхронно (ожидая реплики) или асинхронно (реплицируется после записи)?
Можете поучаствовать и задать вопросы непосредственно спикерам.
Кроме того, количество докладчиков с научными степенями — зашкаливает.