Вышел CouchDB 1.0

>> т.е. что нода два таки увидело обновление от ноды один

Я очень, очень хочу верить, что в мире больше не осталось балбесов, которые пишут не insert only биллинги.

как вы на инсерт-онли будете обновлять сумму остатков у клиента? и как поймаете ситуацию что остаток равен нулю и нужно отключить от Инета?

> На рынке эти NoSQL базы не распространены, и программисты на них никому не нужны.

давайте не будем столь категоричны. те данные, которые уже лежат в hbase/bigtable/cassandra и.т.п. - никуда не денутся.

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

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

> приводить ebay как пример использования nosql я лично не стал бы, да. поскольку там java + oracle чуть более, чем везде.

http://highscalability.com/blog/2008/5/27/ebay-architecture.html

nosql - это google/bigtable, yahoo/hadoop, twitter/cassandra, facebook/cassandra.

произошла путаница ))) говоря о eBay имелось в виду Amazon ;) а уж у Amazon многое включая eBay крутится на «облаках», кои на своей собственной платформе. Заодно платформу еще и другим продают.

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

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

>Вопрос проще, и не надо уходить от ответа

Это Вы к чему? Цитируйте сообщения, на которые даёте комментарии, а то совершенно непонятно, что у Вас в голове.

> Здравому смыслу по использованию в проектах опытных программистов NoSQL тоже противоречит: нет проектов - нет опытных программистов. Поддерживать любой из сегодняшних NoSQL проектов через 10 лет будет некому. С точки зрения менеджеров это просто кошмар.

я как приверженец РСУБД таки должен тебя остановить ))) NoSQL только начали развиваться, потому опытных мало. Но есть область - облачные вычисления, так в ней только NoSQL и выживут... а сама область развивается чуть больше чем активно ;)

> Мне незачем изменять клиента при внесении операции, мне незачем менять счет компании при внесении операции, поэтому в документе это ссылки, а не сами объекты.

так ссылка это relation ;) вот и создается «Р» СУБД под другим соусом и с несколько иным функционалом =)))

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

А почему Skype об этом не знает?

Cassandra is in use at Digg, Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX, and more companies.

Digg, Facebook, Twitter - понятно. Там стоимость информации практически равна 0, также как и ответственность этих компаний за эту информацию. Вот некоторые примеры:

Facebook uses Cassandra to power Inbox Search, with over 200 nodes deployed. - Чему равна стоимость потери/некорректности информации?

Digg, the largest social news website, announced on Sep 9th, 2009 that it is rolling out its use of Cassandra and confirmed this on March 8, 2010 - Опять, website без особых требований к информации.

Twitter announced it is planning to use Cassandra because it can be run on large server clusters and is capable of taking in very large amounts of data at a time. However, these plans were subsequently scaled back or scrapped - Оп-па, они уже все поняли.

Cisco's WebEx uses Cassandra to store user feed and activity in near real time - Опять, стоимость информации низкая, главное требование - быстрое ее записать. Хранить ее они явно будут отдельно, в чем-то еще.

Reddit switched to Cassandra from memcacheDB on March 12, 2010[14] and experienced some problems with overload handling in Cassandra in May - Ну, если раньше у них была memcachedb, они совершенно точно не страдали паранойей по поводу надежности.

Cloudkick uses Cassandra to store the server metrics of their users - Правда-правда? Какие ценные данные!

> как вы на инсерт-онли будете обновлять сумму остатков у клиента?

Не сразу понял вопрос, поэтому upd: http://www.linux.org.ru/jump-message.jsp?msgid=5111473&cid=5115478

То есть баланс считается базой а не руками.

и как поймаете ситуацию что остаток равен нулю и нужно отключить от Инета?

Тут couchdb не отличается от реляционных.

так ссылка это relation ;) вот и создается «Р» СУБД под другим соусом и с несколько иным функционалом =)))

Забавно, то есть NoSQL всегда воспринимается как полная денормализация и не иначе?

>Забавно, то есть NoSQL всегда воспринимается как полная денормализация и не иначе?

ну так если нет join, то как ты собрался собирать столбцы (которых по сути тоже нет) в кучку?

>> Мне незачем изменять клиента при внесении операции, мне незачем менять счет компании при внесении операции, поэтому в документе это ссылки, а не сами объекты.

