Конференция "Прочее" » В чем фишка NoSQL / MongoDB?
 
  • Elementrary © (09.10.17 16:40) [0]
    Пытаюсь я понять смысл концепции 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 для хранимых процедур.
 
Конференция "Прочее" » В чем фишка NoSQL / MongoDB?
Есть новые Нет новых   [87919   +42][b:0.001][p:0.002]