Релиз MongoDB 2.2.0

Работаю с обеими типами баз, в настоящий момент это MongoDB и Oracle. Не могу сказать, что из них лучше/хуже, по простой причине - задачи бывают разные. Вкратце сравнение:

1. Сеть. Oracle - шифрование и сжатие. MongoDB - ничего подобного нет. Не сказать, что это уж очень важный момент, но сжатие - рулит. Можно запихивать сжатые и шифрованные данные в монго - однако клиент от этого проще не станет.

2. Потребление памяти. Чем больше тем лучше, однако у монго зависимость от памяти пропорциональна объему хранимых данных. При этом выхода всего два - либо исправлять базу путем использования ключей в 1-2 символа и урезания объема данных, либо использовать шардинг.

3. ACID. Скажу кратко, в монго придется менять архитектуру клиента и/или свой взгляд на этот вопрос. Иногда это может быть сложно, неудобно или вообще невозможно и недопустимо. В простейших случаях допустить возможность появления устаревших данных, т.к. они не являются критичным случаем и не являются сбоем системы. Решение с введение коллекции с транзакциями лишь усложняет всю систему.

4. Гибкость построения сложных документов. Несмотря на то, что монго и другие NoSQL решения выдвигают чуть ли не главной фишкой создавать любые сложные документы - применение их в реальности сильно отличается. В частности, большие и сложные документы сказываются на а) удобстве их изменения, если необходимо делать какие-то проверки, то легче не станет: чем больше аргументов на проверки - тем больше придется делать индексов (некоторые индексы лучше вообще не строить без надобности), либо выкачивать целиком документы, что неразумно в ряде случаев; б) нагрузка на систему, перезапись документа ради одного поля в 5кб отличается от перезаписи другого документа менее чем в 100 байт. При этом, во втором случае всплывает вопрос об ACID, когда документ создается через ссылки из разных коллекций, баз и т.д. Увы, тем, кто сталкивался только с небольшими документами и не задавался вопросом об разбиении на поддокументы - видел лишь одну положительную сторону монго :) Выйдя на уровень сложных документов со ссылками, кроме вопроса по ACID, возникнет тот же вопрос как и в SQL - как связывать документики и вот тогда, монго снова покажет свою гибкость и удобство засчет возможности построения ссылок через массивы. Во-многих случаях этого будет достаточно, т.к. массивы в каждом документе будут весьма малы (менее 100) и по ним можно легко строить индексы, клиентская часть от этого не станет сложнее. Что в отличие от СУБД порой неудобно реализовать.

5. Третье-сторонние возможности. В то время, как pgsql, а oracle и тем ранее умеют выдавать данные в xml формате из коробки, этот вопрос полностью ложится на разработчика клиентской части mongo. Я не говорю, что это является обязательно фишкой любой БД, но в ряде задач это требуется. И тут монго, увы, проигрывает. Кроме XML, есть другие плюшки в виде инициации HTTP/TCP соединений непосредственно со стороны БД.

6. Масштабируемость. Коснусь только монго. Масштабируемость по чтению, легко делается через реплики с коеффициентом стоимости 1:1 (для увеличения на 100% требуется 1 сервер). Выйдя на уровень шардинга, т.е. когда ОЗУ станет просто не хватать или объемы данных превысят все возможные лимиты, коэффициент стоимости станет 1:2 (100% производительности ценой 2 серверов - 1 это новый сегмент и еще 1 - реплика для него). При этом, на высоконагруженных серверах бэкапирование данных с «горячих» серверов может стать просто критичным и невозможным, т.е. придется создавать реплику, с которой легко и быстро снимается бэкапы.

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

7. Итог. Прежде чем делать выбор SQL/NoSQL стоит взвесить все плюсы и минусы. NoSQL не избавит вас от проблем SQL, а даже наоборот добавит своих. Вопрос об ACID возможно остановит от выбора неправильного пути, а миф о том, что документы в монго принято хранить в виде одной записи с тысячью полей пусть так и останется мифом. А масштабируемость несмотря на свою прозрачность и простоту имеет свои недостатки. Сайтики на сто человек можно писать хоть с SQL, хоть без, выбор остается за тем, что ближе по складу ума - логичные и строгие таблицы, либо свобода действий, ограниченная фантазией :)

Вы тоже пришли в мир персистентных данных через SQL, судя по смещению акцента с предполагаемого «в каких случаях полезнее SQL, а в каких - NoSQL» к озвучиваемому «если вы уже построил архитектуру своего приложения в реаляционной парадигме, то в каких случаях нужно всё сломать, чтобы перейти на монгу».

Да, пришел с SQL. А вам подавай лишь монго? Еще раз, тут кто-то забивает на минусы NoSQL, а кто-то считает такие минусы не допустимыми. Это две разные парадигмы и я лично не вижу ни одной из них идеальной для решения абсолютно любой задачи. Иногда легче использовать SQL ради простоты приложения, иногда легче использовать NoSQL опять же ради простоты приложения. Либо вы решаете узкий список задач, либо фанатик :)

а чем тебя там mmap бесит, ннэ?

Немного поясню.

NoSQL не избавит вас от проблем SQL

Если такие проблемы возникли, то они возникли из неправильного проектирования. Замена РСУБД на монгу сама по себе не решит эту проблему. Монго - это не заплатка, а отдельный инструмент со своими подходами к разработке.

свобода действий, ограниченная фантазией

Обычно это подразумевает неумение пользоваться инструментом и неимением методологии. Такую фантазию и на SQL можно натворить, не понимая реаляционных подходов.

Я прошу прощения, если мои замечания выглядели как аргументация «монго всегда круче». Мои проекты гораздо чаще используют постгрес, ежели монгу. Я лишь сетую по поводу не самых корректных формулировок критериев выбора, которые слишком «SQL-центричны» :).

Монго - это не заплатка, а отдельный инструмент со своими подходами к разработке.

Верно.

Обычно это подразумевает неумение пользоваться инструментом и неимением методологии. Такую фантазию и на SQL можно натворить, не понимая реаляционных подходов.

Верно. Видел людей втянутых в SQL, но не знающих основ построения сложных таблиц. В итоге, join join погоняет, что выливается в дикие тормоза, а размер данных просто фантастичен. Хотя имеются несколько хороших учебников, которые именно начинаются с того, как строить таблицы, с указанием того, когда нужно выделять таблицу, а когда нет. Увы, но я с столкнулся с худшим. С переносом тех же данных в монго, пришлось избавляться от неверной архитектуры, иначе все проблемы SQL становятся также частью и NoSQL и имеют более серьезные последствия (сжирание памяти и места на диске, сложность слежения за изменениями данных и т.п).

которые слишком «SQL-центричны»

Расписал как получилось. NoSQL относительно молод (имею ввиду широкое применение в тех задачах, которые раньше не решались) и пока плюсы не перекрывают минусы в ряде случаев.

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

Слышь, проектировщик, ты обосрался на трех табличках, а еще трепыхаешься.

процесс совсем не быстрый - ранее чем после НГ этого и не случится, так кусочками попробуем подключать и посмотреть

Как интересно. И почему же?

Лучше подходит для задачи, например.

В вебе документо-ориентированным СУБД не нужны костыли в виде ORM и т.п.

В вебе документо-ориентированным СУБД не нужны костыли в виде ORM и т.п.

Зато им нужны кастомные map/reduce в случае нетривиальных случаев, на которые, почему-то, натыкаешься чаще, чем о том вещают фанбои.

Задача: реализовать аккаунтинг на монго.

1. Либо у тебя SQL головного мозга в терминальной стадии.

2. Либо ты не владеешь предметной областью. Система двойной записи на документо-ориентированной СУБД решается на раз. А если в твою задачу добавить учет по аналике, как в настоящем бухучете - РСУБД просто сольет.

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

