Как справиться с множественными подключениями к БД

Нужен совет.

Работаю над проектом наподобие Твиттера. Программная часть почти готова, и 1 ноября я собирался запустить его в работу, но решил повременить с этим, т.к. думаю перекроить архитектуру БД, и разнести все основные сервисы по отдельным базам. То есть чтобы на каждый сервис (профили юзеров, фотоаватары юзеров, блоги юзеров, форумы юзеров, чаты юзеров, конференции юзеров) была своя база данных.

Ни разу не пробовал реализовать это, вот советуюсь, как правильно это сделать. Все БД по идее будут располагаться на разных серверах, а пока денег нет на это - все будет на одном сервере. Насколько трудно для одного сервера будет, если на одной странице будет подключаться сразу 5-6 баз данных? Возможно, какие-то мануалы на русском языке почитать, или видео посмотреть какого-то умного докладчика...

Заранее хочу уточнить, что данные я кеширую в мемкеш на очень длительный срок, и запросы на чтение (SELECT) производятся крайне редко. Нагрузка происходит только при записи/перезаписи данных. Меня интересует проблемность единовременного множественного подключения и, желательно, снижение нагрузки с записи/перезаписи посредством очередей запросов.

Проект должен быть по дефолту крайне высоконагруженным. Работаю над подобным первый раз, поэтому по голове сильно не бейте.

Разносить БД на несколько суб-БД я, наверное, буду в любом случае, ибо считаю, что если, к примеру, в данный момент, происходит большая нагрузка на сервис блогов (очень много пишут и голосуют), и БД этого сервиса дошла до критической нагрузки, я искусственно притормаживаю этот сервис "Мы перегружены, подождите пару минут", а все остальные сервисы, БД которых чувствуют себя нормально, должны функционировать в обычном режиме.

Это для того, чтобы если вдруг один сервис перегружен, сайт продолжал работать и без него, а не отдавал полностью 404. Возможно, я ошибаюсь.

К тому же, даже если ставить лимит запросов на сервере 200 тыс/мин, для шести сервисов, это очень и очень мало, даже с учетом горизонтальной масштабируемости (не более 1 млн записей в каждой таблице). А так выходит, по 200 тыс запросов в минуту на каждый из 6 сервисов, что в 6 раз снижает нагрузку.

Это сугубо мое мнение. Я просто высказал свое видение реализации этого проекта. Еще раз повторяюсь, я в этом ***юга. Поправьте меня.

дим,до конца не дочитал,но с самого начала возник вопрос:ЗАЧЕМ?
Делай таблицы с префиксами,и всё.
dimalondon_fotoalbum_files
dimalondon_fotoalbum_settings
dimalondon_fotoalbum_something
dimalondon_posts_list
dimalondon_posts_comment
итд итп
если это ради снижения нагрузки,то имхо создание нескольких подключений куда более ресурсоёмко.

2. eGo Ржавчина в Зубах, если бы ты дочитал до конца 1 пост, там внизу написано, зачем. Меня больше интересует техническая часть, как правильно сделать это.

По сути, у меня, к примеру, в страницу/шаблон личной страницы аяксом вытягиваются данные из разных точек. В блок блога подтягивается кеш блога (соответственно, там же и будет соединение с БД блогов), в блок фотоаватара вытягиваются данные о фотках (там же и будет соединение с БД фотографий), и так далее по списку. Всего на этой странице выбираются данные от 4 модулей. Соответственно, будет 4 соединения. Вот вопрос, разумно ли...

А ещё попробуй спланировать что у каждого "сервиса" будет не одна БД, а несколько.
Хотя помоему тут уже изначально неправильный подход.
Надо что-бы скрипт сам изначально знал что записи с 1 до 10000 лежат на первом сервере, с 10001 по 20000 на втором и т.д.
И уже обращался к нужным (этакий шардинг). Только продумывать это всё надо хитро

4,вот это более грамотно

4. ShiftBHT, дык, я же говорил, что думаю разбивать таблицы по 1 миллиону записей на каждый сервер. Я не делал этого пока, потому что пока не припекло (до первого миллиона пока далеко, до полумиллиона тоже, это можно сделать позже, в процесе). А вот разбивать БД на несколько Суб-БД в процессе работы уже намного сложнее, поэтому спроектировать это надо заранее.

4. ShiftBHT, "скрипт" может и не знать что записи с 1 по 100000 лежат на первом сервере другие на втором и так далее, достаточно создать избыточность данных, но помоему серавно подход изначально какойто не правильный

7,так скрипт надо научить узнавать.

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

9. МегабиТ, недоступность определенных серверов решает репликация. Если недоступен какой-либо из серверов, в замен его обязан вступить в работу реплицирующий его сервер.