>поиск в Google по 'eBay PayPal NoSQL' не приносит никаких подтверждений вашему утверждению

Ну, например, http://en.wikipedia.org/wiki/Nosql#Architecture

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

неправильно. потому что sql подразумевает нормализацию данных. А nosql ее не подразумевает.

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

простота хуже воровства.

eBay и PayPal это не совсем одно и тоже. Системы там разные. Про PayPal ничего не знаю.

eBay и начал делать и продавать «облака». они же первыми сделали хранилище - Amazon S3. http://en.wikipedia.org/wiki/Amazon_S3

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

Непротиворечивость БД означает непротиворечивость данных. Это первое и основное требование к БД. А отношение между БД и физическими обьектами, представленными в базе, не зависят от структуры базы данных. Оно зависит только от людей, которые управляют этой базой. И, что самое важное, NoSQL никак не решает эту проблему, скорее - наоборот.

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

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

я не уверен что вы знаете хоть одни из пречисленных языков на уровне уверенного общения с носителями ))) особенно «ароматический язык насекомых» ;))))

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

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

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

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

А кто-то в здравом уме считает, что хоть какой-то инструмент применим для любых областей? :)

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

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

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

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

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

Веществ не нужно - обычного троллинга достаточно.

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

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

ок, ошибка в бизнес-логике работы системы. Но в самой БД нет ошибки - значит БЛ допускает расхождение сумм.

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

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

Как есть УЖЕ проверено в момент внесения изменений.

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

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

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

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

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

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

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

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

Не возможно, а имеет :)

Но сама информация в мире не обладает свойством избыточности.

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

> кто-то в здравом уме считает, что хоть какой-то инструмент применим для любых областей? :)

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

Значит вы неправильно отквотили мне и начали отвечать ;)

Я давно интересуюсь СУБД и NoSQL в частности. Но в областях где я работаю NoSQL не применим ибо требуется ГАРАНТИЯ.

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

S3 это один из вариантов NoSQL.

Поскольку определения что такое NoSQL - нет, то в NoSQL попадают все «не только реляционные СУБД».

>Так что вопрос остается - откуда взялся этот бред про NoSQL в больших компаниях?

Из практики использования :) А то, что редко что-то пишут по PayPal или eBay - так там, небось, сплошные NDA :) А про что-то попроще - пишут немало: http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

>Значит вы неправильно отквотили мне и начали отвечать ;)

Возможно. Сижу в деревне на тормознущем GPRS в Опере-турбо ;)

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

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

Для примера биллинг. Что мешает первичку и движение средств по счетам объединить в один документ? А зачем тогда транзакции? Более того, не нужен костыль в виде отдельно хранимого баланса, так как суммы уже будут посчитаны. Писать биллинг на couchdb было одно удовольствие, очень много головняка ушло как класс.

Повторяю, очень много задач прекрасно денормализуются и ложатся на NoSQL хранилища. Причем это не джедайское «because we can», а именно осознанный выбор, потому что так действительно проще.

Допустим. Тогда как S3 связано с CouchDB? И там что - нет транзакций?

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

Насколько я понимаю, NoSQL == нестандартная база данных. Использование нестандартных вещей обычно означает - люди не смогли сделать то, что им надо, на стандартных вещах. Что - это невозможно?

Есть пример Skype, который сделал более мощную базу на Postgres: http://highscalability.com/skype-plans-postgresql-scale-1-billion-users Вот программеры в Skype сначала включили голову, а потом сделали систему. Кто будет сопровождать сегодняшние NoSQL проекты через 10 лет? а через 30? Проекты на PG сможет сопровождать любой приличный программер или DBA, поскольку они опираются на стандарт. А NoSQL?

Есть еще один довод. Чтобы человек начал делать приличные базы, нужно этим заниматься в районе 5-10 лет. Я, например, этим занимаюсь уже лет 15. А теперь попробуйте найти хоть десяток программеров на конкретный NoSQL с опытом промышленных проектов в 10 лет.

А хотите еще на закуску? В моей Австралии потребность в программерах:

