LINUX.ORG.RU

Neo4J 2.2 — новая версия графовой базы данных

 ,


3

1

25 марта вышла новая версия графовой базы данных Neo4J.

В этом релизе представлены улучшения, которые, как утверждается, позволят существенно повысить производительность операций чтения и записи данных, а также улучшают возможности по отладке и тестированию.

Ключевые моменты изменений версии 2.2:

  • новый планировщик запросов для языка Cypher основанный на анализе затрат (cost-based optimizer);
  • поддержка профилирования и отладочного вывода для запросов Cypher;
  • новый механизм кеширования операций чтения, основанный на размещении страниц кеша в памяти (in-memory page cache);
  • новый механизм быстрой буферизации записи и оптимизация сброса транзакций на диск.

На начало 2015 года графовая база данных Neo4J занимает 23 место по популярности (по версии сайта DB-ENGINES).

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: ymn (всего исправлений: 3)

На начало 2015 года графовая база данных Neo4J занимает 23 место по популярности

Это как дистровотч или тиобе?

bj
()
Ответ на: комментарий от slyjoeh

Я думал sqlite будет тоже в топе (часто вижу его в мелких софтинах), а тут вон оно что.

alozovskoy ★★★★★
()
Ответ на: комментарий от slyjoeh

Неожиданно.

Вполне ожидаемо, mariadb-специфичных проблем в гугле ищут мало.

bj
()
Ответ на: комментарий от cyanide_regime

есть in-memory графовые базы, написанные на С?

вообще есть, например WhiteDB или VertexDB, но я ими честно не пользовался

PS можно еще посмотреть на Weaver, но это вроде совсем в сторону

shty ★★★★★
() автор топика
Ответ на: комментарий от bj

Это как дистровотч или тиобе?

все на самом деле еще немного хуже... :)

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

shty ★★★★★
() автор топика

Механизм не новый, новое то, что кэш автотюнится. Раньше поддержка отображенных в память файлов (за счет чего кэширование) описывалась в конфиге наряду с типом кэша (тоже не самый легкий выбор), и вообще было только на люнипсе, а виндузятники страдали, а теперь все автотюнится и поддерживается на всех платформах. Годно!

anonymous
()
Ответ на: комментарий от anonymous

пока не было времени в сорцы глядеть, но насколько я понял - таки все же механизм новый, раньше - да, был memory mapping, а теперь совсем in-memory сделали

shty ★★★★★
() автор топика
Ответ на: комментарий от slyjoeh

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

дело не в объективности, а в погрешности, и в понимании рейтинг чего это

пока что MariaDB и MySQL не сильно разъехались и многие вещи прекрасно хиляют и там и там, так что про Maria в основном спрашивают специфичные для нее вещи, т.о. думаю реальное количество установок скорее всего больше, нежели следует из данного рейтинга

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

Не понимаю я, в чем профит от nosql. Имхо, в таблицах все логично.

а ты попробуй положить хотя бы 200Тб неструктурированных данных в таблицы и попробуй поработать с ними, потом посмотрим что ты скажешь ))

shty ★★★★★
() автор топика

Neo4j

Неофодж? Настоящая арийская БД?

mvas78
()
Ответ на: комментарий от shty

Ну так надо сразу данные записывать в таблицы структурированно. Если данные совсем не структурирование, то и nosql не сможет их обрабатывать.

Klymedy ★★★★★
()
Ответ на: комментарий от Klymedy

Если данные совсем не структурирование, то и nosql не сможет их обрабатывать.

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

если же данные совсем сильно разные - тут уже нужно строить какое-нибудь data lake, и опять nosql во все поля

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

кроме того обычно на таких объемах (по крайней мере в моих, не ручаюсь, что строго прямых, руках) традиционные базы начинают серьезно проседать по производительности

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

Предположим, есть художественная литература, как пример совсем неструктурированных данных, содержащая описания персонажей. Как nosql может, к примеру, вывести средний возраст персонажей, имеющих 2 или 3 детей?

Klymedy ★★★★★
()
Ответ на: комментарий от shty

Вот с производительностью возможно, да. Хотя неужели нельзя просто оптимизировать хранение данных, оставив sql-интерфейс?

