MongoDB 1.6.0

ты дешевый китайский самозванец!

Профессор Луговский изначально писал биореактор на хаскеле.

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

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

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

И опять все по кругу.

машины ездят по земле, машины ломаются на колдобинах, машинам придумали дороги, что там с самолетами? когда им автобаны построят?

Это не ответ. nosql без внешних локов не умеет распределенные транзации типа обновления нескольких объектов. Многие для этого используют zookeeper, но он тормозной.

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

Когда в твоем проектике будет хотя бы больше 1000 запросов в секунду, а база (с опцииональным кэшом) перестанет помещаться в память.

Здесь тесты приводились с хабра и собсветнные, где заливались аж десятки тысяч, а то и миллионы записей (не больше килобайта каждая наверное). Вот там точно не нужно горизонтальное масштабирование и прочие фичи nosql.

> использующим данный функционал

НЕНАВИСТЬ!!!!!!!111

> с опцииональным кэшом

Ненависть.

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

твой мосг, ты и включай. Да. А читать все-таки научись, девочки смеяться быдут.

> Написана на языке C++.

Закапывайте

Не надо ничего закапывать!

http://www.mongodb.org/display/DOCS/Production+Deployments

Эти клиенты таки вынуждены будут обратиться в аутсорсинговые компании для переписывания типа софта на EJB3 и/или Spring.

Это бизнес

PROFIT!

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

Если бы было не так, транзакции были бы не нужны.

Школьнеги думают, что брамины пишут на фунциАнальных недоязычках, а кшатрии - на Це-пи-пи?

И только презренные барыги вайшьи - на Джаве. И уж совсем шудры на пых-пых и хариджане-неприкасаемые - на бейсике?

Нет, мой юный друг. Как К.О. я сообщаю, что программеры даже в Индусе - все брамины. Это варта (каста). А выбор языка - это ДЖАТИ, а не варна.

И наиболее оплачиваемая джати - это Джаваджати.

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

Если бы было не так, транзакции были бы не нужны.

И мы возвращаемся к уровням изоляции.

А «транзакции» NoSQL работают только с одним объектом.

>А «транзакции» NoSQL работают только с одним объектом.

Это даже не транзакция, так - запись... А честные распределенные транзакции (кстати, распределенных транзакций нет и в sql - разве там можно обновлять разные шарды в одном update/insert?) живут с внешними локами. Но я не знаю ни одной nosql системы, где эти локи быби бы встроены. Ни в касандре, ни в монго их точно нет.

