VBart

Посмотрите на книжку по CouchDB, не знаю, насколько она способна «сдвинуть мышление», но мне показалось, что неплоха. К тому же бесплатная: guide.couchdb.org/

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

Остальные ваши доводы, не касающиеся баз данных, тоже вызывают уйму вопросов. Во-первых, если у вас уже есть аппаратный балансировщик нагрузки, то зачем за ним еще 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