Здравствуйте, SergASh, Вы писали:
M>>В отдаленном будущем Bolt заменит REST API к базе.
SAS>А что было не так с REST API ?
Производительность общения с СУБД через HTTP не всегда устраивает.
PS. Наша компания (и я в том числе) так же делает свою графовую СУБД, хоть и в более узкой нише чем neo4j. У нас двоичный протокол (называется SNARL, сделан на основе Google Protobuf) был всегда.
Мне в Neo4j очень понравился Cypher. Писал те же самые запросы, что у нас сейчас на SQL сделаны получается гораздо выразительнее. Вместо экрана запроса 3-4 строчки. Просто здорово!
Но очень смутила производительность. Делал разные проверки, но наиболее запомнилась проверка на связность двух узлов. В несколько десятков раз получилось медленнее, чем на SQL Server. Для тех же самых данных.
Кто-нибудь знает про аналогичные Cypher языки, надстройки для SQL баз данных? Я так прикинул можно было бы написать свой транслятор в принципе... Но лучше взять что-то готовое.
Здравствуйте, Spinifex, Вы писали:
S>Кто-нибудь знает про аналогичные Cypher языки, надстройки для SQL баз данных? Я так прикинул можно было бы написать свой транслятор в принципе... Но лучше взять что-то готовое.
Это сложнее чем тебе кажется. Cypher не стандартизирован и даже семантика его операторов формально не описана (насколько я знаю), поэтому трансляция в SQL *в общем случае* — дело мутное (например, непонятно как доказывать корректность). Поэтому общих трансляторов и нет. Можно написать транслятор для частных случаев.
В качестве сравнения можешь посмотреть на SPARQL — он стандартизирован W3C, его семантика формальна и есть реализации на основе трансляции в SQL (например, так поступает Virtuoso). Правда насколько это быстрее получается чем нативная реализация — зависит от модели данных и самих запросов.
Здравствуйте, kl, Вы писали:
kl>Здравствуйте, Spinifex, Вы писали:
S>>Кто-нибудь знает про аналогичные Cypher языки, надстройки для SQL баз данных? Я так прикинул можно было бы написать свой транслятор в принципе... Но лучше взять что-то готовое.
kl>Это сложнее чем тебе кажется. Cypher не стандартизирован и даже семантика его операторов формально не описана (насколько я знаю), поэтому трансляция в SQL *в общем случае* — дело мутное (например, непонятно как доказывать корректность). Поэтому общих трансляторов и нет. Можно написать транслятор для частных случаев.
kl>В качестве сравнения можешь посмотреть на SPARQL — он стандартизирован W3C, его семантика формальна и есть реализации на основе трансляции в SQL (например, так поступает Virtuoso). Правда насколько это быстрее получается чем нативная реализация — зависит от модели данных и самих запросов.
SPARQL это уже совсем не то. Даже Gremlin мне не так понравился...
Да и я вобщем-то и не настаиваю прямо на стандартизированном трансляторе, достаточно иметь что-то похожее.