Вот это мне понравилось. Тут две ямы замаскированы. Первая: Вместе 'мне незачем' надо было честно написать : 'я не могу'. Хотя бы поскольку в реальной ситуации это полезно - обновлять либо запись счета с его балансом, либо историю операций. И вторая - если есть ссылки, значит есть и обьекты. А как же Великая Идея 'Все в однм документе'?

Я действительно не понимаю - есть обьекты, есть отношения между ними. Где принципиальная разница от SQL? И если разница - в запрете транзакций, то опять-таки - это делается на обычном SQL, просто на практике это не нужно. А если разница в API базы (нет SQL) - то это просто болезнь 'сделано не здесь'.

ну так если нет join, то как ты собрался собирать столбцы (которых по сути тоже нет) в кучку?

В couchdb есть join )))

> То есть баланс считается базой а не руками.

Нам все равно - кем считается баланс. Нас интересует: при операции записывается сама транзакция (insert) и меняется баланс в отдельной записи (update). Эти две операции образуют транзакцию. Попытка это сделать без транзакции приводит (при некоторых условиях) к нарушению целостности данных.

Все очень просто: Если надо каждый раз считать баланс по операциям, то вам надо срочно поменять розовые штанишки. А если он посчитан (неважно кем) и хранится отдельно - то без транзакций не обойтись.

Кстати, в моем предпоследнем месте работы, в банке, расчет service fee по транзакциям занимал 16.5 дней. А рассчет того же самого по предварительным суммам занимал порядка 2 часов. Разница понятна?

>Чему равна стоимость потери/некорректности информации?

Очень больших денег стоит. Единичные потери, конечно, будут незаметны, но как только надёжность упадёт хоть сколько-то заметно, начнутся массовые жалобы коммьюнити и народ начнёт сваливать на более надёжные социальные системы. И рыночная стоимость фейсбука начнёт падать стремительным домкратом :)

Опять, стоимость информации низкая, главное требование - быстрое ее записать

Я ещё раз повторюсь. Не ставится цель доказать, что NoSQL применим всюду. Очевидно, что это не так. Ставится целью опровергнуть заявления, что крупные компании не используют NoSQL. Надеюсь, разница очевидна?

Я действительно не понимаю - есть обьекты, есть отношения между ними. Где принципиальная разница от SQL?

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

>Непротиворечивость БД означает непротиворечивость данных. Это первое и основное требование к БД.

Это опциональное требование к реляционной БД, а не к БД вообще. Иначе при денормализации данных, которая происходит практически в каждом запросе sql появится неоднозначность.

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

ура. стало быть структура БД может быть любой.

Оно зависит только от людей, которые управляют этой базой.

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

И, что самое важное, NoSQL никак не решает эту проблему, скорее - наоборот.

С точки зрения теории NoSQL является подмножеством sql. Так что в вакууме ничего нового он дать не может. А в реальности за счет более простыхи продвинутых инструментов масштабирования - дает.

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

Смотрите выше. Реализовать корректный биллинг описанным вами способом нельзя. Нужны транзакции.

Нам все равно - кем считается баланс. Нас интересует: при операции записывается сама транзакция (insert) и меняется баланс в отдельной записи (update). Эти две операции образуют транзакцию. Попытка это сделать без транзакции приводит (при некоторых условиях) к нарушению целостности данных.

Прозреваю, вы совсем не знакомы с матчастью. Серьезный человек рассуждает о couchdb, но при этом ни бельмеса не понимает. До этого вы казались более адекватным.

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

>Нам все равно - кем считается баланс. Нас интересует: при операции записывается сама транзакция (insert) и меняется баланс в отдельной записи (update). Эти две операции образуют транзакцию. Попытка это сделать без транзакции приводит (при некоторых условиях) к нарушению целостности данных.

1) попытка делать все через транзакции не исключает ошибки, а только маскирует их.

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

>С точки зрения теории NoSQL является подмножеством sql

Гы :D

>> Непротиворечивость БД означает непротиворечивость данных. Это первое и основное требование к БД.

Это опциональное требование к реляционной БД, а не к БД вообще. Иначе при денормализации данных, которая происходит практически в каждом запросе sql появится неоднозначность.

Еще раз, по буквам. НИКОМУ не нужны данные, для которых не выполнена непротиворечивость. Независимо от базы данных. Так что мне совершенно все равно, как быстро NoSQL создает данные с потенциально нарушенной структурой.

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

