База данных и обработка на стороне сервера

Question

В настоящее время у меня есть 2000 записей в базе данных postgresql, которые обновляются каждую минуту и ​​которые фильтруются с помощью оператора SQL.Может существовать до 1000 различных комбинаций фильтров, и каждую минуту можно вызывать около 500 различных фильтров.В настоящее время ответы HTTP кэшируются в течение 59 секунд, чтобы облегчить загрузку сервера и вызовы базы данных.Однако я рассматриваю кеширование всей таблицы БД в memcached и выполнение фильтрации в php.2000 строк не много, но время отклика для получения данных из памяти против базы данных будет намного быстрее.

Будет ли время обработки php перевешивать время отклика базы данных для фильтрации sql для этого числа строк?Таблица не должна увеличиваться больше чем на 3000 строк в обозримом будущем.

Answer 1

Как и в случае любого вопроса, касающегося is x faster than y, единственный реальный ответ - оценить его для себя.Однако, если база данных должным образом проиндексирована для запросов, которые вам нужно выполнить, она, вероятно, будет быстрее фильтровать наборы результатов, чем большинство PHP-кодов, которые вы могли бы написать.hand, уже разработан и оптимизирован для поиска, фильтрации и упорядочивания строк.

Answer 2

То, как работает PostgreSQL, если вы не очень сильно нуждаетесь в памяти, 100% такой маленькой и часто запрашиваемой таблицы будет храниться в ОЗУ (Cache) уже с помощью алгоритмов кэширования по умолчанию.Имея фильтр ядра базы данных, это почти наверняка быстрее, чем делать то же самое в вашем приложении.

Возможно, вы захотите проверить свои postgresql.conf, особенно shared_buffers, постоянные стоимости планировщика (установите random_page_cost почти или точно так же низко, как seq_page_cost) и effective_cache_size (установите достаточно высокое).

Возможно, вы выиграете от оптимизациииндексов.Существует широкий спектр доступных типов.Рассмотрим частичные индексы, индексы по выражениям или многостолбцовые индексы в дополнение к простым индексам.Протестируйте с помощью EXPLAIN ANALYZE и сохраняйте только те индексы, которые действительно используются, и ускоряйте запросы.Поскольку вся таблица находится в оперативной памяти, планировщик запросов должен рассчитать, что произвольный доступ почти или точно такой же быстрый, как и последовательный доступ.Разница относится только к чтению диска.

При обновлении каждую минуту убедитесь, что не , чтобы сохранить любые индексы, которые на самом деле не помогают.Кроме того, пылесос и его анализ часто являются ключами к производительности в таком случае.Не VACUUM FULL ANALYZE, просто VACUUM ANALYZE.Или используйте авто-пылесос с настроенными настройками.

Конечно, применяются все стандартные рекомендации по оптимизации производительности .