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

и на данный момент повесткой дня БД.

простейший вариант в данном случае это репликация, НО имхо это самый последний уровень абстракции, ибо данный вариант плох тем что на самом деле львиная часть каждого отдельного сервера уходит не перелопачивание фиговой кучи данных (причем одной и той же)
и зародилась мысля (а точнее по некоему примеру твитера) изначально готовить к резнесению некие субъекты (таблицы) на разные сервера, так как к примеру разработчики твитера часть работы (join-ы) переложили на программную часть

ну а уже каждый конечный сервер можно подвергнуть при необходимости репликации

дык вот может у кого есть какой нить опыт в подобном?

на данный момент "сложность" вижу:
1) в том как определяться (красиво) к какому серверу обращаться за конкретными данными.
2) насколько избавляться от join-ов, в смысле что можно оставлять на отдельном сервер.

зачем?

что "зачем?"?
вся эта котовасия? для возможности распределения нагрузки, для избежания головняка в будущем, для оптимизации работы серверов.

или говоря проще стелю себе большой ком соломы.

На все случаи жизни не перестрахуешься
Оптимизировать нужно конкретные запросы к бд и куски кода
Распределять какую именно нагрузку вы планируете, вы хорошо себе представляете себе профиль этой нагрузки? Будет у вас больше записей или апдейтов, какого рода связи в таблицах планируются и примерные размеры этимх самый таблиц ? Невозможно улучшать то - не знаю что

Есть некие вещи, до которых доходишь с опытом, но у каждого они свои. Я не делаю никогда триггеры в базе данных, не использую связи таблиц на уровне бд, не использую NOW() и тд в запросах: апдейчу только инкрементально, не оптимизирую заранее, не пихаю ООП везде, где попало, не использую фреймворки в нагруженных проектах ... из остального уже зависит от обстоятельств

вопрос оптимизации скриптов, базы, ...
не рассматривается,
ибо это в априори, все скрипты все запросы на момент расширения уже оптимизированы.

вопрос о том что там дальше.

Извините что отхожу от темы, но все же интересно.

Вот про это можно по подробнее.
Как вы делаете, если не на фреймворке?
Роутинг должен быть, должен.
Единая точка входа, так называемый FrontController.
Используете ли вы MVC (Разделение логики от отображение)?
Просто все ровно как бы фреймворк мини получается нет?

vanicon, все очень просто, почти любой фреймверк расчитан на общие ситуации, а следовательно в нем множество "блоков" которые в конкретном случае приводят лишь к замедлению.

vanicon, все что вы описали - библиотеки из пары классов

Все ясно, просто "не использую фреймворки в нагруженных проектах" не совсем правильно, ведь как бы фреймворк есть, просто свой, самый простейший, там роутинг, mvc, класс для работы с бд, работа с view и тд...
Ну а по теме, насчет как определить к какому серверу за данными обращаться, думаю стоит для этого использовать nosql бд, типа redis, ну это так для размышлений...

совсем правильно.

роутинг - 2 класса
mvc - архитектура, то, как ты делишь свое приложение на логические блоки ... доп кода не требует
класс для работы с бд - PDO
работа с view - не очень понимаю, что имеется ввиду

итого, если 2 класса ты называешь фреймворком - ОК, но я с тобой не согласен

бред какой-то ... как связан роутинг запросов между нодами шард с nosql? оО

Ну там вовсе не 2 класса, но считать я не буду, суть не в этом.
Просто с моей точки зрения библиотека, это тупо набор классов/функций для решения определенных задач...
А сама структура приложения, должна же быть, как я ранее писал 1 точка входа и тд

Это связано с mvc.

Если я правильно понял проблему автора, то проблема в том что нужно знать на каком сервере(я имею ввиду mysql) лежат какие-либо данные...
Я предлагаю решения типа что-то этого:
К примеру у нас 3 сервера, 2 сервера mysql, 1 сервер redis
Сервер на котором стоит redis будет знать где и какие данные лежат...
Посылается запрос на сервер с редисом, он дает инфу где лежат эти данные к которым идет запрос, а дальше уже делать запрос к нужному mysql серверу.
Конечно можно использовать вместо redis и любую другую бд, хоть тот же mysql, но как бы этот роутинг не стал бы "узким горлышком".
А redis за счет хранения данных в ram сможет достаточно быстро этим заниматься...
Ну вот как-то так...

самопальные кластеры и балансировщики нагрузки - полная чушь
для этого уже есть готовые решения, просто для таких систем не пишут на mysql и PHP.


если будет достаточно ram для кеша, mysql будет делать это не менее быстро.

Полностью поддерживаю!
Я слышал что есть какой-то там спец mysql cluster
различные nosql решения, к примеру mongodb....
Использовать ту бд которая может расширяться без костылей и тд, но на начальном этапе этого ничего и не нужно...

Ну а почему на php не пишут?
это только web морда, а ее можно и на пыхе сделать.

Но здесь как бы не кеш (кеш - типа временные данные), а это в данной ситуации не является кешом.
Насчет быстродействии mysql я сомневаюсь, потому что насколько я знаю и проверял сам redis на несколько порядков быстрее работает...

web морда - это HTML

А серверную часть для таких делов пишут на яве - J2EE сервера приложений кластеризуются из каропки.
То же касается промышленных серверов БД.
А балансировщики вообще ставятся апаратные какие нибудь Cisco



обычно нужна работа с данными посложнее чем просто ключ-значение. А на более менее сложных выборках NoSQL БД сразу проседают.