Каковы некоторые из лучших инструментов/стратегий для кэширования средних/больших наборов данных в PHP?

У меня есть ваше среднее приложение PHP (работает на сервере Windows) с формами и сетями данных/списками, а некоторые из них требуют выполнения довольно сложных запросов, которые я оптимизировал до максимума, и я сомневаюсь, что тонна, которая может быть выполнена чтобы заставить их работать намного быстрее. У меня также нет возможности изменить структуру базы данных, учитывая другие процессы, зависящие от структуры. Так как кэширование на самом деле не очень много используется в приложении, это, кажется, следующий логический шаг.

Недавно я прочитал о кэшировании поколений и разработал достойный механизм для автоматизации кэширования запросов в моих приложениях. Моя проблема теперь в том, что я столкнулся с ограничениями по размеру для обоих вариантов, которые оказались логичными. WinCache ограничивает вас до 85 МБ, что не собирается сокращать его, а memcached ограничивает элемент до 1 МБ, что мало похоже на то, что у вас есть запрос, который возвращает довольно большое количество записей и имеет много полей. ОК, точнее, похоже, что memcached теперь позволяет установить более крупный размер, но тот факт, что он по умолчанию равен 1 Мбайт и используется только для этого, позволяет мне подвергнуть сомнению то, что я пытаюсь сделать.

Максимальное количество записей, которые моя сетка разрешает возвращать сразу, составляет 1000 записей, поэтому максимальное количество записей, которые могут быть сохранены в кеше (поля на запись различаются, конечно). Я знаю, что огромное количество пользователей, вероятно, означало бы, что кеш будет заполняться очень быстро, но количество одновременных пользователей обычно невелико и из того, что я читал, если memcached исчерпал память, он просто избавится от самого старого кешированные элементы, поэтому я не вижу большого недостатка с хранением больших наборов данных, если операция не очень дорогая, но из того, что я прочитал, похоже, не так.

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

Ответ 1

Если у вас нет веских причин отправлять эти данные по проводке в кеш, не.

Если это вообще возможно, используйте локальное решение для кэширования процессов, такое как APC (u) или YAC (YAC - чрезвычайно умное программное обеспечение и может быть нестабильным).

Когда APC (u) или wincache фактически копируют массивы и скаляры в и из разделяемой памяти, они делают это побитовое, байт за байтом, они не сериализуют или иным образом не изменяют формат данных, в сочетании с тем, что есть 0 сетевых издержек, локальные решения кэширования, такие как APC (u), намного быстрее, чем что-либо вроде memcached или redis.

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

Конечно, если у вас есть веская причина для отправки по проводам, то это довольно бесполезная информация;)

Ответ 2

Поскольку ваше веб-приложение запускает множество сложных запросов, которые возвращают большой набор данных, вам обязательно нужно посмотреть на кеширование данных.

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

Ответ 3

Было бы лучше, если memcached находится на другом сервере, чем база данных. Таким образом, вы будете балансировать нагрузку с двух разных мест. Таким образом, не кэшированные результаты будут поступать из сервера базы данных напрямую, а кэшированные - из другого.

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

Ответ 4

Есть много вариантов, с которыми вы можете пойти:

1) Если вы имеете дело с большим количеством запросов, то использование MASTER/SLAVE DB ARCHITECTURE будет иметь большую помощь. Выбирать запросы можно на SLAVE strong > DB, что уменьшит огромную перегрузку в MASTER DB.

2) Использование SPHINX, безусловно, поможет вам повысить скорость восстановления данных. Вы можете прочитать об этом в статье wikipedia WIKI-Sphinx.

3) Вы также можете использовать сервер REDIS, который также поддерживает репликацию Master/Slave. СТАТЬЯ REDIS

Это также зависит от других факторов, от того, как вы нормализуете структуры таблиц, индексируете, выполняете объединения.

ПРИМЕЧАНИЕ.. Ненужное использование JOINS обычно исключается. Вы можете прочитать об этом здесь IBM-Избегайте ненужных внешних соединений

Надеюсь, что это поможет

Ответ 5

Без внесения больших изменений в ваше приложение у вас есть еще несколько вариантов:

Вы можете кэшировать весь интерфейс. Просто создайте задание, которое выполняется каждые 5 минут (зависит от изменения данных для вашего приложения) и создает html файлы в каталоге html. И когда клиенты запрашивают URL-адрес вашего сервера, используйте html файл. Это может быть очень удобно.
Использование nginx будет хорошим выбором.
Есть несколько аппаратных средств, которые вы можете добавить в свою сеть, которые могут без особого труда кэшировать действительно большой объем данных. Nginx - это программное решение, а netscaler - аппаратное решение. Похоже, citrix предлагает отличные решения.