> А честные распределенные транзакции (кстати, распределенных транзакций нет и в sql

Ну, в SQL есть хотя бы честные внутрибазовые транзакции.

Там они не имеют смысла, т.к. в любой момент данные могут «переехать» на новый узел. SQL проще. т.к. не обновляет базу на другой машине. А на одной машине это совсем просто сделать. Вон, в tokyo cabinet глобальный лок стоит, и никто не парится.

>Ну, в SQL есть хотя бы честные внутрибазовые транзакции.

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

А чтобы дать программеру возможность примитивно посемафорить.

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

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

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

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

t0 - x - x

t1 - x+1 - x

t2 - x+1 - x+1

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

Не хами, сынок.

Это поведение будет только в случае если транзакции не изолированы. Ставишь уровень изоляции SERIALIZABLE и все будет работать. Конечно, будет тормозить. Хочешь чтобы было быстро - меняешь стуктуру базы. Это если такое в твоем случае возможно. Так что не надо трындеть что дескать SQL не дает гарантий предсказуемости результатов. Просто цена этой предсказуемости велика.

>Это не ответ. nosql без внешних локов не умеет распределенные транзации типа обновления нескольких объектов. Многие для этого используют zookeeper, но он тормозной.

Ответ в том, что носекель обеспечивает беспроблемную вставку и обновление документа. А операция над документом в большинстве случвев эквивалентна транзакции в сиквеле.

В прочих случаях нет никакой революции. Есть всего два метода. Квитирование результата (метки или валидация по избыточности) и трехзначная логика. Оба варианта в нормальной реализации подразумевают локлесс и нормальное масштабирование.

молодец. именно это и было написано изначально.

> молодец. именно это и было написано изначально.

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

>> Ну, в SQL есть хотя бы честные внутрибазовые транзакции.

которые ставят большой крест на линейной масштабируемости,

И ты можешь это доказать?

вызывают деадлоки

Я вот не понимаю - ты тролль или дурак? Дэдлоки, мля. Тебе же сказали - когда нужно согласованно обновлять несколько объектов в NoSQL, используются внешние менеджеры блокировок. Вот тебе и дэдлоки. А если в SQL-базу нужно тупо добавлять записи, там нет дедлоков.

>И ты можешь это доказать?

Эту очевидность надо доказывать? кто-то научился бесплатно изолировать данные да еще на нескольких нодах?

Я вот не понимаю - ты тролль или дурак? Дэдлоки, мля.

не пугайся. дедлоков не видел?

Тебе же сказали - когда нужно согласованно обновлять несколько объектов в NoSQL, используются внешние менеджеры блокировок. Вот тебе и дэдлоки.

как вариант. в духе сиквела.

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

а вот это к чему? или носиквел в этой простейшей ситуации будет вести себя по другому?

>> Я вот не понимаю - ты тролль или дурак? Дэдлоки, мля.

не пугайся. дедлоков не видел?

Утипути. Я видел дедлоки, да. Когда-то давно. А с тех пор научился их избегать - это нетрудно. А те, кто не научился, разглагольствуют о NoSQL, который якобы решит проблему.

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

а вот это к чему?

Это к дедлокам.

>Утипути. Я видел дедлоки, да. Когда-то давно. А с тех пор научился их избегать - это нетрудно

дедлоки лишают транзакции главного преимущества - надежности. Ты можешь строить из себя крутого програмёра, но когда нибудь,когда ты будешь сладко спать, он придет и съест твой мозг. Да, ты ощетинишься транзакциями, но дедлок обернет твою защиту против тебя, вся система заклинит, а ты будешь рвать последние волосенки и думать о суициде.

Это к дедлокам.

А вот и анальная фиксация. Даже в случае банальной последовательной записи в одну таблицу ты рьяно отрицаешь дедлоки, хотя никто их там и не ищет? это твой кошмар? Ты все знал!

Простите, что вмешиваюсь, но...

Да, ты ощетинишься транзакциями, но дедлок обернет твою защиту против тебя, вся система заклинит

AVL2 ты ведь выше писал, что в noSQL проблема записи нескольких документов (связанных) решается в духе SQL. Значит и здесь будут рвать последние волосенки бедные программеры. В чем профит?

> когда нибудь,когда ты будешь сладко спать, он придет и съест твой мозг

анальная фиксация.

это твой кошмар? Ты все знал!

То есть ты всё же не тролль и не дурак, а просто болен...

>> молодец. именно это и было написано изначально.

Нет, дорогуша. Ты нагло трындел

Плохо, очень плохо! Техникой чтения ты огорчаешь свою первую учительницу.

Всем, кто хвалит MongoDB и подобные им «базы данных», НАСТОЯТЕЛЬНО рекомендую прочитать сей линк: http://zabivator.livejournal.com/412053.html

> кстати, распределенных транзакций нет и в sql

В джаве есть xa датасорсы которые реализуют распределенные транзакции через 2 phase commit протокол.

>AVL2 ты ведь выше писал, что в noSQL проблема записи нескольких документов (связанных) решается в духе SQL. Значит и здесь будут рвать последние волосенки бедные программеры. В чем профит?

Тут надо обратиться к истории. Даже SQL серверы далеко не всегда умели транзакции. И тем не менее тот же mysql стал массовым сервером на базе ISAM не умея ни транзакции, ни хранимые процедуры, а firebird или interbase, умеющий и то и другое тем не менее остался в минимальной нише.

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

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

Возникает естественный вопрос - а где полезны транзакции? А полезны они в той узкой нише, где сходятся маленькая нагрузка сугубо интранета, высокая цена ошибки, низкий профессионализм своих отделов программистов, высокие цены и готовность заказчика платить за систему подпорок и костылей.

Подвопрос, почему транзакции так волнуют ЛОР? Потому же, почему местную школоту гипнотизирует слово «энтерпрайз». Транзакции еще волнуют учителей информатики ибо сей механизм укрепляет их либидо в собственных и студенческих глазах.

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

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

result = mybase.table(name).find(key,value).sort(column)

вместо чего-то на тему «select * from name where key=value order by column»

хрен знает, чем это здорово, но это тренд. Смиритесь.

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

Для тупых, ключевое тут «также легко (и быстро), как строки», а то ведь вылезут тут с alter table create/update/drop column...

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

реляционный ответ - создавать под каждый массив свою таблицу. Для справочника фирм, это таблица самих фирм, таблица адресов, таблица телефонов, счетов фирмы и т. д., которые связаны между собой по ид фирмы. Ура, здорово, но теперь операция добавления фирмы в справочник превращается в десяток инсертов по разным таблицам. И в частности, многократно увеличивает вероятность рейсов.

Есть решение? есть. Создаем таблицу из двух полей - id и большой блоб и сериализуем объект «фирма» со всеми его подтаблицами в это бинарное поле, например, в xml виде или еще проще, в json.

Все, теперь у нас есть одна сущность - одна таблица, и теперь добавление одной фирмы порождает один инсерт. Волшебным образом мы не только упростили себе жизнь, но и убили нишу для транзакций. Ура?

Не совсем, нам ведь надо еще искать фирму по отдельным атрибутам, а у нас для этого остался только like %% и то с оговорками.

Что делать? Ну ладно, дублируем ключевые поля объекта фирма в таблицу и при необходимости создаем индексы. Теперь можно искать не только id, но и по всем важным атрибутам. Правда опять недоработка, поиск по внутренним массивам в фирме все еще затруднен ибо в общем случае мы не можем гарантировать, что у нас будет нужное количество столбцов, но это уже детали. Еще пуристы от реляционки будут вопить, что мы дублируем ключевые поля внутри блоба всего объекта и в служебных столбцах, но как говорят в южном парке, по сравнению с аэропортами и это вполне терпимо.

Итак, что мы имеем? Объекты, которые мы сериализируем в json и обратно, простые таблицы из двух столбцов, возможностью неограниченого выпиха в них наших объектов по одному на запись и ограниченого числа столбцов для участия в сиквеловских выражениях и простая объектная обертка над сиквелом для тупых.

А теперь объединим все это в одну сущность, оптимизируем и получим... обычный носиквел.

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

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

НАСТОЯТЕЛЬНО рекомендую прочитать сей линк

Скучно. Графоманство еще одного несчастного, которого заставили использовать кассандру. С одной лишь мантрой на устах: «DBA, DBA, DBA — этот мессия всех спасет». Обвиняет NoSQL-щиков в поверхностном владении SQL, хотя и сам совсем неглубоко погружен в детали конкретных NoSQL хранилищ. УГ, короче.

Все бы хорошо, если бы не было так плохо: описанный пример (как и весь nosql) не позволяет делать атомарный update - только insert, и иногда append. А если поменялся телефон у фирмы? Скачать, обновить, записать обратно - а за это время второй поток обновил адрес... Вот и рэйс, вот и нужны транзакции или хотя бы локи (что по сути очень похоже: транзакции без локов не бывают).

nosql в простейшем виде - это просто очень масштбавируемая система за счет отказа от атомарных обновлений, остается только insert/select.

В более сложном это уже не nosql, а nosql + whatever else.

>В джаве есть xa датасорсы которые реализуют распределенные транзакции через 2 phase commit протокол.

Да внешних их много есть, но в самой базе-то нет. Вон в RAC тоже есть, но какое же оно кривое, убогое и глючное (особенно при падении сети).

А эти ха датасорсы реализуют paxos или что-то свое?

>Все бы хорошо, если бы не было так плохо: описанный пример (как и весь nosql) не позволяет делать атомарный update

не понял, мы в новости про монго или где?

http://www.mongodb.org/display/DOCS/Updating#Updating-update%28%29

nosql в простейшем виде - это просто очень масштбавируемая система за счет отказа от атомарных обновлений, остается только insert/select.

неправда. не надо все сводить к бигтейблу...

В более сложном это уже не nosql, а nosql + whatever else.

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

>НАСТОЯТЕЛЬНО рекомендую прочитать сей линк:

Спасибо. По ссылке — DBA-попоболь не предмет отбивания у него куска хлеба носкульщиками. Мерзенько.

описанный пример (как и весь nosql) не позволяет делать атомарный update
качать, обновить, записать обратно - а за это время второй поток обновил адрес... Вот и рэйс
транзакции без локов не бывают

MVCC в couchdb замечательно с этим справляется без локов.

А как он это делает не расскажете?
Как в разделяемом участке памяти изменить данные не используя блокировки?

в разделяемом участке памяти

WTF? Мы же о системах хранения вроде говорим. Там, прочитал запись, записал запись, не?

Посмотрел mongodb. Из плюсов простая установка и настройка.
Простой и не требовательный к ресурсам драйвер на C.
Из минусов нет нормального разграничения прав доступа.
Боюсь в продакшене злые хакеры потрут все базы.
Нет ссылочной целостности.
Нет проверки целостности данных определяемой пользователями.
Нет транзакций.
Ничерта нет. Есть тупое хранилище JSON коллекций с поддержкой репликации.
Нет инкрементных резервных копий.
Резервное копирование блокирует доступ к БД.
Как замена LDAP пойдет ибо проще в использовании намного, но после допиливания.

Да именно так.
Так как избежать конфликта при изменении объекта JSON двумя конкурирующими процессами?
Они по вашему не в памяти находятся?

> Да внешних их много есть, но в самой базе-то нет. Вон в RAC тоже есть, но какое же оно кривое, убогое и глючное (особенно при падении сети).

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

А эти ха датасорсы реализуют paxos или что-то свое?

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

> А полезны они в той узкой нише, где сходятся маленькая нагрузка сугубо интранета, высокая цена ошибки, низкий профессионализм своих отделов программистов, высокие цены и готовность заказчика платить за систему подпорок и костылей.

Ниша очень большая, например все финансовые системы без транзакций не мыслимы.

Они по вашему не в памяти находятся?

Это или неумелый троллинг или недалекость в целом.

hint: база на 100Gb

Причём здесь размер БД?
Кэширование на запись как там реализовано? Без использования памяти что-ли?

например все финансовые системы без транзакций не мыслимы.

В треде про couchdb 1.0. Я показал как легко и непринужденно финансовые проводки ложатся на couchdb. Без транзакций в терминах реляционных баз данных. Более того я перевел две живые системы на биллинг на couchdb.

Почему я это сделал? Системы стали слишком сложными в поддержке. Из за количества данных появилось нужда хранить рассчитанный баланс. В связи с этим нужно было нехило усложнять код.

Только не надо опять вопрошать как такое вообще возможно. Подробно это рассказано в том топике.

> Да именно так. Так как избежать конфликта при изменении объекта JSON двумя конкурирующими процессами? Они по вашему не в памяти находятся?

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

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

Значит блокировка все-же есть. Пусть и оптимистическая но есть. Остатся добавить транзакции и мы получим deadlock.

Причём здесь размер БД?

Кэширование на запись как там реализовано? Без использования памяти что-ли?

Давай вернемся к исходному вопросу. Ты утверждаешь, что

Скачать, обновить, записать обратно - а за это время второй поток обновил адрес... Вот и рэйс

Без транзакций невозможно.

Осталось узнать что за «разделяемая память» (на клиенте надо полагать).

И причем тут кеширование записи.

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