Вышел CouchDB 1.0

Мне кажется, что БД тут как раз не самое слабое место (и уж точно не RDBMS). Сбор данных и запись в таблицу - это два разных процесса. Если данные идут постоянным большим потоком, имеет смысл вообще юзать распределённую БД или творить что-то типа сплита таблицы по ключу (когда физически таблица находится на разных машинах, но видится как одна).
Если же это неравномерный поток с произвольным пиком нагрузки, то его спокойно схавает общая очередь + пишущий в БД поток.

Психологически, люди (особенно молодые) очень любят отрицать всё старое и бросаться на новые плюшки, поэтому как бы простительно. Но я бы всё же рекомендовал для таких задач воспользоваться обычными РДБМС, благо за 30 (если не 40) лет они в таких системах побывали, что очень прилично развились, сдивнув в кювет хвалёные сетевые и иерархические базы, а объектные даже на сантиметр не смогли их сдвинуть. Ну это просто совет, спорить не обязательно.

> Да давно уже нашёл у ведущих игроков. Вылезайте из анабиоза :)

:) Шпасибо. Я лишь предположил потенциально приемлемую нишу для таких «странных» СУБД, дальше РДБМС я не особо вылезал (не удивительно, что я не в курсе прогресса). Хотя каюсь, ставил как-то Монго и, не найдя элементарных логических операций OR и AND, перекрестил это дело и смело удалил - не для наших это задач.

>Приведите пример, как сделать коллекцию с разным набором полей и разными объектами модели данных в РСУБД.

элементарно.

№1) в объектах реализуем сериализацию и пишем в табличку пару id,blob, где в блобе лежит сериализированный объект.

Собственно, это то, что и делает сабж.

№2 в табличке для любого объекта сохраняем три поля - id, id field, value. Соответственно, каждый объект будет занимать в табличке число строк, равное количеству его атрибутов.

>Я лишь предположил потенциально приемлемую нишу для таких «странных» СУБД

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

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

Понятно, что электронный магазинчик в подвальчике в этих БД не заинтересован. На малых объёмах и без требования масштабируемости обычный SQL часто удобнее.

это не костыль, а прямое решение прямой проблемы.

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

>в табличке для любого объекта сохраняем три поля - id, id field, value

Я когда-то купился на такой подход в одном своём очень далеко не самом крупном по нынешним временам проекте. До сих пор расхлёбываю :D

>1) защита от сбоев электричества вообще никак не относится к транзакциям. Кто тебе вообще сказал подобную глупость?

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

2) Во всех случаях состояние БД является отражением, моделью некоего физического процесса. Купил клиент продукт - появилась запись в БД. Введение транзакций никак не помогает избежать рассинхронизации отражения с моделируемым процессом. То бишь клиент купил хлеба -> глюкнуло -> откат транзакции и что, у клиента не стало хлеба? Нет. На складе хлеба осталось столько же, сколько у тебя в базе? опять нет.

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

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

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

>Я когда-то купился на такой подход в одном своём очень далеко не самом крупном по нынешним временам проекте. До сих пор расхлёбываю :D

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

Первый вариант гораздо лучше.

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

Избыточность вносится с тем, чтобы была возможность:

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

2) минимизировать потери от всех сбоев, спасти накопленную в БД информацию.

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

>> оу, то есть для Вас избыточность данных - это норма?

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

наличие констрейинтов на уровне СУБД + транзакции = непротиворечивость БД в любой момент.

>> для десткого сада разжевываю: чем меньше избыточность - тем меньше противоречивость

Следуя вашей логике RAID - полное говно, в котором все данные противоречивы)

совсем детский сад ;)))

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

>> Бесполезное говно без транзакций

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

транзакции нужны на ЛЮБЫХ операциях с деньгами и обслуживанием пользователей. Если в Инет-магазине или Инет-банке написали, что товар куплен, то он должен быть КУПЛЕН вне зависимости от работы ПО, глюков железа и т.п.

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

> транзакции - тупик эволюционного развития десктопных недоаксессов.

Угу! Даешь вещества!

>> оу, то есть для Вас избыточность данных - это норма?

В природе не просто избыточность данных - норма, а ОГРОМНАЯ избыточность данных - норма :)

это где в природе избыточность данных? если есть пользователь KRoN73 и человек за ним, то второго человека (избыточного) - НЕТ. если вы купили квартиру, то вторая у вас не появится - ее тоже придется купить.

Можно хотя бы три примера избыточности?

> И то они уже работают под такими нагрузками, что просто сливай воду :) Facebook, Digg, eBay...

там нагрузки специфические, как только потребуется консистентность данных между ВСЕМИ узлами, так сразу транзакции и прочие плюшки РСУБД потребуются

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

Так что если транзакций нет, то никакой полезной информации в базе хранить нельзя. За исключением описания домашней коллекции фильмов или mp3.

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

Огромные базы, и на системе без транзакций? Курите еще - ждем новых откровений.

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

2. расхождение между физ.процессом и информацией в БД никоим образом к инфо-системе не относится - за это ответственны ЛЮДИ. Продавцы в магазине или зав.складом.

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

Если транзакций нет, то где гарантия, что состояние БД будет хоть как то соответствовать состоянию ДО сбоя?

>> в табличке для любого объекта сохраняем три поля - id, id field, value

Я когда-то купился на такой подход в одном своём очень далеко не самом крупном по нынешним временам проекте. До сих пор расхлёбываю :D

EAV удобный подход, но для своих задач )))

У нас применялся гибридный вариант - аттрибуты по которым идет связь (fk), поиск (всякого рода индексы) и т.п. жестко прописаны в таблице, а дополнительная информация переменного вида лежит в виде EAV.

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

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

а теперь прикинь что нить этакое когда добавление одной строки в запись порождает изменение в 15 связаных таблицах

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

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

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

Не стану. bigtable уже придумали.

чет примеры жидкие на одну таблицу и пару полей

ай молодца. у тебя в базе уже поля без таблиц появились?

> Избыточность вносится с тем, чтобы была возможность:

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

2) минимизировать потери от всех сбоев, спасти накопленную в БД информацию.

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

а нафига, если уже есть решение? 1. при любом сбое логики - получаем constraint violation и данные не изменяют состояние БД. 2. резервное копирование придумано как раз для этого.

допустим если в БД 40-50 таблиц (что очень мало), то сделать резервную копию - задача тривиальная. а сделать по дублю на поле - нафига? сделать собирательные поля - их обратно парсить сложно, а в некоторых случаях просто невозможно ввиду необратимости операций.

> Ради интереса тестировал вставку данных на 150 гигабайтной базе. (Интерес возник, потому что есть проект где используется PotgreSQL для задачи с таким объемом данных). У CouchDB скорость была порядка 80 записей в секунду (у PostgreSQL не помню сколько но в разы меньше). Так что для определенных задач я думаю это очень даже полезный проект.

Это как же надо извращаться? Ну ладно - на моих проектах данные датчиков пишутся со скоростью примерно 12 тыс записей в секунду в Postgres. Спишем на странность базы, вероятно. Но: Вчера разворачивал базу OpenStreetMaps. Скорость ввода - порядка 19 тыс в секунду при обьеме базы в 170Gb. Машинка - 3GHz Dual Core, не то чтобы ах. При 80 записях в секунду я бы просто не дождался результата в этом году.

Теперь вспомним еще одну интересную вещь. Отключение транзакций (если оно возможно на конкретной базе) приводит к ускорению операций ввода от 3х до 5ти раз. Я пробовал на Informix и MSSQL. Другое дело, что ни для какой базы данных с больше чем несколькими таблицами режим 'без транзакций' не используется.

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

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

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

потому что заказчик поставил в ТЗ 15 таблиц ;)

bigtable уже придумали.

bigtable не заменяет РСУБД... и наоборот - у них разные ниши.

> Теперь вспомним еще одну интересную вещь. Отключение транзакций (если оно возможно на конкретной базе) приводит к ускорению операций ввода от 3х до 5ти раз. Я пробовал на Informix и MSSQL. Другое дело, что ни для какой базы данных с больше чем несколькими таблицами режим 'без транзакций' не используется.

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

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

>2) минимизировать потери от всех сбоев, спасти накопленную в БД информацию.

ну тут тоже можно сделать вариант журналирования неудачных транзакций только когда это касается и уж тем более бугалтерии то значение должно быть одиночным а не по принципу если оно тут не правильно то возьмем соседнее ,не удалась транзакция значит и не надо ее ,значит и остатки счетов не изменились, а так получается фуганули не фуганули а если ошибка не по причине какого то непредвиденого сбоя а она физически и есть ОШИБКА а мы взяли и применили ошибочные данные старые спасать де? (а ну у тебя же есть костыль на базе избыточности), такой подход для чатов удобен , так протеворичивости не избежать

> это где в природе избыточность данных? ...

в любой твоей человеческой клетке — находятся ДНК-молекулы с одинаковыми нуклеиновыми последовательностями...

...а знаешь сколько в человеке клеток? вот и поумножай сколько раз ДНК-информация продублировалась! :-) :-D

а если ты предположим десятый-раз-подрят опоздал на работу, потом приходишь туда (через несколько часов) — то можешь поспрашивать отдельно каждого из твоих сотрудников и они тебе [каждый поотдельности, с различными нюансами] — расскажут [копию] истории о том как начальник в бешенстве тебя уволил :-D

....вобщем примеров много :-)

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

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

ну зачем, зачем ты раскрыл тайну и сократил тред минимум на 10 страниц ?

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

>это где в природе избыточность данных?

Да хотя бы в твоей ДНК :)

Можно хотя бы три примера избыточности?

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

Собственно, тебе встречный вопрос - назови три примера из природы, где нет информационной избыточности :D

>как только потребуется консистентность данных между ВСЕМИ узлами

Тогда можно ставить крест на по-настоящему больших системах. Или сильно терять в производительности.

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

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

>это вообще глупость... единственное чем здесь транзакции

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

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

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

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

