Блог Андрея Смирнова

Серия постов про «Web, кэширование и memcached» продолжается. Начало здесь: 1, 2 и 3. В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached.

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

Следующий пост будет посвящен тэгированию кэшей.

Continue reading…

Индекс по полю в БД потенциально может ускорить SELECT операцию с условием по данному полю, может ускорить заброс вида: ORDER BY поле LIMIT 20, но индекс замедляет существенно операции изменения таблицы и т.п.

Когда нужен индекс, когда он поможет и будет использован при SELECTах? Всё зависит от селективности индекса, т.е. от кол-ва строк, которые мы получим если зададим условие

проиндексированное_поле = значение

Отличный кандидат для индексирования – селективность 1, т.е. уникальный индекс (например, id), когда по указанному значению мы найдем максимум одну запись. Хорошо, когда селективность составляет < 5% (например, поле city_id у пользователя). При этом PostgreSQL умён, он считает не селективность «вообще», а селективность в виде гистограммы по отдельным значениям поля. Т.е. если мы задаем условие вида

страна = Россия

то получим 10% записей из БД, а если условие

страна = Уругвай

то получим 2 записи, и это PostgreSQL понимает.

Так вот, если селективность плохая (получим много записей), PostgreSQL предпочтёт выполнить полное сканирование БД, не используя индекс. И такой индекс только мешает.