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

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

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

Определенно.

Ничего себе, оказывается сабж даже популярнее, чем MariaDB. Неожиданно.

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

Неожиданно.

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

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

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

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

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

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

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

думаю для корректности рейтинга к MariaDB надо приплюсовать MySQL

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

лучше OrientDB!

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

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

Графы в таблицах? Как ты себе это представляешь?

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

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

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

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

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

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

Neo4j

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

Данные в таблицах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и попробуй поработать с ними

Я имел в виду именно обработку, а хранить можно блобом.

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

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

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

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

например?

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

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

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

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

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

например?

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

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

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

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

Даже Mysql не соблюдает правила Кодда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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