Присвойте CSS определенному элементу

Я - ведущий разработчик на сайте с по 15M пользователи. У нас было очень мало масштабирующихся проблем, потому что мы запланировали его РАНО и масштабируемый глубокомысленно. Вот некоторые стратегии, которые я могу предложить на основе своего опыта.

СХЕМА Прежде всего, денормализуйте свои схемы. Это означает, что, а не иметь несколько реляционных таблиц, необходимо вместо этого решить иметь одну большую таблицу. В целом соединения являются тратой драгоценных ресурсов DB, потому что выполнение нескольких готовится и дисковый ввод-вывод записей сопоставления. Избегайте их, когда Вы будете мочь.

компромисс здесь - то, что Вы будете хранить/вытягивать избыточные данные, но это приемлемо, потому что пропускная способность данных и внутриклетки является очень дешевой (большие диски), тогда как несколько готовятся, ввод-вывод более дорогие порядки величины (больше серверов).

ИНДЕКСАЦИЯ Удостоверяется, что Ваши запросы используют по крайней мере один индекс. Остерегайтесь, хотя, которого индексы будут стоить Вам, если Вы запишете или часто обновлять. Существуют некоторые экспериментальные приемы для предотвращения этого.

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

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

КЭШИРОВАНИЕ я настоятельно рекомендую Memcached. Это было доказано крупнейшими плеерами на стеке PHP (Facebook) и очень гибко. Существует два метода к выполнению этого, каждый кэшируется в Вашем уровне DB, другой кэшируется в Вашем слое бизнес-логики.

параметр слоя DB потребовал бы кэширования результата запросов, полученных от DB. Можно хешировать SQL-запрос с помощью md5 () и использование что как ключ поиска прежде, чем идти в базу данных. Позитивный аспект к этому - то, что довольно легко реализовать. Оборотная сторона (в зависимости от реализации) - то, что Вы теряете гибкость, потому что Вы рассматриваете все кэширование того же относительно истечения кэша.

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

репликация SHARDING ДАННЫХ только получает Вас до сих пор. Раньше, чем Вы ожидают, Ваши записи станут узким местом. Для компенсации удостоверьтесь, что поддерживали данные sharding рано как возможные. Вы, вероятно, захотите застрелиться позже, если Вы не сделаете.

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

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

ОФЛАЙНОВАЯ ОБРАБОТКА не заставляет пользователя ожидать Вашего бэкенда, если они не имеют к. Создайте очередь заданий и переместите любую обработку, что Вы можете офлайн, делание ее отделяется от запроса пользователя.