Стоит ли использовать MongoDB для финансовых приложений и почему?

Вангую, что ответы разделяться на «нет» и «да». :)
PS: Возьми и попробуй, я за!

Вангую, что ответы разделяться на «нет» и «да». :)

fixed

PS: Возьми и попробуй, я за!

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

разделяться

разделяться
fixed

Ага.

У монго нет поддержки транзакций. /thread

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

Вообще-то я заголовок топика пофиксил от этого замечания.

Я видел, просто забавно вышло.

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

в монге уже появился decimal?

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

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

У монго нет поддержки транзакций. /thread

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

в момент финансовой операции — сначало создаётся <временный_объект>. затем делаются ссылки на этот объект у всех участников будущей операции.

затем внутрь объекта записывается суть проводимой операции: какая именно операции производится, что было ДО, и что станет ПОСЛЕ, текущая метка времени.

затем делается финансовая операция. а этот <временный_объект> — будет гарантировать непротиворечивость этой финансовой операции — в случае внезапного FAIL.

после окончания финансовой операции — временный_объект удаляется, и затем ссылки на него — тоже удаляются.

Сказки из серии «как сделать СУБД из топорамонги»

Сказки из серии «как сделать СУБД из топора^Wмонги»

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

..и о том что — кроме маханизма (протокола) гарантированной правильной записи — необходимо ещё и разработать механизм (протокол) корректного восстановления правильного состояния после FAIL...

..а затем ещё и проработать сценарии своевременного распознавания FAIL-случаев :) [ведь не вручную это всё исправлять!]

то получается — что наверно предстоит много работы для этих баз данных :)

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

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

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

Это что-то вроде такого http://stackoverflow.com/a/8043891 ?

ACID только в токутековском форке 2.2 (man tokumx).

Вы на монге хотите от скуки сделать или реально нужны какие-то ее фичи?

http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

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

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

А так да, уборку помещений в банке тоже можно назвать операцией, связанной с финансами.

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

транзакции в рСУБД отключить нельзя (всякое гогно типа mysql к рСУБД относить не будем), можно только снизить уровень надёжности соответствующими настройками хранилища и СУБД.

В хайлоаде обычно класть на сохранность и консистентность данных, там главное доступность сервиса, а всё остальное вторично. Сами хранилища чаще самопальные под конкретные условияя и известные SQL/NoSQL СУБД входят в них как составляющие.

Спасибо, почитаю.

предстоит много работы для этих баз данных

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

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

Ты про оракл когда-нибудь слышал?

tokumx

Сам использовал? Насколько хороши? Вроде как они недавно только избавились от утечек памяти :)

ACID только в токутековском форке 2.2 (man tokumx).

И то без шардинга.

Сам не использовал. Отзыв хороший http://forum.nodejs.ru/index.php/topic,1842.msg12688.html#msg12688

А в более других db беспроблемный acid на беспроблемном шардинге?

Вы на монге хотите от скуки сделать или реально нужны какие-то ее фичи?

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

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

Еще интересует вопрос как она поведет себя на слабениких VDS, где памяти всего 256Мб-512Мб.

Смотрите вот на что:

- какие ORM есть в наличии
- насколько и как часто вам нужны транзакции
- насколько вам нужны джоины

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

Честно скажу, что мои задачи можно было бы и на сиквеле решить без проблем. Я монгу выбрал больше из любопытства, как и ноду.жс :) .

Еще интересует вопрос как она поведет себя на слабеньких VDS, где памяти всего 256Мб-512Мб.

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

Динамические структуры там эмулируются сериализацией плавающих данных в одну колонку.

Это зависит от СУБД. Но в единственной топиковой рСУБД всё это нормально поддерживается родными средствами и с индексами. Есть ряд расширений (hstore, например) и некая поддержка xml/json, xml при этом можно частично индексировать

Да, посгрес весьма неплох. Там еще есть заточки под полнотекстный поиск и хранение картинок.

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

посгрес весьма неплох

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

Оно уже научилось не репейрится днями после рестарта сервера?

Так у опсосов биллинг база на монге?

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

И еще если индексы не вмещаются в память - ты приехал.

Плюсы базы - это действительно база номер 1 по удобности (стартапы ваять вечер на каком-то MongoDB + HipstorJS), шардинг, MapReduce (и его ускоренно-обрезаная версия Aggregation Framework)

Есть атомарность на уровне сколько угодно сложного одного обьекта. Часто хватает.

Кстати, интересно, как с этим у Монго?

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

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

Еще интересует вопрос как она поведет себя на слабениких VDS, где памяти всего 256Мб-512Мб.

Вполне себе быстро работает как на виртуалках, так и в Virtualbox. Если позволяют средства/время, то разворачивать кластером + репликацию делать. В standalone-режиме оно не сильно инетересно. :)

структуру БД можно менять как душе угодно «на горячую».

В SQL тоже. Alter table.

Реально в монго плюс в другом. Есть у тебя таблица «контрагенты» в которой и физ и юр лица (с совсем разными полями). И у платежа ссылка на элемент это таблицы. В SQL приходится городить нетривиальный огород. Или поле «регистратор» у движения по взаиморасчётам. Там может быть оплата, оказание услуг, корректировка долга, ещё что-нибудь...