Пролью свет. Конкретная банковская проводка изменяет по крайней мере два независимых друг от друга обьекта, которые нельзя обьединить в одном документе. Кроме того, нужно еще посчитать некоторое кол-во fees/taxes/etc и поместить их еще в несколько обьектов. Хочется услышать, как, скажем, transaction fee или compound interest (которые зависят от договора обслуживания на счет и еще кучи условий) будут обновляться автоматом, через b-tree.

Что же касается couchdb, то сам факт, что она не поддерживает транзакции уже перечеркивает ее практическую ценность. Именно это и обсуждалось.

>НИКОМУ не нужны данные, для которых не выполнена непротиворечивость. Независимо от базы данных. Так что мне совершенно все равно, как быстро NoSQL создает данные с потенциально нарушенной структурой.

Вот, опять пошли глобальные обобщения, легко опровергаемые сегодняшней рыночной практикой. Это такой троллинг или такая неадекватность?

Вот, возьмём конкретно Twitter на Cassandra.

Cassandra не обеспечивает непротиворечивость или Twitter уже не относится к категории КОГО-НИБУДЬ? :)

В couchdb есть join )))

вот такой?


In SQL, this would probably be represented as a table of authors and a table posts. Getting the aggregate result would be something along the lines of:

SELECT * from authors join posts ON authors.id = posts.author_id

This is just a simple standard JOIN, nothing very interesting about it. However, in a document oriented system this “join” operation doesn’t really exist. Enter view collation.

View collation allows us to define a map/reduce function pair that takes in multiple document types, aggregates them onto a single key value, and gives us a means to search on author id.

Let’s say we have an author document like the following:


{'type' : 'author', 'name' : 'Chris Chandler', '_id' : '22d43eaa7e06c9c37ed3e0489401a506' }

and some number of post documents similar to:


{'type' : 'post', 'title' : 'Hello world', 'Body' : 'body text', 'Author' : '22d43eaa7e06c9c37ed3e0489401a506' }

In this case our “foreign key” is 22d43eaa7e06c9c37ed3e0489401a506. The mapping function would need to connect these records based on that key is something like the following:

function(doc) {
if(doc.type == 'author')
{
emit(doc._id , doc);
}
else if(doc.type == 'post')
{
emit(doc.author, doc);
}
}

This view will generate an intermediate hash table containing entries with the author’s key. In essence we have one key (the author’s) pointing to either a post the author has created, or the author’s record itself. To make this view answer the question ‘Show me all posts created by a certain author’ we need to write a reduce function that removes the unnecessary author records so the final table will only contain author keys pointing to lists of posts.


function(keys, values, rereduce)
{
var posts = [];
for(var i = 0; i < values.length; i++)
{
if(values[i].type == 'post')
{
posts.push(values[i]);
}
}

>Что же касается couchdb, то сам факт, что она не поддерживает транзакции уже перечеркивает ее практическую ценность

Сегодня масса NoSQL-систем без транзакций имеет практическую ценность у весьма крупных игроков рынка. Вы принципиально игнорируете этот момент? Фильтр на входе стоит или что?

> 1) попытка делать все через транзакции не исключает ошибки, а только маскирует их.

Месье бредит?

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

Если?? Он всегда занимает слишком много времени. Забудьте ваши наколенные поделки, последняя база данных, с которой я работал, была 300GB и считалась маленькой.

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

>Еще раз, по буквам. НИКОМУ не нужны данные, для которых не выполнена непротиворечивость. Независимо от базы данных. Так что мне совершенно все равно, как быстро NoSQL создает данные с потенциально нарушенной структурой.

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

Блин, выключи идиота и поищи работу на NoSQL. ЕЕ НЕТ. Хватит трепа - я все обьяснил про тип хранимой в NoSQL информации, по каждому из твоих игроков рынка.

Ты сам-то понял, что сказал?

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

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

Хочется услышать, как, скажем, transaction fee или compound interest (которые зависят от договора обслуживания на счет и еще кучи условий) будут обновляться автоматом, через b-tree.

Движения по всем счетам отражаются в одном документе, в том числе и fees/taxes/etc. Не вижу принципиальной разницы между этими движениями и основной проводкой.

> вот такой?

No-no-no. Вот такой http://blog.couch.io/post/446015664/whats-new-in-apache-couchdb-0-11-part-two...

Товарищ, зачем вы кричите и топаете ногами? Успокойтесь, никто вас не заставляет использовать NoSQL.

>Валидировать операции - это делает база и без вас.

бред. для этого надо знать логику моделируемого процесса. А база этой логики не знает.

