Комментарии 33
Обычная бесполезная маркетинговая статья.
Нет ничего ни о производительности и удобстве работы с реальными данными в реальных условиях (миграция текущего приложения на эту базу, задержки и скорость под нагрузкой и т.д.)
Статья является переводом и немного про другое - про аналитику. Что мне понравилось - наглядно показана разница между схемами реляционной БД и Графовой. Попробуйте сравнить Рисунок 1 и Рисунок 3, когда планируем схему - тут многие мыслят "традиционно" таблично.
В конце ссылки на сравнения по производительности. Более свежие сравнения:
https://www.tigergraph.com/benchmark/
https://www.tigergraph.com/blog/truth-behind-neo4js-trillion-relationship-graph/
Что касается миграции - есть готовые для MySQL и PG. Но если мы говорим про BigData - то TigerGraph часто используется поверх существующих хранилок (aka Spark) и реализует графовую аналитику на скоростях.
в 2021 всё на клиенте джойнится , проблем нету.
Тоесть GetVideos
Сразу показываем видео
Сразу ПОДгружаем GetLikesCount допустим
Слишком маркетинговая статья. Перешел на сайт. Там там чтобы добраться до документации (не how to, не hello world) - это нужно изрядно постараться. Всё, что попадается - это только "купите нас полностью".
Жаль. Мне симпотичны графовые БД (neo4j, OrientDB, Titan, и т.д.). Но вот сходу понять какие ключевые фичи есть у TigerGraph - сложно. Как я понял ключевое - это набор готовых функций анализа графа + возможность писать свои.
Не очень понятно что с ACID транзакциями (как я понял они ACID только локально / in-memory).
Как именно реализован распределенный граф (partitioning, sharding, ...) и какие имеются ограничения - так же не нашел.
Статья скорее для замученного нарзаном Аналитика, а не Администратора...
Документация: 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:
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
Спасибо за такой развернутый ответ. Он полезнее чем сама статья :)
К сожалению ограничение по транзакциям достаточно существенные:
Transactions are defined as follows:
Each GSQL query is a transaction. Each query may have multiple read or write operations.
Если я правильно понимаю. То не получится сделать: BEGIN -> GSQL -> business logic -> GSQL -> COMMIT
И это существенно ограничивает область применения подобных транзакций.
Внутренний механизм согласованности строится поверх Zookeeper + Kafka.
Сама БД заточена под massive-read операции. Т.к. запись во все реплики синхронная. Само по себе это не плохо и не хорошо.
Просто такие вещи по хорошему должны быть где-то на первых страницах. Чтобы понимать область применимости этой БД :)
Тут скорее идея в том, что бизнес-логику можно реализовать с помощью GSQL. Поскольку это полноценный язык программирования, мы можем сделать циклы, ветвления и т.д.:
REST Request --> GSQL + business logic --> JSON Result
Massive-write - это тоже случай для этой БД. Например кейсы с CyberSec аналитикой, когда у нас большой стрим данных.
Тут скорее идея в том, что бизнес-логику можно реализовать с помощью GSQL.
Это красиво только на бумаге. В реальности в этой бизнес-логике нужно обращаться к данным и функциям которые локальны с точки зрения клиента этой БД. И это не говоря про различные интеграции.
Представьте, что в Oracle/PostgreSQL есть только их pl/[pg]sql и транзакция только на их единичный вызов. Многое можете сделать? Что-то можно, но это ограничение очень сильное и с ним нужно считаться.
Massive-write - это тоже случай для этой БД.
Да, только вот физику никто не отменял. И для этих целей они вынужденно отключают синхронную репликацию и их преимущество master-less нивелируется.
Это не говорит против БД. Всё таки это принципиальные ограничения. Но вот об этом они нигде не говорят явно.
Вопрос: а о чём они ещё умалчивают? :)
По бизнес логике - конечно если несколько БД, тут некуда деваться и транзакцию нужно делать уровнем выше, на уровне приложения.
По запросам - тут сложнее, мастер есть в рамках GSQL запроса. Реплика фактор 2 или другой позволяет обеспечить сохранность данных.
Эти вопросы хорошо будет осветить в отдельной статье, спасибо!
In-Database аналитика, тьюринг полный язык GSQL, который наиболее близок к грядущему GQL стандарту
вот это реально сомнительно
А что именно сомнительно? мы успешно пишем алгоритмы, которые работают внутри БД, без внешних библиотек и костылей.
Я не уверен насчет этой фразы "язык, который наиболее близок к грядущему GQL стандарту" Уж скорее он будет ближе к Cypher, все таки 95% community это юзеры Neo4j и 5% это Gremlin. Хотя это не точно, Tigergraph'у больше всех надо.
Обещают выпустить GQL стандарт в конце 2022, там видно будет;)
А вот собственно и пруфы https://github.com/OlofMorra/GQL-parser/tree/main/src/test/resources/queries/gql/presentation
Спасибо! Это случайно не Ваша работа ;)?
Но всё таки, это труд хорошего студента и его отчёт о работе.
"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 года.
это ссылка из википедии https://en.m.wikipedia.org/wiki/Graph_Query_Language секция " The first implementation"
Есть еще вот https://arxiv.org/abs/2112.06217
Ну и для полноты ссылок, сам драфт: GQL Early Working Draft v2.2. Для меня скорее важно, что это будет тьюринг-полный язык и по сути это будут программы. Синтаксический сахар, как писать запросы - привыкнем)
Про алгоритмы, да нормально, в некоторых вещах даже больше чем на гремлине можно сделать
Ключевое отличие TigerGraph от остальных графовых бд это MPP и ACID одновременно, т.е. она HTAP бд (новое поколение). Шардинг реализован как node-based (есть два основных вида - predicate-based когда мы шардируем грани, и node-based когда мы шардируем вершины с исходящими гранями). Проблема node-based шардинга в supernode problem (когда очень много граней у вершины). Документация, да у них та еще, очень тяжело разобраться, видимо какой то особый образ мышления у китайцев. Это притом что я отлично знаю cypher и gremlin и знаю примерно каким должен быть запрос. Клиентам они говорят, купите лицензию, потом мы вам дадим наших инженеров и они все настроят и объяснят.
Ключевое отличие TigerGraph от остальных графовых бд это MPP и ACID одновременно, т.е. она HTAP бд (новое поколение).
Согласен
Шардинг реализован как node-based (есть два основных вида - predicate-based когда мы шардируем грани, и node-based когда мы шардируем вершины с исходящими гранями). Проблема node-based шардинга в supernode problem (когда очень много граней у вершины).
На видео ниже можно посмотреть детали архитектуры и Native Graph Storage - вершины и рёбра распределяются по сегментам и хранятся на одной партиции:
Документация, да у них та еще, очень тяжело разобраться, видимо какой то особый образ мышления у китайцев. Это притом что я отлично знаю cypher и gremlin и знаю примерно каким должен быть запрос. Клиентам они говорят, купите лицензию, потом мы вам дадим наших инженеров и они все настроят и объяснят.
Видел много документаций, у TG вполне подробная и понятная документация, от сохи https://docs.tigergraph.com/. Можно найти довольно подбробную информацию - по Языку, алгоритмам и администрированию самой БД.
А что побудило переводить статью о TigerGraph? Вы пользуетесь этой СУБД, или собираетесь ее ставить?
Если коротко - пользуемся сами, ставим и поддерживаем.
Изначально были задачи на графой аналитике, посмотрели что есть с точки зрения масштабирования/скорости, удобства и текущих заказчиков (=продакшен), остановились на этой БД.
Также подкупило наличие ready-to-go решений - с набором данных и готовыми алгоритмами = просто добавь свои данные.
Вам хватает ограничений бесплатной версии (50Gb данных в скомпрессированном виде ) или вы перешли на платную версию?
Если на платную, то что можете сказать об их уровне поддержки и скорости реагирования? Какие были к ним запросы?
Также подкупило наличие ready-to-go решений
Да. Это очень хорошее подспорье. Тут без вариантов.
Можете рассказать про:
Вы данные храните вместе со связями в этой БД?
Или данные отдельно, а эту БД только под граф-связи? (например именно так рекомендуют использовать neo4j)
Каков объем данных в Gb и какая топология деплоймента (партиции, реплики и т.д.)?
Сколько Vertex и сколько Edge?
Это реально интересно. Т.к. мои попытки залезть со своими сценариями на Neo4j и OrientDB привели к тому, что нео отпал, а OritentDB хоть и интересен с точки зрения архитектуры решения, но по производительности совершенно не устраивает. Да и наличие достаточно большого кол-ва багов которые годами не фиксятся удручает.
Наш кейс умещается в 50GB сжатых данных. В нашем случае - данные и связи - это одно и то же, поэтому храним всё в одной БД. Тут наверно индивидуально всё, в целом подход: если данные нужны для анализа, подпадают под определеения вершины или ребра, тогда их используем.
С вендором общались и общаемся, в т.ч. по другим кейсам. Общаемся как по линии community, так и с инженерми напрямую. Уровнем и скоростью довольны, в TigerGraph пришли люди с большим опытом работы в других коммерческих БД, а таже практики из прикладных доменов.
Если Вы пробовали Neo4j или другие, тогда Вам точно стоит попробовать эту БД. С точки зрения производительности на графах - они как раз лидеры, остальные фоловеры (раз и два). С точки зрения стбильности - в продакшенах разных не первый год, у нас тоже стабильно.
Из примеров масштабирования - недавно был пример задачи AML для Blockchain от Merkle Science:
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
Видео работы - особенно интересно с 6 минуты https://www.youtube.com/watch?v=_5Z6c8G-AFk
Проблема тут не в SQL, а в EAV, т.е. неверно подобранном паттерне при проектировании схемы БД.
Очевидно, что графовое решение намного проще в написании, чтении, понимании и сопровождении, чем один огромный SQL-запрос с 24 JOIN'нами. Графовое решение легко расширяется: позволяет выйти за рамки текущей "двухуровневой" проверки отношений без потери производительности и удобочитаемости.
Вот, кстати, совершенно неочевидно.
SQL запрос, хоть он и с 24 джойнами - абсолютно линеен, предсказуем, прекрасно читается и понимается. Вариант с графом - какая то мешанина из слабосвязанных кусков, чтобы понять которую нужно держать в мозгу одновременно кучу кусков кода.
Про энтити-атрибут-вэлью, как антипаттерн создания реляционных БД уже сказали.
Кстати, тем кто хочет попробовать графы в привычной среде советую установить MSSQLSERVER 2019, можно даже express. Их там есть.
У каждого свои задачи, если начинаешь запускать графовые алгоритмы или нужно проанализировать связи с глубиной 6 или 10 - можно выбрать любой инструмент, но на каком-то этапе упереться в стену: по производительности, по масштабированию, по удобству работы и т.д.
Помимо синтаксического сахара в запросах, важно чтобы хранение данных было изначально графовое. Насколько могу судить по статье https://habr.com/ru/company/otus/blog/518586/ про MSSQLSERVER - получается монструозный "графовый" запрос и скорость работы на больших данных ожидаемо просядет (ибо JSON в таблицах).
Вместо 24 JOIN в SQL запросе — реализация в графовой базе данных