Нужен mysql-сервер способный обрабатывать огромное кол-во запросов. Сколько именно запросов - не знаю, но очень много. Интересует, как подобное лучше организовать. Как я понимаю тут два решения: взять либо один очень мощный сервер либо сделать кластерную систему, на которой база была бы распределена по серверам. Интересно знать какие преимущества и недостатки у этих решений.

Есть сервера многопроцессорные(4хQuad-Core Intel® Xeon® X7350, 2.93GHz, 8MB L2 cache) и с большим кол-вом RAM. Например: 128Гб оперативки. Понятно, что стоимость такого сервера около 20 000 евро, но быть может это более лучше решение чем использовать кластер ?

примет такого сервера: http://configure2.euro.dell.com/dellstore/...;sbc=pedge_r900

P.S. лизинг такого сервера кстати недорог. Около 500 евро в месяц.

Передо мной тоже стоит подобная задачка (огромное количество запросов к базе).
Но я как-то даже и не знаю, стоит ли в этом случае юзать mysql... Присматриваюсь к oracle, ибо критична еще и надежность хранения данных.

Вы какую-нибудь информацию нарыли?

mysql вполне подходит я считаю.

Мог бы посоветовать несколько серверов с репликацией, но это все же смотря по ситуации, в некоторых случаях это может быть лучший вариант, а в некоторых может и нет 

Какова общая архитектура?

Если тот самый наиболее безотказный вариант, 3-хуровневое "прокси/балансер - груда (возможно, груда в будущем) машин, занимающихся бизнес-логикой - общая помойка данных", то тут важно не перекладывать бизнес-логику на базу, и думать скорее о том, как с максимальной производительностью слинковать 2й и 3й уровень. И еще не связываться с аппаратно-зависимыми вещами (т.е. поставить RISC-кластер под AIXом или SMPшную альфу/спарк под солярой, к примеру, конечно, круто, но это может помешать в дальнейшем). Но на подобной архитектуре живет тот же гугол, а там весьма умные ребята работают.

База объемная? Что по степени готовности? На 128ГБ оперативы все можно держать на heap (или, возможно, нельзя, зависит от объемов базы). Если есть уверенность, что не будет нештатной остановки сервера. Можно еще подстраховаться, выложив все на MFS и наладив rc-скрипты для подъема и сохранения при шатдауне. Ну и доп. mysqld, живущий в chroot / BSD jail и принимающий репликации, естественно. В случае с heap / mfs огромный плюс - производительность. Минус - стабильность в случае нештатного отключения.

Или копать в сторону SSD накопителей, как другой вариант. Только дорогие они.

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

К примеру, если есть таблицы, которые не придется друг с другом связывать (статистику посещений и пароли пользователей вряд-ли придется джойнить), то хорошей идеей бы было вынести их в разные базы, на разные сервера. Для таблиц с очень частым селектом и менее критичным апдейтом(к примеру, настройки пользователя, которые необходимы при каждом запросе) вполне могла бы подойти простая репликация Master -> Slave. А для таблиц с огромным числом строк и не требующих сложного поиска (хронология, комментарии, логи, etc) идеально подошла бы сегментация.

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


Считаю, что это плохая идея. 
1. Никакой масштабируемости
2. Одно слабое звено тут может послужить тормозом всей системы.
3. В случае проблемы с сервером, ляжет вся система.
4. Скорее всего это выйдет дороже.


Да вы экстремал!  Даже если совершенно безразлична сохранность данных, все равно у таблиц HEAP есть ограничения (к примеру нельзя использовать столбцы типа TEXT, BLOB, etc). И потом чем не устраивает связка InnoDB + Memcache?

И еще можно работать только с рядами фиксированной длины. Но производительность дает дикую, пару раз приходилось сие пользовать.

Все зависит от архитектуры.