Документ рассматривает проблемы, связанные с использованием memcached и его альтернативами для кэширования данных в условиях высокой нагрузки на сервер базы данных. Основное внимание уделяется конкуренции кэшей, синхронизации данных и необходимости использования индексов для оптимизации производительности запросов. Также обсуждаются функции кэширования в современных системах управления базами данных, таких как Oracle и MySQL.

1. Зачем не нужен memcached Илья Космодемьянский

2. С чего все начинают

3. Проблемы Высокая нагрузка на сервер БД Медленный отклик

4. Что , где и как можно кэшировать? Г отовую выдачу или данные? Standalone система ( memcached ) Кэш операционной системы Кэш СУБД

5. Кэш ОС Очень не специализирован, работать сложно Кэш файловой системы может не дружить с ядром

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

7. Ура, нагрузка на базу снизилась!

8. O(1) Хэш в памяти - это быстро Разгрузили базу

9. Проблемы Кэш не влезает в память => Кэшей стало > 1 => Целостность данных Инвалидация Э ксплуатационные затраты

10. Общие пути решения Синхронизация : на каждый запрос, push, pull Репликация etc - путь джедая

11. СУБД не вчера придумали Д анных >> размера RAM Н еобходимая обвязка (сеть, транзакционность, бэкап) Book standard

12. СУБД не черный ящик Есть ли кэш в СУБД Если есть, то как им пользоваться

13. Немного об устройстве памяти в Oracle «У нас mysql – почему речь об Oracle? !» SGA и все-все-все Database buffer cache . Кэширование кэша Shared pool Result cache и где держать результаты «жутких запросов»

15. Как «готовить» СУБД scale-out и scale-up . Общие подходы И ндексы и iot Пишем быстрые запросы

16. Общие проблемы Есть «плохая база», некогда и не на что переписывать DBA дорог и капризен Цена вопроса

17. Memcached vs РСУБД ?

18. Вопросы? (с)2009 Илья Космодемьянский