Ищу схему БД реального биллинга

Почему mongo?

Рубисту положено знать и уметь настраивать это чудо. Восполняю пробел в знаниях :)

Адекватные люди биллинги пишут с помощью реляционных БД

финансовое приложение

отсутствие ACID-транзакций

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

Я б делал на PgSQL. Но на этом тоже можно, а спецов мало =)

Есть некоторая атомарность. Реализуется через зад одновременный доступ к одной записи.

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

Рубистов вообще нельзя пускать к БД. Тем более нереляционным.

Ты сам подымал тему надёжности Монги какое-то время назад :) Судя по тексту темы, ты спросил ещё до чтения документации.

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

Не могу Вас серьёзно, воспринимать, сударь.

Это и понятно. Ты же рубист =)

Но, строго говоря, уже на бумаге столкнулся с проблемами. У них же нет constraints! Продал 23 штуки товара из 20 доступных, например.

Вообще с надежностью баз и CS в целом все грустно - https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads

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

In the meantime, if your application requires linearizable reads, I can suggest a workaround! CaS operations appear (insofar as I’ve been able to test) to be linearizable, so you can perform a read, then try to findAndModify the current value, changing some irrelevant field. If that CaS succeeds, you know the document had that state at some time between the invocation of the read and the completion of the CaS operation. You will, however, incur an IO and latency penalty for the extra round-trips.

Джва года мечтал так кодировать запросы к базе.

Спасибо.

Предположим, журнал в Монге сделает запись гарантированной. Ещё предположим, что денормализация и изоляция на уровне «кортежа» будут достаточными.

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

настоящий мужык должин!!!!!!!

MongoDB
финансовое приложение (бухгалтерия, биллинг)

отличный выбор!

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

Если бы все можно было бы унифицировать то программисты 1С не пользовались бы такой популярностью.

Работал в близкой сфере - биллинг ЖКХ. Унификация в принципе невозможна. Очень много специфики, схема постоянно дорабатывалась.

ИМХО, единственный источник требований к системе - заказчик.

Положим, можно было разглядеть - смысл - исследование.

Рубистов вообще нельзя пускать к БД. Тем более нереляционным.

Руби и БД ещё не значит активрёкорд.

Майское обновление ReOpenLDAP — теперь multimaster-кластер требует в разы меньше RAM

MariadBD?)

Не совсем то =)

финансовое приложение
MongoDB

OMG

Статья старая, с тех пор они улучшили монгу.

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

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

Статья старая, с тех пор они улучшили монгу.

20ое апреля сего года?

Провожу исследование производительности MongoDB

хочу реализовать финансовое приложение

You are doing it wrong. Если тебе нужна скорость выполнения транзакций то возьми за основу tpc-b/tpc-c какой-нить. Правда, оно расчитано на реляционные базы, но хотя бы будет понятно что называют «финансовыми транзакциями». Ещё можно посмотреть на pgbench.

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

20ое апреля сего года?

А, ну тогда всё как я и предполагал: никакими костылями монга не превратится в надёжную БД.

Хм, я думал я знаю ту статью, оказалось что нет. Почитал.

Там описаны типичные грабли большинства свободных решений по репликации БД. Т.е. тут монга совершенно не одинока. Уверен, бОльшая часть решений для mysql и postgres будет иметь точно те же проблемы, к сожалению.

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

Проблема в том что документация монги утверждает обратное.

И вообще весь call-me-maybe — это поиск противоречий между документацией и реальностью. За что автору почтение. Чтобы тыкать носом в говнецо нужен порядочный скил.

http://dbinfo.bitel.ru/ - схема http://bgbilling.ru/ - биллинг

нужна схема данных,

А если графовую бд-шку? [ bookman900]

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

А что не то? Вот человек, занимающийся обозначенной отраслью. Кастуй, спрашивай. Или на их форуме.