Klymedy ★★★★★
()
Ответ на: комментарий от Klymedy

Предположим, есть художественная литература, как пример совсем неструктурированных данных, содержащая описания персонажей. Как nosql может, к примеру, вывести средний возраст персонажей, имеющих 2 или 3 детей?

Вы часом не путаете проблему хранения неструктурированных данных и их обработки, не?

если что, можно поговорить и за обработку )

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

неужели нельзя просто оптимизировать хранение данных, оставив sql-интерфейс?

почему нельзя, можно - SQL же декларативный язык

кстати, к примеру, упоминавшаяся в треде OrientDB вполне себе поддерживает SQL как язык запросов

и если посмотреть на CQL (Cassandra), то можно заметить, что он вообще-то практически один в один тот самый SQL

shty ★★★★★
() автор топика
Последнее исправление: shty (всего исправлений: 2)
Ответ на: комментарий от Klymedy

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

а про «поработать» имелось в виду запись/чтение, индексирование, масштабирование и т.п.

shty ★★★★★
() автор топика
Ответ на: комментарий от shty

Базы могут делать обработку данных. Хранить неструктурированные данные можно в блобах. А докатимся мы до 5.4.

Klymedy ★★★★★
()
Ответ на: комментарий от Klymedy

Базы могут делать обработку данных.

например?

Хранить неструктурированные данные можно в блобах.

можно, но нафига тогда реляционную базу брать?

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

NoSQL подразумевает не только и не столько отказ от SQL как языка запросов. Терминологическая путаница.
Возможно наименее плохим определением nosql СУБД будет что то вроде: «СУБД сознательно отказавшаяся от соблюдения одного или нескольких требований предъявляемых реляционным СУБД (с.м. 12 правил Кодда[1]) ради получения некоторых выгод».

[1] https://ru.wikipedia.org/wiki/12_правил_Кодда

MrClon ★★★★★
()

Вопрос чайника: В чем популярность графовой базы данных Neo4j ? Графовая модель дает скорость ? Но тогда должна быть реализация на C - скорость будет больше.

Oaks
()
Ответ на: комментарий от shty

например?

UPDATE per­sons SET street = 'Nis­sesti­en 67', ci­ty = 'Sand­nes' WHERE lastname = 'Tjes­sem' AND firs­tna­me = 'Ja­kob';

Разве это не обработка?

нафига тогда реляционную базу брать?

Нафига связываться с неструктурированными данными? И что nosql может такого с ними делать, чего не могут обычные?

Klymedy ★★★★★
()

у меня сразу ассоциация с бтрфс
как в этой базе обстоят дела со снэпшотами ?

kto_tama ★★★★★
()
Ответ на: комментарий от Oaks

Лучше OrientDB. Я тебе гооворю. Там и графовый движок есть, да!

anonymous
()
Ответ на: комментарий от Oaks

В чем популярность графовой базы данных Neo4j ?

хорошо сделана, нормальная документация

Графовая модель дает скорость ?

графовая модель хорошо подходит для моделирования отношений, например граф друзей или предпочтения пользователей

Но тогда должна быть реализация на C - скорость будет больше.

Java дает сравнимую скорость, и ее правильно готовить легче и быстрее

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

UPDATE per­sons SET street = 'Nis­sesti­en 67', ci­ty = 'Sand­nes' WHERE lastname = 'Tjes­sem' AND firs­tna­me = 'Ja­kob';
Разве это не обработка?

вообще нет, это то что называется CRUD

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

и у меня вопрос, как Вы такие запросы к блобу собираетесь строить?

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

Нафига связываться с неструктурированными данными?

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

И что nosql может такого с ними делать, чего не могут обычные?

да тот же CRUD умеют делать, только с учетом несколько других задач и окружения

Важный момент! Я не топлю здесь за отказ от реляционных баз, надо лишь понимать их ограничения и использовать строго тогда когда надо.

shty ★★★★★
() автор топика
Ответ на: комментарий от Klymedy

Так вот почему он такой популярный, это ведь оказывается не унылый SQL, а модный хипсторский noSQL!

А если серьёзно я не просто так добавил оговорку про «сознательный отказ». Предполагается что мускуль пытается быть труЪ РСУБД, но не всегда осиливает.