* NoSQL - 2 (два) и оба - на небольшие web-проекты * PostgreSQL - 41 (14 PostgreSQL+senior) * MySQL - 440 (87 MySQL+senior) * Oracle - 2449 (700 Oracle+senior)

Так что - еще будем спорить про NoSQL в больших компаниях? Очень бы хотелось увидеть аналогичные цифры из России, Украины, Штатов..

Простой вопрос

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

извини конечно но в банках поэтому и используют транзакции

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

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

При биллинге как минимум задействованы разные счета в одной операции. Их НЕЛЬЗЯ обьединять. Как вы мыслите обьединение в одном документе одного из счетов компании и счета клиента? Причем есть еще начисления налогов на отдельные счета, различные processing fees.. Остальные ваши идеи на том же уровне.

>Так что - еще будем спорить про NoSQL в больших компаниях?

Конечно, не будем. Применяются. Примеры - выше :)

Это не проблема базы данных, и ни одна база данных ее не решает.

Мы общими усилиями нашли один - S3 в eBay. Про остальные никаких подтверждений не найдено. И, судя по всему это исторически сложившийся маразм, который только подтверждает правило. См. выше - почему важно иметь не велосипед, а стандартную базу данных. Хинт: размеры велосипеда значения не имеют.

При биллинге как минимум задействованы разные счета в одной операции. Их НЕЛЬЗЯ обьединять

Догмат? Обоснование какое-нибудь есть? Почему нельзя? Потому что не ложиться на реляционную модель. Но чем отличается реляционное связывание посредством ссылки на операцию и звязыванием в одном документе?

Как вы мыслите обьединение в одном документе одного из счетов компании и счета клиента?

Так же как одна операция связывает эти счета.

Ту да же и налоги прекрасно входят.

Да, забыл спросить. Если NoSQL базы применяются в больших компаниях - почему никто не ищет программистов на NoSQL?

Это не проблема базы данных, и ни одна база данных ее не решает.

Спасибо за понимание в этом вопросе. А то некоторые товарищи готовы все отдать на откуп транзакциям.

>Мы общими усилиями нашли один - S3 в eBay

eBay - это не просто большая компания. Это одна из крупнейших (по объёмам БД).

А про просто большие - примеры выше были. Вы не читатель, Вы писатель? :)

Ну, тогда вот ещё в копилку: http://www.mongodb.org/display/DOCS/Production+Deployments

«MongoDB is used for back-end storage on the SourceForge front pages, project pages, and download pages for all projects.»

«The New York Times is using MongoDB in a form-building application for photo submissions. Mongo's lack of schema gives producers the ability to define any combination of custom form fields.»

«GitHub, the social coding site, is using MongoDB for an internal reporting application.»

и т.д.

Или вот: http://cassandra.apache.org/

«Cassandra is in use at Digg, Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX, and more companies that have large, active data sets. The largest production cluster has over 100 TB of data in over 150 machines.»

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

Да, забыл спросить. Если NoSQL базы применяются в больших компаниях - почему никто не ищет программистов на NoSQL?

Можно, ради интереса, поинтересоваться, каков спрос на COBOL программистов в Австралии?

>Если NoSQL базы применяются в больших компаниях - почему никто не ищет программистов на NoSQL?

А можно примеры массовых поисков большими компаниями специалистов по любому профилю на публичных ресурсах? :)

И в любом случае это ни о чём не говорит, увы.

>Можно, ради интереса, поинтересоваться, каков спрос на COBOL программистов в Австралии?

Ага. Или на тот же Erlang :)

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

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

А этот бред про документы в биллинге оставьте до вашего первого большого проекта на эту тему. Сразу все станет ясно.

* Cobol - 89

* Erlang - 9

Что интересно, ни в одной из 9ти заявок, упоминающих Erlang, он не был основным языком. Они все искали Java/C#, и все - в одной-единственной компании в Perth (это у нас такая дырка от задницы).

Видишь ли, ты не можешь поместить один из счетов компании в свой супер документ, поскольку этот же счет должен быть еще и в соседнем супер документе

Что мешает одному счету находиться в разных документах? Может имеется некоторое недопонимание? Мне надо привести примеры документов?

Куда попадут все операции между одним счетом компании, и куче счетов клиентов?

Это видимо означает «Как потом выбрать все операции между одним счетом компании и счетами клиентов?». Ответ — легко.

А этот бред про документы в биллинге оставьте до вашего первого большого проекта на эту тему.

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

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

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

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

а в виде чего хранятся оставшиеся средства клиента? и где гарантия что нода один посчитав что он потребил 100Гб сняла 10$ с средств (20-10=10), а нода два посчитав что он потребил еще 50Гб еще 8$ и не получилось потерянных изменений (20$-8$=12$, т.е. что нода два таки увидело обновление от ноды один).

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

>* Erlang - 9

Что интересно, ни в одной из 9ти заявок, упоминающих Erlang, он не был основным языком

Вот и получается, что по запросам вакансий нельзя судить о крутизне использования :)

Можно ещё ту же ADA вспомнить. Или Jovial.

> Допустим. Тогда как S3 связано с CouchDB? И там что - нет транзакций?

и та и другая - представители NoSQL. Про транзакции - не знаю, вроде как там нет транзакций на НЕСКОЛЬКО ИЗМЕНЕНИЙ, т.е. изменения атомарны, но в пределах одного, а не нескольких.

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

Насколько я понимаю, NoSQL == нестандартная база данных. Использование нестандартных вещей обычно означает - люди не смогли сделать то, что им надо, на стандартных вещах. Что - это невозможно?

нет NoSQL это «не только SQL», к примеру PostgreSQL как пост-реляционная и объектная (есть наследование в некотором виде) является NoSQL ;)

Дальше да, NoSQL типа Saccandra применяют там, где возможностей РСУБД просто не хватает. Попробуйте всю Wikipedia перевести на одну РСУБД - свтянет колом вся система. А Saccandra может тянуть всю википедию ибо линейно масштабируется.

PS wikipedia изобрела лисапед в виде свалки MySQL + еще memcached сверху навинтили чтобы получить приемлемую производительность. Так что они как раз могут применить NoSQL и получить выигрыш.

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

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

> Из практики использования :)

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

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

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

>> Насколько я понимаю, NoSQL == нестандартная база данных. Использование нестандартных вещей обычно означает - люди не смогли сделать то, что им надо, на стандартных вещах. Что - это невозможно?

нет NoSQL это «не только SQL», к примеру PostgreSQL

Всё же, под NoSQL сегодня обычно понимают документо-ориентированные и key-value базы.

Прошу прощения. Суть вопроса была вот в этом предложении.

а в виде чего хранятся оставшиеся средства клиента?

В couchdb эти суммы хранятся в узлах B-Tree индекса, который строится во время map/reduce.

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

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

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

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

>* NoSQL - 2 (два) и оба - на небольшие web-проекты * PostgreSQL - 41 (14 PostgreSQL+senior) * MySQL - 440 (87 MySQL+senior) * Oracle - 2449 (700 Oracle+senior) Так что - еще будем спорить про NoSQL в больших компаниях? Очень бы хотелось увидеть аналогичные цифры из России, Украины, Штатов..

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

> Есть пример Skype, который сделал более мощную базу на Postgres

не «более мощную базу», а горизонтально масштабируют postgresql через pl/proxy.

ну и skype так сделал потому, что им совершенно не нужен nosql, поскольку пользовательские аккаунты отлично влезают в реляционные БД.

> Мы общими усилиями нашли один - S3 в eBay. Про остальные никаких подтверждений не найдено. И, судя по всему это исторически сложившийся маразм, который только подтверждает правило. См. выше - почему важно иметь не велосипед, а стандартную базу данных. Хинт: размеры велосипеда значения не имеют.

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

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

К примеру Wikipedia, Twitter (уже перешел), Google (они и сделали BigTable & MapReduce) и другие.

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

Вопрос проще, и не надо уходить от ответа. Стандартная или не стандартная? PG/Oracle/MySQL/MSSQL/etc поддерживают SQL92. Ему учат в любом институте/колледже. Расширения языка (самый пространный - PL/SQL) тоже хорошо описаны. А NoSQL?