Есть атомарность на уровне сколько угодно сложного одного обьекта.

Если нужны итоги (взаиморасчёты, обороты и т.д.), то неудобно. Записи вместо одной таблицы размазаны по всем объектам-регистраторам.

Проще mongo для объектов + SQL для «проводок»

Есть у тебя таблица «контрагенты» в которой и физ и юр лица (с совсем разными полями)

Есть же какие-то общие поля? В PostgreSQL есть наследование таблиц. Делаем таблицу «контрагентов», от нее наследуем таблицы «физлица» и «юрлица», никаких огородов

http://www.postgresql.org/docs/9.3/static/ddl-inherit.html

Ты про оракл когда-нибудь слышал?

да, слышал. глазами её не видел, но ходят слухи что там GUI-инсталлятор :)

это правда?

Картинки мы в базе (PG) храним.

Правда, на раздаче перед ним (и перед сервлетом, отвечающим на запросы картинок) стоит nginx со статическим (proxy_store) кэшированием, а при изменении картинки меняется уникальным образом её ключ. И такая связка работает не просто быстро, она работает, ну, считай, с нулевой нагрузкой на систему при чтении.

Вообще, мне сложно советовать что-то топикстартеру, сам я биллингом не занимаюсь, но идея «играться с фичами» на боевом инстансе биллинга кажется мне кощунственной. Возможно, это потому что на биллинге, который делается в пределах нашей конторы (для телефонных и интернет-провайдеров), подобные фокусы, особенно перед выгрузкой, оборачиваются бессонными ночами менеджеров и программеров, выдранными с корнем волосами и всем, что в волосах затерялось. Но, какгрится, your mileage may vary.

Ну и да, кстати, у Постгреса в отличие от Оракла, сравнительно хорошо с транзакционностью DDL. То есть, можно, начав транзакцию, создать/поменять табличку, потягать туда-сюда данные, посмотреть на них и откатиться, «как будто ничего не было». Не знаю, достаточно ли «для удовлетворения любопытства».

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

Да, проблема такая есть. Только на прошлой неделе обсуждали её с нашим директором, ответственным за функционирование нашей бизнесовой БД (активационные ключи, пользователи итп), объём как раз сравним. Он бы и рад обновиться с 8.3, но ему на это надо порядка 6 часов даунтайма, а ему этого времени пока не дают.

Лет 10-15 назад, да, действительно, Оракл ставили только гуёвым, писанным AFAIR на свинге инсталлятором. И мои дружки, ДБАшники, по тогдашним каналам, нервно матерясь, целили мышкой в красивые кнопочки и менюшки, запущенные подчас на другой стороне планеты.

Но уже с девяткой, как минимум, всё было хорошо, «обычные» RPMки.

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

А если есть DAL, то реализовывать на нём прикладную логику становится уже делом, грубо говоря, индустриальным. И Вам совершенно не важно, как эти данные хранятся «в подложке».

По картинкам есть несколько вопросов:

1. Сколько картинок и какой общий объем?
2. Шардинг картинок делать просто или нет?
3. Стриминг для таких блобов поддерживается (чтобы не было двойного буферирования, особенно на больших блобах) или можно только целиком выхватывать?

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

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

Что значит «финансовые»? Ты хочешь хранить Главную Книгу, Книгу Покупок, Книгу Продаж и т.п. в MongoDB?

Дык, храни, что же тебе мешает? Никаких проблем.

Хочешь, чтобы «закрытие» первичного документа делало записи в Главной Книге (для Бухгалтерского, Налогового и Управленческого учетов), Книге Покупок/Продаж и регистрах складского учета? Вот тут сложнее, т.к. никакой гарантии атомарности.

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

Это, кстати, универсальная идиома MongoDB: вся логика сосредоточена в приложении. MapReduce — это именно MapReduce, а не механизм задания логики БД, или логики обеспечения целостности. И не пытайся определять что именно map и что именно reduce с помощью логики mapReduce, этим должно заниматься приложение ;)

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

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

У них на вики упомянуто некоторое количество способов, однако, полностью живого, работоспособного и рекомендованного решения, насколько я понимаю, нет. Есть некоторое количество тулзеней вида «мигрируем чо угодно куда угодно как угодно, теперь с малиновымна руби». Но, в моём понимании, для тех случаев, когда действительно важно получить консистентную базу и ничего не потерять, без поддержки честного реплэя (бинарных) логов эта задача не решается.

по фичам хорош - спору нет - но у него дикая проблема с обновлением версий.

Три года уже никаких проблем.

Даже при обновлении на минорную версию надо данные конвертировать

Никогда такого не было, Вы что-то путаете.

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

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

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

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

Никогда такого не было, Вы что-то путаете.

иногда бывает. Если не ошибаюсь, когда-то было при переходе на 8.4 с других 8.х

500GB мигрируют около 7 секунд.

Спасибо за информацию. Попробую собрать из исходников ради интереса - просто у меня openSUSE, там так просто рядом разные версии не поставишь. В моем случае данных было совсем немного, поэтому решилось все разворачиванием из sql скрипта.