А в чем тогда был глюк, если с базой ничего и не делали?

Если транзакций нет, то где гарантия, что состояние БД будет хоть как то соответствовать состоянию ДО сбоя?

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

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

для этого и придумана информационная избыточность.

потому что заказчик поставил в ТЗ 15 таблиц ;)

неправильно. потому что sql.

bigtable не заменяет РСУБД... и наоборот - у них разные ниши.

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

>Огромные базы, и на системе без транзакций?

Именно так. Базы петабайтных объёмов у тех же eBay, Wallmart, PayPal - ИМХО, вполне себе огромнык БД. И, да, они на NoSQL. Хотя конкретной информации по их инфраструктуре, правда, я навскидку не нашёл.

Но есть, зато, инфа по более простым, но всё равно большим системам.

Скажем, небезызвестный тут SourceForge использует MongoDB.

Twitter свои 100Тб недавно перевёл с MySQL на Cassandra.

>>потому что заказчик поставил в ТЗ 15 таблиц ;)

неправильно. потому что sql.

В реальной базе данных таблица соответствует entity в задаче. Ты что, не можешь представить себе задачу с 15 entities? У меня пока еще ни одной базы меньше чем с 20-30 не было (и это были простейшие базы). Правда, наколенных баз для домашнего применения я не пишу.

на счет ДНК - ХЗ я не спец ;)

а если ты предположим десятый-раз-подрят опоздал на работу, потом приходишь туда (через несколько часов) — то можешь поспрашивать отдельно каждого из твоих сотрудников и они тебе [каждый поотдельности, с различными нюансами] — расскажут [копию] истории о том как начальник в бешенстве тебя уволил :-D

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

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

естественные языки к миру отношения не имеют - это антропогенное явление.

Собственно, тебе встречный вопрос - назови три примера из природы, где нет информационной избыточности :D

Рождение ребенка - либо родила, либо нет. Езда на машине - либо доехал, либо нет. Фактически любое действие в реальном мире не имеет избыточности.

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

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

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

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

Я не могу сказать - что использует eBay или PayPal (это одна и та же компания). Но одно совершенно ясно - если они умудрились использовать NoSQL, то идиотизм это редкостный. Сдуру можно и член сломать, знаете ли.

Впрочем, поиск в Google по 'eBay PayPal NoSQL' не приносит никаких подтверждений вашему утверждению. Откуда вы это вообще взяли?

>естественные языки к миру отношения не имеют - это антропогенное явление.

Даже когда это язык птиц, дельфинов или ароматический язык насекомых? :D

Рождение ребенка - либо родила, либо нет.

Ты даже вопроса не понял.

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

Уточняю вопрос: приведи три примера природной передачи информации без её избыточности.

>1. при любом сбое логики - получаем constraint violation и данные не изменяют состояние БД.

с какой стати? В одной таблице ведем проводки, а в другой считаем баланс. Взяли и не учли признак проводки и в итоге суммы не совпали. Ошибка? да. constraint violation? нет.

резервное копирование придумано как раз для этого.

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

а сделать по дублю на поле - нафига?

никаких дублей. избыточность не есть дубли.

> для этого и придумана информационная избыточность.

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

потому что заказчик поставил в ТЗ 15 таблиц ;)

неправильно. потому что sql.

без sql это будут сущьности. если набор аттрибутов сущьности стабилен, то проще всего их однозначно замаппить на таблицы ;)

потому если 15 сущьностей, то 15 таблиц (упрощенно ;) )

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

а не проще при включеных транзакциях вести журнал неудачных

>наличие констрейинтов на уровне СУБД + транзакции = непротиворечивость БД в любой момент.

Непротиворечивость в самой себе. Это тот конь в вакууме, который необходим матаппарату sql. А система должна быть непротиворечива реальности. А это совсем другое.

>а не проще при включеных транзакциях вести журнал неудачных

нет. журнал транзакций != журнал операций.

> Именно так. Базы петабайтных объёмов у тех же eBay, Wallmart, PayPal - ИМХО, вполне себе огромнык БД. И, да, они на NoSQL. Хотя конкретной информации по их инфраструктуре, правда, я навскидку не нашёл.

eBay - там распределенная реплицируемая хэш-таблица. Кстати за консистентностью данных должно следить приложение - сама система eBay за этом не следит совсем.

Twitter свои 100Тб недавно перевёл с MySQL на Cassandra.

только они не обеспечивают гарантий при работе со своим сервисом. там где требуются гарантии Cassandra увы не применима.

>> совсем детский сад ;)))

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

Так и NoSql базы не вносят избыточности на уровень данных, а обеспечивают ее на более низком уровне. О чем собственно у нас и был спор. Мой оппонент говорил, что избыточность нарушает целостность, а я говорил, что избыточность ДАННЫХ МОЖЕТ нарушать целостность. Тогда как избыточность хранения наоборот увеличивает надежность.

>> как только потребуется консистентность данных между ВСЕМИ узлами

Тогда можно ставить крест на по-настоящему больших системах. Или сильно терять в производительности.

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