Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

В чем фишка NoSQL / MongoDB?


Elementrary ©   (09.10.17 16:40

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

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

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

ID  |  JsonDoc

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

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

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


Kerk ©   (09.10.17 16:42[1]

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


rrrrrrr ©   (09.10.17 17:18[2]

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


xayam ©   (10.10.17 10:36[3]

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

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

BasicDBObject order = new BasicDBObject();
order.put(“date”, orderDate); // это поле было давно
order.put(“totalSum”, total); // раньше мы использовали просто “sum”


rrrrrrr ©   (10.10.17 11:20[4]

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


Kerk ©   (10.10.17 11:36[5]

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

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


rrrrrrr ©   (10.10.17 12:14[6]

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

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


rrrrrrr ©   (10.10.17 12:16[7]

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

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

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


megavoid ©   (10.10.17 20:35[8]

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


DayGaykin ©   (10.10.17 20:56[9]

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

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


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


Elementrary ©   (10.10.17 21:53[10]


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

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

ID  |  JsonDoc

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

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


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

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

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


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

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


картман ©   (10.10.17 22:40[11]


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

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


rule ©   (12.10.17 11:18[12]

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


картман ©   (12.10.17 12:23[13]

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


tesseract ©   (13.10.17 14:43[14]

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

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

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


tesseract ©   (14.10.17 16:59[15]

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

https://github.com/bloomberg/comdb2

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


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо