MongoDB 1.6.0

этот толстый вброс собрал уже 100 комментариев.

> А что в качестве альтернативы?

альтернативы для чего?

сложность кластеризировать веб-сервер?

или реплицировать базы?

лично для себя не вижу чем MongoDB поможет именно в этом вопросе.

Расскажи про быструю кластеризацию постгреса на 10 машин, ага.
И про проседания производительности при этом не забудь.

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

чушь полнейшая.

Во первых, «целостность и достоверность» информации в реляционной БД вовсе не означает ни целостности ни достоверности.

все гораздо проще. В реляционной модели каждый помещаемый в базу объект распыляется на атомы, на отдельные записи в десятках таблиц. Собственно, поэтому бОльшую часть времени любая реляционная БД находится в разваленном состоянии, просто потому, при помещении объекта с первым инсертом мы ее рушим и только последним инсертом или апдейтом восстанавливаем. Все это время абсолютно корректная выборка будет возвращать результат.

При выборке собирается обратно с помощью элементарного (но затратного, шо пездец) декартового произведения матрицы на столбец. Очевидно, что все время помещения объекта в бвзу, любая абсолютно корректная выборка будет возвращать непредсказуемый результат.

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

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

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

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

И да, даже самый распоследний форумок и бложек, как любой нелимитированный по нагрузке ресурс, могут поставит на колени реляционку. См, например, сюда http://rusliberal.com/.

хренассе, прорвало тебя...

Никто в реляционке не гарантирует клиенту никакой целостности или достоверности его, клиента, информации. Это все лошь писдеш и провокация.

Ну почему же, все эти констрайнты вполне обеспечивают «межатомные связи». При использовании транзакций, разумеется. Так что, целостность вполне обеспечивается. Точно так же скотч обеспечивает целостность порваной купюры. И точно так же глупо говорить, что не порванная купюра не целостна, поскольку она не склеена скотчем.

С достоверностью тоже засада. (Тебя уже просветил про вред избыточности какой-то пионер в прошлом треде про nosql). В принципе верно, можно такой результат получить при умножении, что капец. Вот и приходиться дробить всё «на атомы». Но, как известно, сдуру можно и прибор дверью прищемить.

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

Емнип, в мускуле были многострочные операции, оч удобно записать в таблицу набор ключей-значений за один insert )

>Ну почему же, все эти констрайнты вполне обеспечивают «межатомные связи». При использовании транзакций, разумеется.

об том и речь, что констрейны и транзакции решают проблемы порождаемые самим сиквелом и не более того.

Точно так же скотч обеспечивает целостность порваной купюры.

Дык вот именно, что сначала сделают копилку из шредера, к ней прилепят автосклейку скотчем, а потом требуют, чтобы все копилки ношредер тоже были со скотчем, а то «целостность и достоверность» пострадают, да еще веть и пропадание питания и прочие фобии клиента сюда же притянут...

И точно так же глупо говорить, что не порванная купюра не целостна, поскольку она не склеена скотчем.

С достоверностью тоже засада. (Тебя уже просветил про вред избыточности какой-то пионер в прошлом треде про nosql).

Купюра может быть порвана в том числе из за неучтенных особенностей копилки. Ответ сиквел-епнутых неофитов - заклейте клиенту глаза, то есть уберите избыточность и вы никогда не узнаете, что купюра таки порвалась.

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

и опять таки, вдоволь натешившись прибором с дверью, они и в устройстве без механических деталей требуют запас пластыря. иначе ведь «не серьезно».

Емнип, в мускуле были многострочные операции, оч удобно записать в таблицу набор ключей-значений за один insert )

во первых это не стандарт, а во вторых, писать и изменять обычно надо в разные таблицы.

какой-то сферический конь в вакууме

то, что реляционки говно, мы от вас неоднократно слышали. вы лучше расскажите чем noSQL лучше в плане целостности, достоверности, избыточности и т.п.
просим.

> Расскажи про быструю кластеризацию постгреса на 10 машин, ага. И про проседания производительности при этом не забудь.

кто вам виноват, что вы юзаете в кластере то, что проседает по производительности?

>то, что реляционки говно,

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

nosql лучше в плане целостности и достоверности тем, что позволяет не распылять сохраняемый объект по жестко заданым таблицам и соответственно, не восстанавливать его потом. Каждый документ держит схему в себе. Весь объект, это единица и она сохраняется, как единица.

Что-то вроде LORа? Что значит простейшие случаи?

именно так, например: искать слова которые отстоят от ключ слова на n-позиций. много есть вещей которых в pg fts нет (ну или не было на тот момент когда я этим интересовался, за 8.4 + fts говроить не стану)

>> Расскажи про быструю кластеризацию постгреса на 10 машин, ага. И про проседания производительности при этом не забудь.

кто вам виноват, что вы юзаете в кластере то, что проседает по производительности?

Т.е сказать по делу нечего?

> nosql лучше в плане целостности и достоверности тем, что позволяет не распылять сохраняемый объект по жестко заданым таблицам

В реальности, нужно хранить несколько объектов и связи между ними. И вот тут... упс.

самый распоследний форумок и бложек, как любой нелимитированный по нагрузке ресурс, могут поставит на колени реляционку

Да ну тебя, форум arstechnika.com с миллионом мемберов в году так 2003-м стоял на двух серверах, одном с PHP, втором с MySQL-базой

>В реальности, нужно хранить несколько объектов и связи между ними. И вот тут... упс.

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

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

>форум arstechnika.com с миллионом мемберов в году так 2003-м

вот-вот. А добавь ему аякс, заставь собирать статистику через жабаскрипт и все...

>> В реальности, нужно хранить несколько объектов и связи между ними. И вот тут... упс.

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

Ага, еще немного - и ты договоришься до того, что весь форум нужно хранить в одном объекте %)

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

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

>Ага, еще немного - и ты договоришься до того, что весь форум нужно хранить в одном объекте %)

зависит от выборок. в ряде случаев это отличный выход.

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

это не серебряная пуля. Но решение.

> сиквел Это SEQUEL? Он где-то ещё используется?

Если связи горизонтальные, ну так и храни ссылки.

Ссылочная целостность обеспечивается?

Не очень-то он и производительный
http://habrahabr.ru/blogs/mysql/87620/#habracut

>> Ага, еще немного - и ты договоришься до того, что весь форум нужно хранить в одном объекте %)

зависит от выборок. в ряде случаев это отличный выход.

Есть троллинг, толстый троллинг, и троллинг AVL2.

Ну вот и славно, мы выяснили типичный use case для NoSQL: бложик или форум с чудовищной посещаемостью. То есть случаев эдак 15–20 в мире.

У вас, сударь, вообще незавидная судьба, поэтому предубежденность в отношении NoSql мешает мыслить более толерантно. Один неудачный опыт не стоит распространять стразу на все случаи.

Я же, буквально на днях, перевел свою систему учета абонентов корпоративных тарифов на couchdb. При этом совершенно не почувствовав каких-то ограничений в средствах выборки данных. Более того система стала проще. Не стало транзакций, исчезли многочисленные костыли для хранения безсхемных данных и выпилились ненужные сущности, под которые были заведены таблицы. В общем, сугубо положительный опыт.

> Я же, буквально на днях, перевел свою систему учета абонентов корпоративных тарифов на couchdb. При этом совершенно не почувствовав каких-то ограничений в средствах выборки данных. Более того система стала проще. Не стало транзакций

«Вызывает интерес
Акуевший МТС
Как они там п*дят деньги
С наглой рожей али без?» (с)

...но на самом-то деле у них просто нет транзакций %)

>Купюра может быть порвана в том числе из за неучтенных особенностей копилки. Ответ сиквел-епнутых неофитов - заклейте клиенту глаза, то есть уберите избыточность и вы никогда не узнаете, что купюра таки порвалась.

Ну дык, ясень-пень, порвется, ты ж её в шредер сувать собрался. Проблема в выборе схемы шредера: если ширину реза настроить слишком большой, при склейке можно получить купюру с разными номерами, если слишком маленькой — ВНЕЗАПНО получим купюры достоинством 0 или 100500. А дебажить автосклейку — тот еще изврат.

во первых это не стандарт,

о да... Вот чорт, nosql, кажется, тоже не стандарт! :)

а во вторых, писать и изменять обычно надо в разные таблицы.

Зато если не обычно, то вполне позитивно.

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

Посмотрел я на дела рук своих, подивился собственной крутости былинной, да и грохнул всё к такой-то фене. Оставил одну-единственную таблицу insert-only, и возрадовался неиллюзорной радостию.

Заказчик, офигел, конечно, от такого вопиющего отступлени от канонов, но на вопрос «чем различаются А.С. Пушкин и Пушкин А.С.?» так и не ответил. Потом долго еще в астралах пребывал от внезапно открывшихся перспектив, всё борматал что-то невпопад, то девушек вспомит, то еще что: «Пушкин-ах! Анна Петровна Керн! Оля Кидалова ах-ах! Науки! Вызвать Надю! Всех!..» (конечно, я мог чего-то не дослышать)

Оно и понятно, проще один раз секретаршу вздрючить, чтоб грамотно писала, чем регулярно «править базу», незабесплатно причем ни разу.

// Ладно, инвениаризацию садового инвентаря будем считать успешно проведенной.

>У вас, сударь, вообще незавидная судьба, поэтому предубежденность в отношении NoSql мешает мыслить более толерантно. Один неудачный опыт не стоит распространять стразу на все случаи.

Я, кстати, ещё легко отделался. Мне страшно подумать о тех, кто попал бы в такую ситуацию с голой жоп^Wжавой.

Проблема не в том, что мы не видим, что некоторые задачи плохо вписываются в реляционную модель. Проблема в том, что весь существующий NoSQL (дурацкое, кстати, слово) находится на уровне детского сада: ни стандартов, ни схем, ни, простиосспади, математической модели.

>на couchdb

baverman, а может быть ты тему раскрыть сможешь?

Интересует «навскидочное» сравнение mongohdb и couchdb, можно субъективно. И, раз уж ты имеешь опыт, хотелось бы узнать о недостатках couchdb и прочих «подводных камнях».

И еще пара вопросов по couchdb:

как она на венде живет (если ты в курсе)?

какой мануал посоветуешь?

> ни, простиосспади, математической модели.

куда дели? опять матмодель пропили?

>ни стандартов

Да, с этим туго

ни схем

В схемалесс БД? Вобщем то не более разумно чем требовать статическую типизацию от питона.

математической модели

Ну, можно и без нее прекрасно жить - решение то более инженерное чем теоретическое (по сравнению с реляционными).

>>математической модели

Ну, можно и без нее прекрасно жить - решение то более инженерное чем теоретическое (по сравнению с реляционными).

Да не сцы, это тутошние красноглазики её утянули. Поиграюца — вернут, дети же, что ты хочешь?

>Ну вот и славно, мы выяснили типичный use case для NoSQL: бложик или форум с чудовищной посещаемостью. То есть случаев эдак 15–20 в мире.

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

>куда дели? опять матмодель пропили?

чоловик одержим них синдромом. Хочет неарабских цифр, какого-то другого декартова произведения и т.д.

А на самом деле носиквел, это подмножество сиквела.

> При выборке собирается обратно с помощью элементарного (но затратного, шо пездец) декартового произведения матрицы на столбец. Очевидно, что все время помещения объекта в бвзу, любая абсолютно корректная выборка будет возвращать непредсказуемый результат.

Что куримс..?

Читать до полного просветления про такое фундаментальное понятие как «transaction isolation» и изучать разницу между различными уровнями оного. Дабы не нести бред на форумах и не искушать неокрепшие умы сказками про «ненадежный SQL».

дебилизм на лоре.

вроде пишешь им по русски, ан нет.

> baverman, а может быть ты тему раскрыть сможешь?

Почему я выбрал couchdb:

В первую очередь MVCC. В монгодб не понравилось хипарское отношение к данным — лишь бы быстрее записать, а то что в записываемом документе может быть старый кусок — пофиг. И версионность в большинстве случаев способна заменить транзакции.

Мультимастер репликация.

Необходимость задавать map/reduce алгоритм для каждой выборки. Динамические индексы в монго вещь, конечно, интересная, но хрен знает, что она решит навертеть, в этом вопросе предпочитаю явность. Это, кстати, помогает планировать какие данные вообще могут понадобится приложению и облегчает проектирование.

Качество. Криворуков на эрланге гораздо меньше чем криворуков на плюсах.

Параноидальный подход к надежности.

Минусы:

Требования к размеру винтов. База пухнет очень быстро. Необходимо периодически делать compact.

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