P.S. ссылка намекает на не соблюдение восьмого правила, «физическая независимость данных»? Думаю подразумеваются уровень штатных интерфейсов приложения, а не уровень хранения данных.

MrClon ★★★★★
()
Ответ на: комментарий от Klymedy

Можете привести пример таких неструктурированых данных?

множество всех веб-ресурсов, медицинские данные, научные данные, данные о работе предприятия, на самом деле совокупность данных почти любой предметной области - неструктурирована

shty ★★★★★
() автор топика
Ответ на: комментарий от Oaks

Графовая модель дает скорость ?

Скорее наоборот. Хотя некоторые графы наверное очень хорошо партиционируются, что может быть полезно при выдрочке скорости.
Граф даёт удобство. В некоторых случаях.

MrClon ★★★★★
()
Ответ на: комментарий от Klymedy

Множество веб-ресурсов использует реляционные БД, и данные там структурированы.

1) 4.2 номер 1: про реляционные данные - это не так, Google, Amazon, Yahoo, (+100500 тысяч их, и все веб-ресурсы) используют нереляционные базы данных (возможно наряду с реляционными, и тем веселее)

2) 4.2 номер 2: Вы и правда считаете что домашняя страничка Васи Пупкина согласована с тем что сделано внутри Facebook (например) и одновременно с сообщениями Марьи Петровны на форуме садоводов? да Вы оптимист отчаянный

shty ★★★★★
() автор топика
Последнее исправление: shty (всего исправлений: 2)
Ответ на: комментарий от MrClon

Я скажу, как член команды, которая юзает непосредственно neo4j в проекте. У нас древовидная структура, сущности тесно связаны и часто достаются по длинным цепочкам (типа как путь к папке). Тут оно достаточно тормозное, ибо путь может быть длинным, и беготня по двадцати связанным нодам может влететь в копеечку с учетом того веера ребер, которые от них расходятся (а тебе нужно выбрать на каждом шаге какое-то одно). Это, конечно, лучше, чем дрочка вприсядку моделирования иерархических СД на SQL (да, да, давайте сюда с вашими nested sets или 100кратными джойнами таблицы с самой собой).

Но когда нужно по коротким цепочкам каких-то паттернов ходить, либо просто найти цепочку между несколькими сущностями - тут ваще огонь.

Ну и плюс индексы и модель с метками (индексы наметках значительно помогают).

В общем, я за то, чтобы кричать ненужно только по делу, а не потому, что тебе пока не пригодилось (это я не тебе, а вообще всем).

anonymous
()
Ответ на: комментарий от Klymedy

Ты как граф в таблицу положишь, сладенький? А если у тебя там циклы ещё есть, то твой маршаллер вообще самоубьется.

cherry-pick
()
Ответ на: комментарий от anonymous

Анон, ты часом не в курсе как там унутре сделано хранение и обработка графов?
Часто говоря о графовых СУБД говорят только об удобстве интерфейса, а вот о поездатых алгоритмах для эффективной работы с графовыми данными слышать как-то не приходилось.
Возникают опасения что внутре у ей неонка какая-то кандовость вроде той-же РСУБД (или какой-нибудь монги) с таблицами вершин и рёбер, а СУБД представляем тобой просто удобный интерфейс.
Подчеркну — это вопрос, а не утверждение.

MrClon ★★★★★
()
Ответ на: комментарий от shty

Существование хороших, годных историй успеха с nosql СУБД не умаляет достоинств РСУБД, в частности не умоляет их годность в качестве варианта по умолчанию.
Так-же наличие таких саксес стори не оправдывает влажных восторгов хипсетров норовящих пропихнуть новомодную штучку куда попало.

С другой стороны достоинства РСУБД и тупость тупых хипстеров не переводят все nosql СУБД в разряд ненужных ненужностей не имеющих права на существование и не оправдывают снобистское отрицание того факта что в некоторых случаях использование nosql СУБД является разумным инженерным решением.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Не, там не таблицы, эффективный бинарный формат со своим хранилищем для каждого типа сущностей (ноды отдельно, отношения отдельно и т.д.). Можешь скачать с их сайта архивчик и запустить, а потом глянуть в папке, куда оно складывается - файлы со словом store

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.