Смотря для чего... Быть может и не та и не другая под конкретный проект не подойдет)
Сейчас выбор большой и уже нужно отталкиваться от конкретной задачи, а не от инструмента.
Мм. Верно, не указал зачем. Суть, хранение данных (сайт) и сбор статистики + биллинг, т.е. много мелких транзакций, и их пересчет. Понимаю что надо это дело разделять. Вот думаю что лучше использовать.
Евгений Кузнецов: Насколько много, трудно сказать сходу. Поскольку у меня такой проект впервые, знакомых компетентных в этом вопросе нет. На глаз, в начале планируется около 10к на биллиинг, и еще больше на статистику, в сутки и с последующим увеличением. Также по этим данным нужно выводить визуальную статистику, то есть строить графики и прочее. Тут думаю понятно.
А данные однотипные, но для каждой подсистемы свой формат.
Все это можно сравнить с банерной рекламой. Думаю от этого можно отталкиваться.
Поскольку пока таблицы будут умещаться в памяти проблем у всех БД не должно возникнуть, то я бы смотрел в сторону простоты масштабирования, и думаю выбирал между Postgres и Mongo (на одном проекте не плохо себя показала). И выбрал бы то, с чем лучше знаком.
Для себя вы должны тоже выбрать с чем больше знакомы и что сможете без особых затрат смаштабировать.
Пока будут в памяти, это. Но рано или поздно они в нее не будут помещаться и тут ждет сюрприз.
Вот тут встает дилемма. С Postgres вообще дел не имел, а с Монгой, только посмотреть что за зверь. И все же не хочется в будущем встревать с тормозами. Особенно если это выльется в смену СУБД.
Почему-то в голове сидит мысль, что mysql плохо масштабируется. Сам его использую для некрупных проектов. То, что покрупнее - Mongo. С postgres не работал, но слышал хорошие отзывы.
Constantine: И правильно не хочется. Потому что они все равно не работают (Монга в принципе не дает гарантий относительного порядка записи в разных коллекциях - а потому любые костыли остаются самоуспокоением)
Средний
Простой
