Пытаюсь я понять смысл концепции NoSQL на примере, допустим, MongoDB.

Итак, мы имеем документо-ориентированную базу данных. Где, как я понимаю, есть ключ и документ, который представляет собой некий JSON.

Но в чем преимущество такого подхода? Если совсем утрировать, то чем это хуже, если в реляционной БД сделать две колонки:




Где вторая колонка - это тип данных Json, который есть уже в большинстве современных СУБД. Куча функций по работе с Json также есть.

Сделать шардирование по ID? Но это легко реализуется и тем же Oracle / Postgress / MySQL.
Отказаться от транзакций? Ну например, можно в MySQL использовать движок MyISAM.

Чувствую, что чего то не понимаю концептуального, может быть есть смысл при специфических режимах работы? Было бы очень интересно, если кто расскажет свое видение, кто поработал и с тем, и с другим.

Ну например поиск может быть не только по ID

да прост кто-то сделал как бы sql сервер для младшей сестры которая не умеет в скл.

Смысл таков, что в NoSQL базах в отличие от реляционных структура данных не регламентирована (или слабо типизированна, если проводить аналогии с языками прогаммирования) — в отдельной строке или документе можно добавить произвольное поле без предварительного декларативного изменения структуры всей таблицы. Таким образом, если появляется необходимость поменять модель данных, то единственное достаточное действие — отразить изменение в коде приложения.

Например, при переименовании поля в MongoDB:

в общем смысла нет, так как это и так делалось задолго до изобретения носкл.

Статическая типизация vs динамическая типизация - бессмысленный спор. А это он.

Для меня еще плюс в том, что становятся не нужны всякие хитромудрые ORM. С NoSQL работать настолько просто, что вопрос нужно иначе ставить: "а что мне в данном случае даст реляционная БД"? Там есть свои подводные камни и явные недостатки тем не менее.

что становятся не нужны всякие хитромудрые ORM

так они по дефолту были не нужны.
ибо мертоворожденное оно.

С NoSQL работать настолько просто, что вопрос нужно иначе ставить: "а что мне в данном случае даст реляционная БД"?

или еще иначе.

если в ноускл json, то будет ли мне c ним так же удобно и хорошо как на sql сервере с xmltype

Да нет никакой великой noSQL мудрости, просто он шустрый за счёт своей упрощённости. Все вот эти ключ=>значение хранятся как бы в большом хэшированном массиве, получаем О(1) при произвольном доступе, вот и всё. Так удобно например, хранить всякие справочники, сессии юзеров, токены, короче, всё то, что очень много и часто читается.
Никто не неволит, можно использовать и классику, просто в некоторых случаях nosql без всяких индексов получается быстрее.

Если понадобится делать отчёты (а в итоге много отчётов), то sql по-любому выиграет.

> Kerk ©   (09.10.17 16:42) [1]
> Ну например поиск может быть не только по ID


Постгрес умеет в условиях указывать поля json-полей. Строить по ним индексы тоже умеет.

> Ну например поиск может быть не только по ID

да, но в приведенной структуре:




в SQL-базе поиск будет также возможен. Зависит от предоставленных встроенных или самописных функций, ну например:

select *
from MyTable m1
where JsonFuncInt(m1.JsonDoc, 'root.prop4.visible[0]') = 5

Фишка в том, что NOSQL база априори быстрее это обработает?
Или речь о широких возможностях JsonFuncXXX... из коробки?

Возможно, есть запосы такого вида, которые трудно "переписать" в стиле SQL?

Вот не могу уловить суть :(


> Все вот эти ключ=>значение хранятся как бы в большом хэшированном
> массиве, получаем О(1) при произвольном доступе

так и в SQL на любое поле можно индекс навесить.

>
> Возможно, есть запосы такого вида, которые трудно "переписать"
> в стиле SQL?

Не, это в ноускл запаришься делать простейший для реляционки запрос.
Для заметок я использую нотепад++ - очень удобная штука. Только для текстовых заметок. Функционала для этих нужд более чем. Если проводить аналогии, блокнот - ноускл, ворд - реляционка. Это всё. Другие объяснения - маркетинг, либо невежество

1. генетическая денормализация хранения данных, что позволяет сразу получать данные а не собирать их из запросов. Такой себе in-place cache.
2. хранение неструктированных данных и необязательны индексы
3. не нужно соблюдать логическую целостность данных, что очень удобно для данных разбросанных по разным сервакам, можно обновлять/менять данные частями инкрементально
4. намного круче маштабирование, так как по факту сервер работает только с "корячими" данными, можно поднять за секунду еще один инстанс и на него преенаправить балансировщиком нагрузку и там уже будут все "горящие" данные при первом же запросе.
5. позволяет делать совсем уж дикие запросы с помощью агрегатов и пайплайнов
6. легкая миграция данных, так как схемы нет.

О дивный новый селфи-мир))

>>Пытаюсь я понять смысл концепции NoSQL на примере, допустим, MongoDB.

Лучше на примере BerkleyDB.

NoSQl - это просто storage, фактически просто файловая система. Отказ от атомарности и изоляции резко снижает накладные расходы.

Мне кстати вот эта база сильно понравилась :

https://github.com/bloomberg/comdb2

Преимущества Nosql в масштабируемости + sql-подобный язык запросов + LUA для хранимых процедур.

Удалено модератором

> Мне кстати вот эта база сильно понравилась

probably the best one:
https://www.arangodb.com/

> Отказ от атомарности и изоляции резко снижает накладные
> расходы.


Выкинули часть тяжеловесной обвязки + sql, получились типа базы. На больших объемах, наверно, оправданно, если юзают.