Он всегда занимает слишком много времени. Забудьте ваши наколенные поделки, последняя база данных, с которой я работал, была 300GB и считалась маленькой.

Еще один буратинистый пионеришко, попавший в БАНКу. То-то я смотрю, банк-клиент через жопу работает...

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

нет.

>а я говорил, что избыточность ДАННЫХ МОЖЕТ нарушать целостность.

избыточность сама по себе ничего не нарушает.

>No-no-no. Вот такой http://blog.couch.io/post/446015664/whats-new-in-apache-couchdb-0-11-part-two...

Ну само по себе неплохо. Хотя понятно, что это скорее для исключений, чем для постоянной работы.

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

По-моему, в этом тексте две лишние запятые и две лишние точки.

>Блин, выключи идиота и поищи работу на NoSQL. ЕЕ НЕТ

Не нужно кричать. Чуть раньше этот вопрос уже оценивался с точки зрения вакансий на тех же Erlang, Ada, Jovial...

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

То есть Вы согласны, что есть крупные игроки, которым нужен NoSQL?

>сейчас 99% БД используются в полу или вообще нереляционном режиме.

Как интресно! «полу-» - это как? И «вообще» - это ващще без таблиц?

>В сабже - мат фундамент это B-trees.

Чем дальше в лес, тем толще партизаны. Причём здесь индексы с их математикой? Я спрашивал что фундаментально НОВОГО придумали в NoSQL.

>Блин, выключи идиота и поищи работу на NoSQL

Мусье знает про GemStone и её ООПБД?

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

Как то ты всё упрощаешь. Кроме объектов есть ещё и связи, которые могут с трудом укладываться в реляционную модель (те же иерархические взаимосвязи). Или есть, к примеру, проблема temporal databases, которую классическая реляционная теория не решает. Дейт даже выдумал 6NF для таких баз, но на SQL это выражается просто отвратно. Есть проблема горизонтального масштабирования, о чём тут много говорилось. Да хватает проблем у РСУБД. Ну подумай, не спроста ведь появились такие извращенские техники, как 6NF, DKNF, а с другой стороны денормализация, шардинг... Просто далеко не каждый домен можно легко впихнуть в прокрустово ложе реляционной теории. Я не сомневаюсь, что программисты с over 10 годами опыта кромсания данных под РСУБД, способны это сделать для любого произвольного набора. Но насколько это решение будет затратным, вот в чём вопрос.

Посмотрите, в конце концов, на пример Кобола. Ему учили в каждом университете. На нем написано, по некоторым данным, да 60% всего софта на этой планете. А найти программера на Коболе сейчас почти невозможно.

Так ведь Кобол когда то был баззвордом не хуже Оракла. И промышленным стандартом, да. А теперь никому не нужен, потому что есть более эффективные и удобные средства. Это как бы аргумент против тебя. Представь (гипотетически), что через десять лет промышленным баззвордом стал какой-нибудь MongoDB c SQL-расширением. Все сайты вакансий пестрят объявлениями «требуется Mongo-программист, желательно со знанием SQL». А старые Oracle DBA с огромным опытом никому не нужны (кроме как для поддержки легаси), их крики о трушности чистых РСУБД воспринимаются как чудачества выживших из ума гиков. Это я всё к тому, что твои доводы о текущей востребованности на рынке не очень то сильны. Индустрия конечно подвержена инерции, но предсказать, какие технологии будут более востребованы на рынке через 10 лет невозможно.

> избыточность сама по себе ничего не нарушает.

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

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

Троллинг, троллинг... Ну, как хотите.

>Как интресно! «полу-» - это как? И «вообще» - это ващще без таблиц?

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

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

А почему Skype об этом не знает?

Skype сделал линейно масштабирующуюся РСУБД с транзакциями? или они просто тупо sharding зафигачили через проксирование и никакого ACID между нодами не обеспечивается?

>> как вы на инсерт-онли будете обновлять сумму остатков у клиента?

Не сразу понял вопрос, поэтому upd: http://www.linux.org.ru/jump-message.jsp?msgid=5111473&cid=5115478

То есть баланс считается базой а не руками.

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

>> так ссылка это relation ;) вот и создается «Р» СУБД под другим соусом и с несколько иным функционалом =)))

Забавно, то есть NoSQL всегда воспринимается как полная денормализация и не иначе?

то как вы описали хранение в виде документов у меня (и не только у меня) вызвало понимание хранение в денормализованном виде типа key-value.