AAronСтранно все это.
1. Вместо того, чтобы запустить проект для много меньшей нагрузки и начать зарабатывать деньги, автор сотрясает воздух.Деньги поначалу поступают медленнее, чем растет нагрузка. Если стартовать не имея запаса прочности, то весь проект будет провален из-за того, что элементарно поляжет под нагрузкой и дискредитирует себя в глазах своих пользователей. Но тут же на это место придут другие, как бывает всегда. Поэтому в данном случае нужно сначала проработать ядро системы на опережение (и в бизнесе, так и в технологии) и уже затем запускать сервис. Я видел, как погибали интересные бизнесы, которые не справились с нагрузкой - и на их место приходили другие ребята. Представляете как было обидно тем, первым?

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

AAron3. На мой взгляд, количество запросов в 1М/с необосновано.Сейчас - согашусь, да. Но нужно думать о будущем, если ты в проекте участвуешь не просто формально, за зарплату.

ggvесли у вас нет фиксированной линии - то это не значит, что пакетная коммутация окончательно победила :)Если сами телефонные компании гонят long-distance трафик через IP, то даже не смотря на то, что у "традиционных" абонентов пока что еще стоят обычные телефоны - это все равно говорит о том, что пакетная коммуникация победила. :) Зачастую уже дешевле платить за IP, чем за классическую fixed телефонную линию.

Anton DemidovКстати, было бы интересно посмотреть на аналогичное сравнение от IBM, может кто видел - киньте линк, плиз.
Что нашел на их сайте:
www-306.ibm.com/software/data/db2/benchmarks/111704.html
www-306.ibm.com/software/data/highlights/scalecluster.html