Зачем NoSQL программистам

[rainman_rocks]

В последнее время, как видим, пошла мода на NoSQL.
Термин, собака, размыт до черезвычайности, под ним все подразумевают разное, кто во что горазд - кто-то интересуется переработанными RDBMS типа BigTable, кто-то болеет за key-value storage, парни с PostgreSQL вообще пошутили на тему QUEL.

Сконцентрируемся всё-таки на основном значении: системы

Comments

[vitus_wagner]

Это из серии "я хочу чтобы у меня все было, и мне за это ничего не было". А так не бывает. SQL хорош тем, что под ним лежит хорошая математика - реляционная алгебра. Эта математика накладывает на возможности представления довольно большие ограничения. Но эти ограничения являются платой за возможность эффективно оптимизировать запросы.

К сожалению, большинство разработчиков, хватающихся сейчас за NoSQL никогда в жизни не слышали слова CODASYL. Поэтому не знают, что история баз данных начиналась с объектно-ориентированных БД, где не было никаких ограничений. Но и искать было крайне затруднительно.

[zhengxi]

> Но эти ограничения являются платой за возможность эффективно оптимизировать запросы.

Вот взять тот же пример с постами и коментами.
Там ровно наоборот получается - для реаляционного решения нужен индекс по всем коментам, поиск по которому не будет лучше логарифмического (а комментов много, так много, что они и на один сервер могут не поместиться).
При этом post_id используется только для связи поста и коммента.
Есть RDBMS которые это "поймут" и эффективно соптимизируют до O(1), до (неявного, скрытого от автора SQL-запросов) хранения указателей на комменты рядом с постом ?

> К сожалению, большинство разработчиков, хватающихся сейчас за NoSQL никогда в жизни не слышали слова

Еще есть слово IMS, IMS is reportedly IBM's highest revenue software product, and it continues to grow.
Вполне такой NoSQL.

[legolegs]

>Там ровно наоборот получается - для реаляционного решения нужен индекс по всем коментам, поиск по которому не будет лучше логарифмического (а комментов много, так много, что они и на один сервер могут не поместиться).

Однажды встаёт необходимость в чём-то вроде списка комментов одного юзера - иноэскуэльщикам остаётся сказать "%ляяяяяяяя.....".

[rainman_rocks]

Вы слыхали фразу Д. Кнута о предварительной оптимизации?

А фразу О. Бендера касательно битья и плача?

Для реляционных БД такая внезапная "необходимость" обернётся точно таким же create index, который точно так же займёт N часов-дней-недель.

Поймите, в РСУБД никакой сверхъестественной магии нет. Там все те же структуры данных и алгоритмы. Вы их точно так же можете воспроизвести и при помощи NoSQL.

[rainman_rocks]

Какая функциональность-то? Цикл по записям с занесением списка указателей в ассоцмассив?
Это элементарная задача.

[rainman_rocks]

Эмммм... во-первых, s/long/log/, во-вторых, CREATE INDEX выполняется за O(n).

[rainman_rocks]

Поиск по нему будет O(1), поскольку список написанных камментов будет храниться в записи каждого пользователя.

Итого, поиск без индекса в SQL/NoSQL - O(n).
Построение индекса в SQL/NoSQL - O(n).
Поиск по индексу в SQL - O(log n), NoSQL - O(1).

Это, собсна и есть тот "прирост производительности"/"масштабируемость", на которые фапают носкульщики.

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

[legolegs]

>Итого, поиск без индекса в SQL - O(n), в NoSQL - O(n) плюс написание и отладка этого поиска.

fixed.

[rainman_rocks]

Само собой. Зато мы этот поиск можем тонко настроить под свои нужды. А в некоторых SQL-базах, гм, fullscan может серьёёёёзно помешать работе.

[rainman_rocks]

Для "более интересной задачи" ответ ровно тот же.
Если у вас нет индекса - это фуллскан, и для RDBMS, и для NoSQL.
Если у вас есть индекс - это O(log n), и для RDBMS, и для NoSQL.

[rainman_rocks]

Конечно просядем при записи. Примерно так же, как и RDBMS проседают при записи при наличии множества индексов. Те же способы решения - отложенная запись, eventual consistency.

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

Проблем реализовать упорядоченное множество (хоть дерево, хоть тупо скиплист) в NoSQL не вижу никаких. В том же JSON делается элементарно, причём с возможностью тонкого управления шардингом.