Вячеслав СкорыхПланируется разработать некое Web-приложение. Предполагаемая пиковая нагрузка - 60 запросов в секунду, 5 млн. запросов в сутки. Подавляющее большинство запросов должны быть запросами на вставку данных. Остальные запросы - сбор статистики в том или ином разрезе за диапазон дат, с частым использованием операторов sum()...group by...

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

Использование XP пока не планируется. Крайне желательно наличие средств репликации БД, горячего резервного копирования. В идеале - хорошо бы иметь средства кластеризации.

На данный момент заказчик отказался от технологий Microsoft из-за стоимости, Oracle, разумеется, тоже отпадает, Interbase и его клоны я рассматривать не хочу, потому как быстрые вставки - не для этой СУБД. На руках остаются бесплатные PostgreSQL и MySQL. Вопрос: какая из данных СУБД лучше подходит под мои требования?
Ну во первых мне не понятно, почему Вы хотите вместо вставки записей использовать их обновление. По моему в любой СУБД вставка работает быстрее, чем обновление.
Во вторых слишком мало информации. Возникает целая серия вопросов:
1. Кол-во добавляемой информации в сутки
2. Ширина таблиц, в которых идет частое добавление/обновление информации
3. Есть ли в таких таблицах поля с плавающей длинной (тот же varchar) или длинные поля (Text, Blob, ...)
4. Длительность транзакций (кол-во вставляемых/изменяемых в пределах транзакции записей)
5. Уровень изоляции для аналитических запросов
6. Селективность таких запросов (хотя бы в процентах от всего кол-ва информации)
7. Период хранения информации
8. Планируемая конфигурация аппаратных средств
9. Требования к масштабируемости
10. Требования к надежности
11. Примерное кол-во постоянных активных сессий
12. Требования к платформе ОС и администрированию
13. Требования к ценовой политике СУБД

Вот примерный список вопросов, который сразу в голову приходит. Ответьте на все вопросы, появятся уточняющие вопросы, напишите их себе, снова ответьте, получите список требований на обоснование выбора платформы. По нему составьте тестовое задание для различных, подходящих под условия СУБД и прогоните его. Если останется парочка кандидатов, с примерно равными балами, идете их форумы и начинаете читать топики с проблемами и ответы как их обходят.

Гы - все это конечно по научному, если действительно серьезно подходить к делу. А если не по научному и с ограниченным бюджетом (а то и с надеждой на халявную СУБД), берете что знаете или что легко учиться и понимается ... и вперед и с песнями, а там как масть пойдет.

P.S. Будет интерес, включите в тестовый список СУБД Sybase ASA 9.0.2, раз уж у Вас денег мало, а много хочется. Почему ... почитайте здесь .

авторВаш список вызывает самые разнообразные эмоции. В нем есть вопросы, на которые я косвенно уже ответил (если PostgreSQL - то это явно не Windows, а при 60 запросах в секунду не может быть и речи о длинных транзакциях, о кластерах я тоже заикнулся), есть, на мой взгляд, второстепенные, есть и такие, на которые невозможно ответить однозначно.
Я задал серию взаимосвязанных вопросов, их нельзя отделить один от другого. "Косвенно" ответив только на пару вопросов, Вы не приближаетесь к оптимальному решению поставленной задачи, так как они не имеют по отдельности при выборе СУБД большой пользы.

авторПозже я смогу это сделать. Но предварительные рекомендации должен дать сейчас, и довольно быстро.
Быстро - это как ? Сегодня, завтра или вчера ? А может все таки лучше найти недельку, написать типовой ANSI-SQL тест и для каждой предварительно подходящей СУБД сделать серию тестов хотя бы на скорость вставки, выполнения запросов на определенном кол-ве активных сессий ?

авторЯ просто ожидал отзывов типа "У нас база прирастает на 2млн. записей в день на таком-то железе и особых проблем нет". Ну или ссылки на какие-то тесты производительности, success story и т.п.
Я могу за любую СУБД ответить, что там база прирастает на 2 млн записей в день и никаких проблем :) Только окажется что в каждом случае разная задача, разные условия, разная реализация, большой уровень профессионализма того, кто ее проектировал. И что с этого можно будет выбрать ?

Резюме: я так понимаю Вы уже остановились на выборе 2 СУБД - Postgre или MySQL. Ну дык поройте по их форумам, задайте в каждом из них этот вопрос, почитайте у кого какие проблемы были с такими нагрузками. Здесь окромя флейма ничего путного не получится.