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

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

9. Как вообще реализуется шардинг на уровне серверов? Я как понимаю есть какой-то прозрачный механизм для этого

Добавлено через 01:28 сек.
10, тут всё сложнее чем ты думаешь...
Если он будет только на чтение, то проблем особых нет, а если он ещё и запросы на запись будет принимать, то возникнет рассинхронизация.
А связка master-master (взаимная синхронизация) не очень хорошо работает...

10. dima.london, а избыточность данных на серверах != реплекациям на серверах разве? и что мешает также брать данные с n по M на одном сервере (main), а с M по X брать с (slave) на который происходит репликация?

Добавлено через 02:44 сек.
php и mysql вобще под high-load не катят

11. ShiftBHT, я считаю, что при записи первого сообщения юзера, ID этого сообщения надо запоминать. Кроме того надо хранить в памяти ID последнего сообщения юзера. И от него отталкиваться при выборке всех его сообщений.

К примеру,
- первый ID=1250004 - значит выбор надо начинать со второго сервера (1250004/1млн = 1,25 что значит второй сервер)

- последний ID=2275404 - значит выбор надо заканчивать на третьем сервере (2275404/1млн = 2,27 что значит третий сервер)

Исходя их этого, данные надо выбирать из 2 и 3 сервера.

как-то так

13. dima.london, постоянно пересчитывать записи?

14. МегабиТ, почему? Только при выборе данных из БД. К примеру, срок кеша закончился, и его надо перекешировать. Я вынимаю из определенного места памяти IDы первого и последнего сообщения, подсчитываю, с какого по какой серверы хранятся данные, и выбираю. Чтобы не дергать ненужные сервера. К примеру, серверов 10, а после подсчета получается, что данные хранятся с 3 по 7 сервера. Вот из этих 5 и делать выборку и формировать кеш из массива полученных данных.
Все просто.

15. dima.london, мне кажется что в реальных условиях твое решения окажется либо не эффективным либо не работо способным вобще

16. МегабиТ, а как те еще предлагаешь? При каждом перекешировании перебирать все сервера? Посмотри на фейсбук. У них 4 датацентра. Это рехнуться можно, пока выберешь данные со всех серверов.
Ну, максимум - это можно у каждого юзера хранить массив серверов (типа 1, 2, 5, 17, 24), и при записи нового сообщения узнавать, в какой сервер пишется сообщение и перебирать массив серверов. Если сервер в массиве не найден - дописывать его туда. А при выборе сообщений просто перебирать этот массив и брать данные из тех серверов, что записаны в массив. Хз.

15. dima.london, http://habrahabr.ru/blogs/mysql/130999/

18. МегабиТ, гг Я на ютьюбе сегодня смотрел доклад этого Зайцева. Ущербный тип. Много воды льет не по делу.

17. dima.london, над таким вопросом нужно посидеть не день и не неделю, попробывать не один вариант, для себя как реализацию я вижу примерно такую, перенсти часть нагрузки на клиента, негенерировать никаких страниц вобще на сервере а только массивы данных, статику вынести на отдельный сервер, часть данных(до состояния изменения) хранить у пользователя в Storage(HTML5 DOM Storage или SQLLite), только придется отказаться от старых браузеров IE < 9, ну и собрать всю страницу у клиента по кускам