Какой кэш БД лучше всего использовать для этого приложения?

Question

Я на 70% прошел через разработку веб-приложения, которое содержит, по сути, крупномасштабные данные, насчитывающие около 50 000 строк.

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

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

На данный момент каждое фильтрующее действие (всего) занимает в среднем 250-350 мс. Например: -

Пользователь берет один конец визуального слайдера, перетаскивает его внутрь, когда он / она отпускает запрос на фильтрацию диапазона, который динамически соединяется моим PHP-кодом, и результаты возвращаются в виде ответа JSON. Общее время, от которого пользователь отпускает ползунок до тех пор, пока пользователь не получит все данные и таблица не будет перерисована, в среднем составляет 250-350 мс.

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

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

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

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

Огромное спасибо всем, кто откликнулся.

РЕДАКТИРОВАТЬ: я должен упомянуть, что база данных MySQL. Сам сайт работает на Apache с прокси nginx. Но этот вопрос связан исключительно с ускорением и сокращением обращений к базе данных, которых много.

Я также должен добавить, что указанное время прохождения туда и обратно 250-350 мс полностью удалено. Как с удаленного компьютера, получающего доступ к веб-сайту. Время включает в себя поиск DNS, поиск данных и т. Д.

Answer 1

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

По сути, у вас есть три варианта:

1. Работайте с большим количеством запросов к вашей базе данных, оптимизируйте базу данных с помощью соответствующих индексов и нормализуйте данные, насколько это возможно.Убедитесь, что вы избегаете обычных ошибок производительности при построении запросов (например, множество OR в предложениях ON или WHERE).Предоставьте представления для гибридных запросов и т. Д.
2. Кэшируйте общие запросы в memcached или аналогичных, то есть без некоторых или всех фильтров.И примените фильтры на уровне приложений.
3. Реализуйте сервер индекса поиска, как SOLR.

Я бы порекомендовал вам сделать первое.Время прохождения туда-обратно 250 ~ 300 мс звучит немного выше даже для сложных запросов, и кажется, что вы можете получить много, просто улучшив то, что у вас уже есть на этом этапе.Для гораздо более высоких рабочих нагрузок я бы предложил решение № 3, оно поможет вам достичь того, что вы пытаетесь сделать, будучи лучшим в обработке множества различных запросов.

Answer 2

1. Вы можете эффективно использовать кэши, только если время от времени выполняете один и тот же запрос.
2. Хороший способ работы с кешами memcache - определить ключ, соответствующий функции, которая его вызывает. Например, если модель с именем UserModel имеет метод getUser($userID), вы можете кэшировать всех пользователей как USER_id. Для более продвинутых функций (Model2::largerFunction($arg1, $arg2)) вы можете просто использовать MODEL2_arg1_arg2 - это позволит легко избежать конфликтов пространства имен.
3. Для полнотекстового поиска используйте индексатор поиска, такой как Sphinx или Apache Lucene. Они значительно улучшают ваши запросы (я смог выполнить полнотекстовый поиск по таблице записей с 10 миллионами на процессоре с частотой 1,6 ГГц, менее чем за 500 мс).

Answer 3

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