MVCC, необходимо помнить, что сохранение документа может привести к конфликту.

Вообще если просто интересно попробовать NoSQL, то лучше монго. Основные принципы те же, но легкость в освоении решает. Ребята постарались. Couchdb несколько специфичен и довольно строг.

как она на венде живет

Есть стабильные билды под различные виндоусы. Отличий в работе не заметил.

какой мануал посоветуешь?

CouchDB: The Definitive Guide — обязательно к прочтению.

Beginning CouchDB — достаточно подробное описание для полных нубов.

И http://wiki.apache.org/couchdb/ особенно API References.

>Почему я выбрал couchdb:

Спасибо тебе преогромное! Даже не надеялся на такой развернутый ответ. Спасибо!

Вообще если просто интересно попробовать NoSQL, то лучше монго. Основные принципы те же, но легкость в освоении решает. Ребята постарались. Couchdb несколько специфичен и довольно строг.

Просто пробовать не интересно, лучше уж с прицелом на перспективу ) И еще мне в couchdb нравится REST.

База пухнет очень быстро. Необходимо периодически делать compact.

Я так понимаю, compact старые версии документов удаляет, а до этого они в базе лежат себе спокойно, и, подозреваю, могут быть доступны? Если так, с этого можно пользу получить.

Криворуков на эрланге гораздо меньше чем криворуков на плюсах

Да, эрланг несомненный аргумент «за». Кстати, можно ли (и есть ли смысл) на нем делать всякие Views, Validation и прочие Show? Почему вопрос возник — в CouchDB: The Definitive Guide там один сплошной яваскрипт.

Спасибо тебе еще раз.

>Что куримс..?

/me зопесал: «rtvd читать не умеет, а еще магистр!»

Сиквел это что?
Вылезай из танка! Давно используют SQL.

>сложность кластеризировать веб-сервер?

или реплицировать базы?

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

Кстати, можно ли (и есть ли смысл) на нем делать всякие Views, Validation и прочие Show?

С 0.11 есть возможность определять native view, которые выполняются в пространстве сервера. Этим еще не страдал. Производительности SpiderMonkey пока хватает.

> Я же, буквально на днях, перевел свою систему учета абонентов корпоративных тарифов на couchdb. При этом совершенно не почувствовав каких-то ограничений в средствах выборки данных.

Эквивалентный опыт с CouchDB.

Более того система стала проще.

Именно так.

Не стало транзакций,

Их можно через bulk использовать - в этом случае пишется либо всё, либо ничего.

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

База упростилась, код намного меньше и проще стал. Как следствие, поддержка кода проще.

В общем, сугубо положительный опыт.

Да.

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

mysql. правда с гемор по настройке , уникальность ключей руками и ненадежно оно как-то.

>mysql

У него же нет симметричной репликации.

Ну я же говорил, не без гемора.

http://capttofu.livejournal.com/1752.html

И как оно переживает временный отвал башки^W одного из мастеров и, через какое-то время, возвращение его в строй? А что с производительностью, если вставок много, а скорость сети не очень высокая?

>И как оно переживает временный отвал башки^W одного из мастеров и, через какое-то время, возвращение его в строй?

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

А что с производительностью, если вставок много, а скорость сети не очень высокая?

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

> дебилизм на лоре.

вроде пишешь им по русски, ан нет.

Да, похоже есть такое дело.

Пруф вот этого в студию, особо одаренный ты наш: «Очевидно, что все время помещения объекта в бвзу, любая абсолютно корректная выборка будет возвращать непредсказуемый результат.»

> /me зопесал: «rtvd читать не умеет, а еще магистр!»

Анонимус писать умеет. Умница, дочка. Может и мозг включать научишься, как подрастешь.

Ну и когда мне надобно будет с Постгреса и Джавы переходить на это супер-пупер популярное и мегавостребованное поделие?

> Пруф вот этого в студию, особо одаренный ты наш: «Очевидно, что все время помещения объекта в бвзу, любая абсолютно корректная выборка будет возвращать непредсказуемый результат.»

Своими мозгами пользоваться уже не модно?

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

и что мы увидим в этой выборке при помещении проводки в базу?

время - расход - приход

t0 - x - x

t1 - x+1 - x

t2 - x+1 - x+1

корректное содержимое базы наблюдается только в начале и в конце.