никакой

просто джава тут просто в качестве прокси выступает для взаимодействия с данными и всего то

тоже самое можно на расте написать за пару недель и оно будет полезнее и быстрее во много раз

оно все хранит точки и связи, а графовая база отвечает за многопользовательский сервер, который по запросу  на языке запросов одновременно от многих пользователей проходится по огромному количеству точек и связей, сохраняя нужное, и это как раз на джаве написано

мне в этом плане только dgraph на го нравится

у них свой key value data layer на го (badger)

у них вся база на go, только вот она не готова в нормальный продакшн, да еще и проприетарная

а раньше rocksdb был от фейсбука
но потом взяли и написали свой, так как оказались умнее что ли, не знаю

почему не готова?

Што фондейшн правда основан на скулайте?

Типа у него своего стораджа нету

да

Кек

Я давно проверял, по-моему не было возможности ограничить количество одновременных запросов, количество памяти и время под запрос. То есть dgraph можно заддосить сложными запросами и она упадет от пережора памяти. Может как однопользовательская штука в какой-то закрытой компании, где с ней будут нежно-нежно обращаться, она и работает, но как многопользовательская база данных к продакшену такое допускать рискованно, то есть какой-нибудь graphql api к гитхабу на основе dgraph не умел бы ограничивать сложность запросов без допиливания последней

Так оно же наружу не торчит, зачем бояться дудоса?

А, ну если падает то да

к gql-ю можно налепить Query Complexity и прочей фигни
чтобы внаружу апи была а под защитой

query complexity не такая простая вещь, она зависит от базы, от ее способа выполнения запросов

ну и главной причиной не брать dgraph я считаю ее проприетарность

кеширование, рейт лимит, query cost, query complexity, query depth

этого мало?