А если в твою задачу добавить учет по аналике

То незабываемый трах с map/reduce и партиционированием данных по отчетным периодам тебе обеспечен, иначе производительность даже на 100k записях просто убога.

Повторюсь, я тоже был фонатом. Слава богу попустило.

Я прекрасно понимаю, о чем ты. Тут дело вот в чем.

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

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

Поэтому, у тебя либо проблема №1, либо №2. Либо обе сразу.

и с вероятностью 99% тебе не нужен SQL.

fixed

Доо. 30 лет у всего мира было помешательство, но пришли NoSQL-фанбои и принесли свет истины. Только почему-то уже разрабатывается UnQL, который является _надмножеством_ SQL.

Немного оффтопик: а что скажешь насчёт CouchDB/Couchbase?

5.

В наше время всё ещё нужен вывод в XML. Ужас.
Касаемо HTTP/TCP соединений — couchdb должен уметь это.

Ну если ты назовёшь XML разумным языком для разметки данных…

XML - разумный язык для разметки данных. Ему только с синтаксисом не очень повезло, но синтаксис вообще дело десятое.

Ну если ты назовёшь XML разумным языком для разметки данных…

Я назову. А ты скажешь, причем XML к SQL и ACID?

Ну дык для неосиляторов с sql головного мозга и делают :)

30 лет не показатель. Вона, интел скока всех своими говнопроцами кормит. Не потому, что хорошие, а потому, что продавать умеет.

почему-то уже разрабатывается UnQL, который является _надмножеством_ SQL.

Ну дык для неосиляторов с sql головного мозга и делают :)

А вот историю нужно было учить.

интел скока всех своими говнопроцами кормит

Ну понятно... «NoSQL рулит», «Intel говно» - типичная альтернативщина от IT.

Ну куда уж нам, крестьянам :)

Ну куда уж нам, крестьянам :)

В NoSQL, писать запросы к СУБД на смеси JavaScript и JSON. Никакой реляционной алгебры и легко представить себя в Твиттере.

Кому нужно это дерьмо без транзакций?

CouchDB

Не работал с ней. Был у меня Redis. Все они заточены под ряд своих задач, но уверен в своей части CouchDB должен справлятся как положено. MongoDB на этом фоне выглядит более универсальным решением, что и плюс и минус.

на смеси JavaScript и JSON

Евгеньваганыч, немедленно верните акк Василию!

Никакой реляционной алгебры

раз уж даже Дейта itt вспомнили, оставлю это здесь

раз уж даже Дейта itt вспомнили, оставлю это здесь

В рассуждения уровня:

Так вот, проблема реляционной модели в том, что это «черная овца» в компьютерно-математических науках. Она построена на классических докомпьютерных «бумажных» основаниях математики. А именно на теории множеств. Она неконструктивна. Имеется в виду математический конструктивизм

я не решусь лезть %) Впрочем, судя по:

у Карабаса-Барабаса продолжается приступ доброты, Карабас-Барабас покажет вам волшебную дверцу

ответ давать здесь не буду, потому что, во-первых, мне наплевать на проблемы тех, кто чего-то не понял

там просто понты.

И в любом случае, непонятно, как это относится к SQL^WACID vs NoSQL.

А ты скажешь, причем XML к SQL и ACID?

А ты не понимаешь, «причем XML к SQL и ACID»?

Правда не понимаешь?

Поздравляю! Вот и никто не понимает. То есть, все понимают, что не при чем. Совсем.

Продолжай в том же духе, и ты, может быть, поборешь свой SQLГМ.

ты, может быть, поборешь свой SQLГМ.

Не поборю. И жену бить не перестану. И коньяк пить по утрам тоже не перестану.

там просто понты.

не без этого

И в любом случае, непонятно, как это относится к SQL^WACID vs NoSQL.

Ну, это понятно, что тебе не понятно.

Что интересно, что многие отписавшиеся в этом треде не понимают что такое реляционная база данных. И что ни Oracle, ни MySQL не является реляционной базой данных. А SQL не является реляционным языком, не говоря уже о реляционной полноте.

Внезапно, но эта «документо-ориентированность» не сильно выходит за рамки реляционной модели. А SQL просто многого из реляционной модели не поддерживает, по этому вообще бессмысленно аппелировать к нему как к «идеальному языку», SQL, так же как и существенная часть NoSQL - просто реализация подмножества реляционном модели, какая-то более мощная, какая-то менее.

Да, именно «синдром утёнка» можно объяснить поведение тех, кто пришёл к хранению данных через SQL и теперь не способен принять возможность других решений. К сожалению, это часто касается и остальных технологий - от операционных систем до языков программирования.

Конечно. Им же можно объяснить и поведение тех, что пришел к хранению данных через всякие там Mongo. :)

А именно на теории множеств. Она неконструктивна.

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

Так и не понимаю, чем так плох унифицированный язык и SQL головного мозга, как следствие. Расовые предрассудки? Пазёрский нонконформизм?

SQL головного мозга, навязываемого человечеству оракулом

Разве что только в твоих фантазиях. Внезапно, оракл развивает BerkleyDB, которая вполне подходит под термин NoSQL.

И это неговоря уже о том, что сфера применения NoSQL баз в текущем состоянии крайне мала, к сожалению.

Вот и еще один отвечатель-нечитатель попалился. Чудненько!

прежде чем выполнится очередная команда ALTER TABLE на его авиабазе...

И какое отношение имеет язык запросов к скорости alter table в конкретной базе? И, кстати, нормальные базу умеют делать это быстро. И даже для MySQL есть колоночный движок, который позволит делать это быстро.

Вот и еще один отвечатель-нечитатель попалился. Чудненько!

А зачем ты тогда оставил ссылку на чувака который порет чушь?

Не потому, что хорошие, а потому, что продавать умеет.

Вот это рассуждение того же рода. Почему-то модно ругать intel кляня «архитектуру» ничего в ней толком не понимая. Чем конкретно плох intel? Только не надо про «ненужный транслятор из x86». Это выдаст в вас некомпетентность.

А SQL не является реляционным языком, не говоря уже о реляционной полноте.

The Third Manifesto и язык БД D стоило бы упомянуть здесь.

---

А ты скажешь, причем XML к SQL и ACID?

Ни при чём, просто это отличный детектор энтерпрайза ГМ.

The Third Manifesto и язык БД D стоило бы упомянуть здесь.

Не D, а Tutorial D ;)

А ты скажешь, причем XML к SQL и ACID?

А это вообще не мне ответ а tailgunner-у

То что если туда загрузить что-нибудь больше твоего аналога твиттера с десятком пользователей, то оно начинает безбожно тупить?

Tutorial D

Industrial D ещё же есть.

А это вообще не мне ответ а tailgunner-у

Ему, просто не хотел писать два поста подряд.

Industrial D ещё же есть.

Это верно, но D - не является языком. Это просто набор требований к языку.

А именно на теории множеств. Она неконструктивна.

Чувак, ты что такое конструктивизм то знаешь?

Чувак, это цитата. Твой вопрос не по адресу.

а чем тебя там mmap бесит, ннэ?

1. Он не управляем. Я не могу задать, сколько базе отъесть памяти. Она будет занимать все, что даст операционка. Это, зачастую, недопустимо.

2. Механизм виртуальной памяти несколько отличается от механизма кеширования в BD. В BD нет необходимости ценить микросекунды и можно реализовать нормальный алгоритм вытеснения, в то время как в VM используются самые примитивные алгоритмы из-за минимизации времени доступа.

Чувак, это цитата. Твой вопрос не по адресу.

Да, это я промахнуля и вопрос был анонимосу. Но он вроде понял.