Как объяснить своей бабушке разницу между SQL и NoSQL / Комментарии / Хабр

stranger_shaman 13 сен 2019 в 12:29

NoSQL позволяет сохранять любые данные в «документе»

Cassandra, ClickHouse тоже NoSQL. Но документов там нет, а таблицы есть.

ilnuribat 13 сен 2019 в 19:03

можно ещё дописать наличие/отсутствие транзакций, согласованность данных

ilyalazarev 13 сен 2019 в 19:04

тоже заметил, что в статье не хватает

nitrosbase 13 сен 2019 в 14:24

а также графические базы данных и поисковые системы, такие как Elasticsearch и Solr.

Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему).

Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.

Viceroyalty 13 сен 2019 в 17:51

Собственно спрашиваю: почему Neo4j и AWS Neptune?
Просто чувствую, что в моем проекте (десктопное ПО, возможно в будующем смасштабируется до Team версии), скоро понадобится какая-то база данных

nitrosbase 14 сен 2019 в 01:37

Ну, указать — не то же самое, что рекомендовать…

Neo4j я указал бы по той причине, что самая популярная. Дальше для полноты картины хочется указать что-то с поддержкой Gremlin в противоположность Cypher; что-то с поддержкой модели RDF наряду или в противоположность поддержке LPG; что-то облачное в противоположность on-premise. А позиция всего одна осталась. Но вот Neptune позволяет проиллюстрировать все эти «альтернативы» одним примером.

Если облачность читателю заведомо неинтересна, можно указать AnzoGraph. Он правда, скорее OLAP-решение (кстати, вот еще одна «координата»), создан выходцами из IBM Netezza и Amazon Redshift, но это современный такой OLAP, ближе к HTAP даже.

Короче говоря, выбор обусловлен сугубо дидактическими соображениями. Из этих же соображений не стал бы указывать CosmosDB, OrientDB, ArangoDB, которые следуют сразу за Neo4j на DB-engines. «На самом деле» они документные, как пишу об этом здесь.

Если же пытаться рекомендовать…

В плане производительности Neo4j обычно «сакральная жертва» во всех бенчмарках. Но раз у вас не что-то «высоконагруженное», может, и хватит. Кстати, совсем «встраиваемое» не рассматриваю, раз вы все-таки хотите team-версию.

Разные enterprise-характеристики (та же горизонтальная масштабируемость) вам тоже, видимо, не очень нужны будут, да? Тогда круг кандидатов расширится. Если требуется с возможностью бесплатного использования в коммерческом продукте или опенсорсное, естественно, сузится.
Мультимодельность и развитые API (language integrated queries и пр.) в перспективе сокращают время разработки. «В перспективе» — это чаще в «следующем проекте», конечно, но как знать, может, успеется и в текущем. Так что ArangoDB и OrientDB я бы вернул в список кандидатов.

Тут интереснее ваша задача. Я-то, конечно, не удивлен, нынче повсюду «connected datа» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку.

Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится.