100 000 даже посетителей в день - это, при обычном 5-10 страниц на посетителя - дает около 20 кликов в секунду, в пиковые моменты нужно уметь обрабатывать до 200 страниц (опять-таки, если не планируются маркетинговые всплески, там может быть и до двух порядков разница и выше).

Для приличных БД такая нагрузка, в общем, не проблема - тем более что реально ее можно будет распределить по нескольким физическим серверам. Но напрямую на MySQL - уже напряжно. Чем определен выбор БД?

В любом случае, большей проблемой будет не столько нагрузка на БД (которую в таких решениях можно легко уменьшать), сколько обеспечение нормальной надежности.

В общем, если опыта нет - нужно консультанта искать.

Ага, на MySQL. Т.е. на нескольких кластерах MySQL+memcached+куча скриптов и хитростей, что бы это все работало. Полторы сотни серверов в сумме, кажется - и не так уж и много запросов на LiveJournal в секунду, для такого количества железа и простой логики.
Почитай на http://poorbuthappy.com/ease/archives/2007/04/29/3616/the-top-10-presentation-on-scaling-websites-twitter-flickr-bloglines-vox-and-more,

Там показано, как это возникало, какие данные по производительности MySQL и т.п.
И вообще хороший ресурс.

Гм, а ты все из презентации понял?
Для меня осталось загадкой, что именно они подразумевают под отказом от транзакций и отдельным демоном, которые решает конфликты?
Все остальное я, так или иначе, и сам использовал, а вот это оказалось загадкой.

P.S. И нафиг им оракл, на их задачи блокировочник лучше ложится (впрочем, для сильно нагруженных систем и базы данных как хранилища это почти всегда так).

P.P.S А еще ebay - это замечательная иллюстрация к тому, что архитектуру даже очень боевой системы можно и нужно радикально перестраивать.

На 22ой.
По крайней мере я именно так расшифровал все, что касается управлениями failover для бизнес-транзакций (которых, на самом деле, нет).