Вопрос я бы поставил так – сейчас разрабатывается сабжевая система, а вернее биллинговая надстройка над ней и вопрос такой – можно ли … или даже так – почему не стоит использовать вместо предполагаемого Оракла MongoDB и чем может это грозить. С nosql базами я еще не работал но очень интересно. Теорию я покопал но меня интерсует мнения практиков.
Почему я спрашиваю – послушал тут как то Радио-Т там один из ведущих работает в какой то финансовой американской конторе, весьма немелкой, которая занимается по сути агрегацией биржевых данных и у них объем данных около 4 миллиардов!!! записей в день – это не просто много, а чудовищно много. И он как раз очень нахваливал монго. Правда насколько я понял они используют монго в основном как хранилище данных за счет быстрого добавления данных а биллинг все таки немного не то – есть там некая транзакционность и некий анализ, но не очень то сложный – прибавить/отнять/разделить - никаких интригалов, приближенных вычислений - вобщем никакой нечоткой логики :( Все как в обычной учетной системе – клиенты, счета ну и так далее. Другой ведущий Радио Т - начальник разработки по в яндексе, судя по разговору человек с тонким пониманием, и тоже монго весьма нахваливал. Вот я бы и хотел, что бы меня отговорили, а то ведь систему выпускать рано или поздно в продакшн со всеми втекающими и вытекающими - вот и хочется вопрос с монгой закрыть раз и навсегда и перейти на темную сторону т.е. отдаться уже Корпорации Зла :) Но мятежный дух и любопытство возобладает таки и хочется посмотреть что еще. Короче крайне интересно мнение коллективного разума по сабжу. Если серьезно хотелось бы ясно осозновать сферы применимости MongoDB в особенности по сравнению с SQL базами - Oracle, MSSQL, PostgreSQL ...

thehil,

О! почти первая же ссылка в точку. Как то про use cases я не нашел с перевого раза инфу у них на сайте. Мне непонятно вот только эта фраза:

"Less Well Suited
Systems with a heavy emphasis on complex transactions such as banking systems and accounting. These systems typically require multi-object transactions, which MongoDB doesn't support. It's worth noting that, unlike many "NoSQL" solutions, MongoDB does support atomic operations on single documents. As documents can be rich entities; for many use cases, this is sufficient. "

т.е система обеспечивает атомарность операций над протсым документом - а вот про rich entities я не совсем допонял.

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

Название сайта тоже хорошее - жопикс :) Хотя некоторые аргументы да настораживает и желательно их обдумать или проверить если предполагается выпускат приложение в серьезный продакшн.
Совершенно согласен что обеспечить атомарность для сложных объектов будет затруднительно и это killing аргумент для моего случая... Спасибо за ответы.

2Yo!

ну не так все сурово - данные легли (пусть даже в реалтайме) индекс пересчитался. В торговых роботах как правило пересчитывается все на лету до отправки в бд, так как очень критичны временные задержки - данные уже потом используются для анализа и отчетов. А отчетные системы используют (в большинстве случаев) по итогам торгов. А вот системы которые пересчитывают в риал тайме позиции игроков .. это да. Тут если и делать на монге нужно ОЧЕНЬ сильно поэксерементировать. Но вообще нафиг - своя рубашка лучше сидит когда ты живой :)

Я посомотрел - как раз очень близко к модели брокерской компании. Но биржевые вещи имеют свою специфику - я как раз разрабатывал такие. Там очень критичны временные задержки в особых местах. Прям реально борьба за миллисекунды. Пример - работал в крупном банке западном - там трейдеры жаловались что экран недосточно быстро прорисовывает котировки - пришлось им приладу переписать вместо си шарпа на правоверном с++ и стало хорошо. Это редкий случай но тем не менее. Там кстати оракл стоял с каким то астрономическим количеством таблиц и это все как то даже работало :)
В моем случае нет таких хайлоадов - но критична надежность, досупность.
Начальство кстати как увидело стоимость Оракла (энтерпрайз эдишн 47 тыщ не рублей на ОДИН проц вернее даже на одно ядро) ... стало сильно думать так что возможно будет таки Постгресс. И я не думаю что постгресс будет сильно хуже или вообще хуже.

Решение для любой базы не очень хорошее имхо. Как показывает моя практика (лично моя) очень тяжело если вообще возможно оторватся от специфики бд. Полностью без триггеров вьюешек сторед процедур ... Как показывает пример PDO (для PHP) в случае того же Оракла там совсем все нерадужно.
Кроме того закладка на любую бд сильно усложняет/удлиняет разработку.

2thehil - да нет я писал что там нет такого хайлоада как в биржевых системах -нет там тысяч запросов в секунду. Клиенты заходят видят свой биллинг откуда то тянутся данные но все без экстрима. Кстати даже на биржевых системах - был проект на московских биржах через квик клиент - максимум что нам удавалось выжать около 10 000 записей в секунду с ММВБ (а вообще сильно ниже нагрузка) - MySQL 5.5 справлялся на раз, ну даже не чихнув. Вообще не одного сбоя не было со стороны БД за год. С MySQL сложности начинаются когда в таблицах больше 7-10 миллионов записей и много инсертов и много индексов. Но кеширует запросы весьма хорошо.
Насчет горизонтального масштабирования я думаю это как раз по любому будет нужно что с Ораклом что без - система должна быть высокодоступной - на начало маленький кластер по любому. так что горизонтальное масштабировнаие оно как бы закладывается изначально. Вопрос в цене уж больно Оракл дорогой.