Для чего я стоил, я имел дело с некоторыми более крупными системами, и было собственное приложение, которое собирало запросы с серверов для использования в общих целях для компании.
например. select * from t1 было преобразовано в:
select * from db1.t1
union
select * from db2.t2
и т.д.
Основная проблема состоит в том, что если вы столкнетесь с межсерверными объединениями, в больших системах с миллионами строк это может сильно ударить по сети и занять много времени для обработки запросов.
Скажем, например, что вы проводите анализ сети и вам нужно объединить таблицы, чтобы определить «ссылки» атрибутов пользователей.
Вы можете получить странные запросы, которые выглядят примерно так (простите за синтаксис):
select db1.user1.boss, db1.user1.name, db2.user.name db2.user.boss from db1 inner join on db1.user.name = db2.user.name
(например, получить начальника человека и его начальника или друга друзей и т. Д.)
Это может быть огромным PITA, когда вы хотите получить хорошие данные для выполнения цепных типов запросов, но для простых статистических данных, таких как суммы, средние значения и т. Д., Для этих ребят лучше всего работал ночной запрос с агрегированной статистикой. в таблицу на каждом сервере (например, nightlystats) ..
например select countif(user.datecreated>yesterday,1,0) as dailyregistered, sumif(user.quitdate)... into (the new nightly record).
Это сделало ежедневную статистику довольно простой, так как подсчитывает, что вы просто суммируете общий столбец, среднее значение, которое вы умножаете на значение отдельного сервера, на общее количество серверов, затем делите на общее количество и т. Д., И получаете довольно быструю панель инструментов. просмотр на высоком уровне.
Мы закончили с индексированием и оптимизацией, и такие приемы, как хранение небольших локальных таблиц часто используемой информации, помогли ускорить запросы.
Для более крупных запросов парень из базы данных просто сбросил полную резервную копию системы в резервную систему, и мы использовали бы ее для локальной обработки в течение дня, чтобы не слишком сильно ударить по сети.
Есть несколько хитростей, которые могут уменьшить это, например, использование общих небольших таблиц (например, основных таблиц для пользователей и т. Д. Без изменения данных и т. Д.), Чтобы вам не приходилось тратить время на их сбор.
Другая вещь, которая действительно полезна на практике, - это объединение сумм и итогов для простых запросов в ночные таблицы.
Последнее, что интересует, заключается в том, что для обхода проблемы bw нужно было запрограммировать тайм-аут «отсрочки» во внутреннем «агрегаторе запросов», то есть, когда он получал время ответа от выборки записи, если время начало откладываться, он будет запрашивать меньше записей и добавлять задержку к запросам, которые он запрашивал (поскольку он сообщал и не чувствителен ко времени, это работало нормально)
Есть несколько SQL, которые автоматически масштабируются, и я недавно прочитал статью об инструментах (но не php), которая сделает кое-что для вас. Я думаю, что они были связаны с провайдерами облачных VM.
В этой ветке также представлены некоторые инструменты и мысли: Подходы к шардингу MySQL?
Если NoSQL является опцией, вы можете рассмотреть все системы БД, прежде чем идти по этому пути.
Подход NoSQL может быть легче масштабировать в зависимости от того, что вы ищете.