Кэширование результатов запроса к БД

[Oddinn]

Кэширование результатов запроса к БД

Возможно этот вопрос уже поднимался, но мне ничего похожего найти не удалось. Итак, вопрос в следующем. Есть некая система, которая при каждом запуске производит множество однотипных SELECT-запросов к базе данных. Для того, чтобы не перегружать сервер, предполагается создавать массив, в котором сохранять результаты запросов, а в последствии проверять - если такой запрос уже был - вернуть данные не из базы, а из этого массива. Осталась одна проблема: как правильно проиндексировать этот массив? Пока единственный приемлемый вариант - это считать контрольные суммы строки запроса и делать их ключами массива. Но ведь есть вероятность, что контрольные суммы пересекуться. Может (даже наверняка) кто-нибудь уже писал нечто похожее - какие есть решения?

 

[su1d]

если будешь использовать хэши, например [m]SHA1[/m], то вероятность коллизий будет практически нулевая.

 

[Oddinn]

Автор оригинала: su1d
если будешь использовать хэши, например [m]SHA1[/m], то вероятность коллизий будет практически нулевая.

Я уже об этом думал, но не будет ли тормозить массив с 40-символьными ключами, елси в нем будет 100 - 150 записей? В таком случае индексом можно сделать просто строку запроса и исключить вероятность коллизий полностью.

 

[Popoff]

http://dev.mysql.com/doc/mysql/en/query-cache.html

 

[Oddinn]

Автор оригинала: Popoff
http://dev.mysql.com/doc/mysql/en/query-cache.html

Спасибо, этого не знал. Очень полезно. Правда вопрос все равно актуален, просто ради интереса, как в подобном случае правильнее создавать уникальные ключи в массиве.

 

[su1d]

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

 

[CM]

Я бы дополнительно предложил такой вариант - сохранять данные, полученные отдельными SELECT-ами в отдельные таблицы, а при последовательных запросах просто делать SELECT * из этих таблиц. Апдейтить данные в таких таблицах, соотвественно - при записи новых данных в базу или после апдейтов. Точнее, сразу после INSERT, UPDATE, DELETE или REPLACE делаешь свои SELECT-ы, только в виде SELECT INTO table. А потом уже работаешь с этими новыми таблицами. Если основная база содержит десятки/сотни тысяч записей, то такой подход дает существенный выигрыш в производительности и снижает нагрузку на сервер. Кроме того, это позволяет сравнительно просто сохранять однотипные данные между скриптами. Хорошо подходит для тех случаев, где, в основном, идет чтение из базы, а запись производиться редко, при этом запросы большей частью однотипные и их (разных) немного (типичный пример - форум).

Ну а так - query cache рулит, естественно