spry

SimpleCMS :)

По-моему, в этом случае будет проще написать свою. Я делал подобную мини-CMS для некоторых простых сайтов-визиток: создавал элементарную базу с контентом (два поля — id и content, можно и файлами обойтись), подключал редактор (к примеру, TinyMCE или любой, который больше нравится) и создавал один шаблон вывода для всех страниц сайта. Вот эта CMS, кстати, очень популярна на Западе. Не знаю, есть ли у нас подобные аналоги, не искал.

Судя по тексту Вы НЕ владеете доменом. :)
Кто регистратор? Какая зона?

Остальные ваши доводы, не касающиеся баз данных, тоже вызывают уйму вопросов. Во-первых, если у вас уже есть аппаратный балансировщик нагрузки, то зачем за ним еще nginx для того же самого? Зачем это нагромождение из http-серверов? Пропускание трафика через эту ёлку из веб-серверов скорости не только не добавляет, а наоборот. Почему бы nginx не балансировать сразу непосредственно application-сервера? Зачем вам апач? Вы же не хостингом торгуете, я так понял, где уже будет играть основная прелесть апача и его маленький дополнительный тормоз — .htaccess-файлы. Все ваши фразы про кэширование и про наборы — memcache также не имеют никакого смысла без четкого понимания, что кэшировать, когда и как, по какому принципу. Кэшировать бывает и даже вредно, и уж точно всегда трудоемко. К нему прибегают, во-первых, когда оно реально возможно, во-вторых, когда реально необходимо и способно что-то существенно ускорить.

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

Значительную роль в high-load проекте играет возможность легкой простой поддержки этого большого парка, легкость конфигурирования новых машин, встраивания их в пул, автоматическое выключение и переконфигурация в случае выхода из строя чего-либо, а следовательно быстрая диагностика, мониторинг. Эти вопросы вы вообще никак не охватили, однако при этом нагородили довольно сложную систему. То же вертикальное масштабирования не обязательно заведомо тупиковый и ложный путь, а для кучи проектов, будет даже предпочтительнее.

Зато упомянули некую базу данных на графах, я вообще не слышал, чтобы они имели сколь угодно широкое использование в веб-проектах, в том числе и высоконагруженных. Как вы ее собираетесь использовать и масштабировать? Тоже возникает куча вопросов.

У вас в вопросе написано «теория», а далее идет изложение каких-то практических фактов, причем очень отдаленно. Как уже тут было выше сказано, у вас кардинально не верный подход.

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

Никто вам не сможет помочь в данном случае по двум причинам:
1) Вы не изложили во всех технических подробностях и деталях свой проект. Про фотки, соц. сеть и прочее — этого не достаточно, нужно многостраничное подробное толковое описание всех требуемых функций, хотя бы… я уж не говорю, что хорошо бы конкретизировать и ресурсы, а так же прикинуть нагрузки.
2) Это не делается вот так вот на коленке. Толковый подробный анализ может занимать несколько месяцев, и разумеется бесплатно этим никто не будет заниматься. Есть некие теоретические основы, но они настолько теоретические, что вы их даже не изложили выше. Количество DNS-серверов, AA-записей, nginx-сы, php, устройство БД и т. д. — это все уже практическая область, которая сильно зависит от задачи. Вы можете реализовать все, что вы написали, и получить при этом громоздкое неповоротливое плохо масштабируемое приложение, требующее при этом огромных затрат. Исходя из того, что вы написали, могу лишь посоветовать не заниматься этим, ибо у вас изначально уже неверный подход и неверные представления. И любые практические советы, которые вам тут написали, или еще напишут — не более чем личный ничем не подкрепленный опыт, в решении собственных (а не ваших) задач, которые могут кардинально отличаться.

Могу лишь поделится советом, как делаю я при выборе конкретного технического решения, по шагам:
1) Сбор требований. Важно собрать и выявить как можно больше требований определяемых конкретной задачей по отношении к конкретному вопросу. Например, все требования к хранению данных такого-то сервиса.
2) Отобрать как можно большее количество вариантов с помощью которых задача в принципе решаема, а затем исключить из них те, которые заведомо не вписываются в требования, оставив только те, что наиболее им удовлетворяют (бывает так что всем требованиям в принципе невозможно удовлетворить).
3) Техническое решение — это всегда компромисс. Из оставшихся вариантов надо выбрать наиболее подходящий, зачастую для этого нужно провести сравнительное тестирование (причем именно свое собственное, на тестах так или иначе моделирующих вашу задачу). Если результат вас все равно не устроил, вероятно вам стоит пересмотреть требования или разбить задачу на несколько, по возможности. В любом случае, это отсылает вас к корректированию пункта 1.

Бонус трек 1: KISS
Бонус трек 2: One size never fits all

Загрузитесь с hirens boot cd и попробуйте восстановить раздел. Утилитами Active Partition Recovery или TestDisk из раздела Recovery Tools.

В моем случае проект был написан «абы-как». Точнее, довольно грамотно, но без каких-либо мыслей о том, что пользователей станет много, и придется как-то масштабировать. Более-менее красивый код, куча таблиц, связанных друг-с-другом, то есть чуть ли не десятки JOIN'ов. Кэширование не использовалось вообще.

Все работало (и работает) на 3-х серверах: база PostgreSQL, nginx для статики, nginx с gunicorn для собственно приложения.

Первые два года этого хватало, но росло количество пользователей и фич, в итоге, приходится периодически садиться и переписывать куски кода: денормализовывать базу, чтобы избежать JOIN'ов и поисков в дополнительных справочных таблицах, пытаться воткнуть кэширование (самая большая головная боль — кэширование надо предусматривать в самом начале и очень-очень хорошо продумывать), и т.д. и т.п.

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

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

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