Вот смотрите, даже "финансы" бывают разные, одно дело - зафиксировать факт оплаты, здесь и мускул неплохо справится. Другое - держать в базе кошельки с приходом/расходом и фиксировать списание услуг с возможностью отката этих самых списаний, сторно, дебет, кредит и всей этой бухгалтерии, тут постгрес или что-то из энтерпрайза типа сайбейса или оракла. Ибо даже за копейку не в ту сторону придется отвечать и перед налоговой и кастомером, и не понятно, кто из них чёрт в табакерке.
И да, транзакция это не только запись в базу, это еще и блокировки, и, самое важное, ее откат. Другими словами, говоря транзакция, я подразумеваю классическое ее понимание, а именно запись непротиворечивой информации в базу данных в конкурентном режиме.
Обычно говорят, что мне нужно записать информацию в столько-то таблиц по таким-то условиям и если что-то пойдет не так, то вот эта информация должна вернуться в исходное состояние. Вы где нибудь в этой фразе видите тип базы или тип транзакции? И мускул тоже умеет откатить транзакцию, ипостгрес, а вот редис не может (но это не беда, если знать как).
Еще раз 500к транзакций даже в день, и то не нагрузка, ни для постгреса ни для мускула! Вопрос, обычно, не про транзакции, а про их качество.
Берите любую базу.
Нагрузка на базу - она разная! И сильно! В отгом случае у вас транзакция затрагивает 20-30 таблиц и подвывертами, в другом те же самые 20-30 таблиц без транзакций -счетчики обновить. Все сильно будет зависеть и от модели данных и от запросов и от самого приложения. И хорошо спроектированную базу убить можно, пытаясь из нее сделать olap. И херово спроектированную разогнать до космических скоростей.
Серебряной пули нет! Никто не скажет, возьмите базу Х и будет щазтие.
Как пример 1С битрикс, какую базу под него не поставь и как ни оптимизируй - либо на селектах загнется, либо на инсертах, а потому что рукожопие сплошное, вот и извращаются, кто кешами, кто прикруткой редисов, кто голым sql.
Продукт, онине с базы начинается, а с архитектуры, и если мне понадобится воткнуть 5 баз данных, воткну и обосную.
lxfr, тем, что это классика, что 95% инструментария заточено на sql, что это путь к успеху, это понятно, просто и эффективно. Nosql не так прост, увы, и чтобы его правильно приготовить, нужно приложить нетривиальные усилия, а порог вхождения на порядок больше, чем в sql. Нельзя просто взять редис и построить модель данных. В тоже время, даже херово спроектированный sql привнесет меньше ошибок, чем херово спроектированный nosql. А при средних нагрузках разницы не будет вообще, будет только больше удобства от sql.
Это как с автомобилями, всем хороши электрокары, но основная масса выбирает бензин и дизель! Их понятно как строить.
