КЕШИРОВАНИЕ
 ДАННЫХ В БД
   Макс Лапшин
   апрель 2009
ПРИВЕТ

Меня зовут Макс Лапшин
•max@maxidoors.ru
•http://github.com/maxlapshin
•модератор ror2ru



              О чем бу...
ПРОБЛЕМЫ КЕШИРОВАНИЯ
Кеширование — сохранение однажды
вычисленных данных для последующего их
повторного использования.

Ке...
ЗАЧЕМ КЕШИРОВАТЬ?
•Быстрый рендеринг одной страницы даже на
малопосещаемом сайте
•Приемлемая загрузка при большом потоке
п...
КАНДИДАТЫ В КЕШ
         Примеры с живых сайтов:
•Счетчик непрочитанных сообщений;
•Корреспонденты по переписке в личных
с...
ОТКУДА НАГРУЗКА?
При выборке списка корреспондентов из таблицы
сообщений происходит JOIN и группировка
таблиц больше 1M за...
МОЖЕТ MEMCACHED?
Очень быстрая сетевая, прекрасно
масштабирующаяся, хеш-таблица с
гарантированным максимальным временем жи...
ЧЕМ ПЛОХ MEMCACHED?
                   МНОГИМ
•Нельзя получить список ключей;
•Нет100% гарантии когерентности кеша;
•Данны...
НЕУЖЕЛИ ВСЁ ТАКИ В БД?
•Счетчик непрочитанных сообщений в переписке
между двумя пользователями будет
использоваться при ре...
СТРАТЕГИИ КЕШИРОВАНИЯ
•Со счетчиками всё ясно: их стоит кешировать
всегда. @user.friends.count @user.friends.size
•Кеширов...
СЧЕТЧИКИ
•Всегда делайте NOT NULL DEFAULT 0;
•Лучше инкрементить/декрементить из
after_create/after_destroy дочерней модел...
СПИСКИ
•Rails (без патчей) не позволяют иметь свой
формат сериализуемого атрибута, поэтому если
сохранять через serialize,...
СЛОЖНЫЕ ДАННЫЕ
•При показе спецификации фотоаппарата, надо
вытянуть список свойств камеры, список типов
свойств и по нему ...
КОМПОЗИТНЫЕ ТИПЫ
На new.prophotos.ru была опробована методика
сохранения группированных данных
специфичными средствами БД:...
WRITE ONCE
Такие данные можно только переписывать и
читать. Дописывать в такую колонку
нецелесообразно. Апдейт всей таблиц...
READ FAST
Просто так рельсы не умеют читать композитные
типы и массивы:
{quot;(vendor_text,{Cavei},string,Производитель)qu...
РЕЗУЛЬТАТЫ
Лично я стараюсь сейчас придерживаться такой
стратегии: кешировать в базе данные, которые
можно вычислить.

В m...
Upcoming SlideShare
Loading in …5
×

кеширование в бд

1,628 views
1,516 views

Published on

Презентация для выступления на апрельском сборе railsclub.ru

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,628
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
50
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

















  • кеширование в бд

    1. 1. КЕШИРОВАНИЕ ДАННЫХ В БД Макс Лапшин апрель 2009
    2. 2. ПРИВЕТ Меня зовут Макс Лапшин •max@maxidoors.ru •http://github.com/maxlapshin •модератор ror2ru О чем буду рассказывать?
    3. 3. ПРОБЛЕМЫ КЕШИРОВАНИЯ Кеширование — сохранение однажды вычисленных данных для последующего их повторного использования. Кеширование затрагивает следующие проблемы: •запись кешируемых данных; •извлечение закешированных данных; •очистка неактуальных закешированных данных, т.е. поддержание когерентности кеша Последний пункт, пожалуй, самый проблемный. Это точно кому-то нужно?
    4. 4. ЗАЧЕМ КЕШИРОВАТЬ? •Быстрый рендеринг одной страницы даже на малопосещаемом сайте •Приемлемая загрузка при большом потоке посетителей •Быстрые апдейты •Быстрые выборки •Быстрый рендеринг А чего кешировать?
    5. 5. КАНДИДАТЫ В КЕШ Примеры с живых сайтов: •Счетчик непрочитанных сообщений; •Корреспонденты по переписке в личных сообщениях на lookatme.ru; •Сложно сгруппированные атрибуты из 4- табличного JOIN-а в спецификации камеры на new.prophotos.ru Да ну, чего там медленного?
    6. 6. ОТКУДА НАГРУЗКА? При выборке списка корреспондентов из таблицы сообщений происходит JOIN и группировка таблиц больше 1M записей. Это чудовищная нагрузка на любую базу. При показе счетчика сообщений происходит выборка из огромной таблицы на каждом показе страницы. Это неоправданная нагрузка на базу и замедление отдачи страницы.
    7. 7. МОЖЕТ MEMCACHED? Очень быстрая сетевая, прекрасно масштабирующаяся, хеш-таблица с гарантированным максимальным временем жизни записи и гарантированным отсутствием гарантий жизни чего-бы то ни было. Он вообще имеет право ничего не сохранять. Чем же плох memcached?
    8. 8. ЧЕМ ПЛОХ MEMCACHED? МНОГИМ •Нельзя получить список ключей; •Нет100% гарантии когерентности кеша; •Данные из Memcached нельзя использовать в SQL выборках; •Его надо разогревать; •Не решает проблему медленного показа редко посещаемых страниц. А куда кешировать?
    9. 9. НЕУЖЕЛИ ВСЁ ТАКИ В БД? •Счетчик непрочитанных сообщений в переписке между двумя пользователями будет использоваться при рендеринге раздела «непрочитанные». Использовать memcached невозможно. •Сохранить в событие список идущих на него user_id, сохранить пользователю список friends_id и можно прям в БД получить количество идущих на событие друзей. А подетальнее?
    10. 10. СТРАТЕГИИ КЕШИРОВАНИЯ •Со счетчиками всё ясно: их стоит кешировать всегда. @user.friends.count @user.friends.size •Кеширование может породить целую модель, решающую проблему кеша. Например «Переписка», в ней будут храниться все данные для быстрого рендеринга: user_login, sender_login, last_message_id; •Специфичные средства БД (PostgreSQL). А подетальнее?
    11. 11. СЧЕТЧИКИ •Всегда делайте NOT NULL DEFAULT 0; •Лучше инкрементить/декрементить из after_create/after_destroy дочерней модели; •Если не лочить таблицу, то возможны коллизии, надо быть готовым всегда пересчитать сбившийся счетчик (-5 непрочитанных сообщений); •Всегда использовать @user.friends.size, потому что он использует @user.friends_count А чего со списком друзей?
    12. 12. СПИСКИ •Rails (без патчей) не позволяют иметь свой формат сериализуемого атрибута, поэтому если сохранять через serialize, в базе будет YAML. Это большой overhead; •Нет ничего страшного в том, что бы сгенерировать YAML SQL-запросом, это может быть в 200 раз быстрее, чем через find_each и save; •В PostgreSQL есть тип ARRAY, который можно заполнять, пересекать и обрабатывать прям в базе:
    13. 13. СЛОЖНЫЕ ДАННЫЕ •При показе спецификации фотоаппарата, надо вытянуть список свойств камеры, список типов свойств и по нему сгруппировать свойства; •Если у вас Mysql, то делайте всё в рельсах, сохраняйте группированные данные в YAML. Это медленно, но другого способа нет. На обработку 5000 записей уходит до получаса. •В PostgreSQL есть композитные типы — палочка-выручалочка. Что ещё за композитные типы?
    14. 14. КОМПОЗИТНЫЕ ТИПЫ На new.prophotos.ru была опробована методика сохранения группированных данных специфичными средствами БД: Как с таким нонконформизмом работать?
    15. 15. WRITE ONCE Такие данные можно только переписывать и читать. Дописывать в такую колонку нецелесообразно. Апдейт всей таблицы 30 сек А кто это будет читать?
    16. 16. READ FAST Просто так рельсы не умеют читать композитные типы и массивы: {quot;(vendor_text,{Cavei},string,Производитель)quot;,quot;(name,quot;{quot;quot;CV-PT10 H3quot;quot;}quot;,string,Модель)quot;,quot;(type, {настольный},string,Тип)quot;,quot;(purpose,quot;{quot;quot;фото- и видеокамерыquot;quot;}quot;,string,quot;Сфера примененияquot;)quot;,quot;(construction, {трипод},string,Конструкция)quot;,… Для этого был написан неопубликованный патч PostgresParser: >> Device.find_by_permalink('pentax-k10d').cached_properties => [#<struct ArrayRetrieval::CachedProperty name=quot;fullnamequot;, values=[quot;Pentax K10Dquot;], data_format=quot;stringquot;, description=quot;Полное названиеquot;>, #<struct ArrayRetrieval::CachedProperty name=quot;start_datequot;, values=[quot;2006/09/13quot;], data_format=quot;stringquot;, description=quot;Дата анонсаquot;>, #<struct ArrayRetrieval::CachedProperty name=quot;lens_mountquot;, values=[quot;KAFquot;], data_format=quot;stringquot;, description=quot;Байонетquot;> Код ещё медленный, по 20 мс на разбор 120 свойств в текстовом виде вместо 200-300 мс на вытаскивание из БД. ActiveRecord внутри — жуть =( И помогло?
    17. 17. РЕЗУЛЬТАТЫ Лично я стараюсь сейчас придерживаться такой стратегии: кешировать в базе данные, которые можно вычислить. В memcached класть только HTML, который не требует быть 100% синхронным. Я пока не нашел разумного способа отслеживать зависимости фрагментов в мемкеше от данных. Кеширование в базе разумно делать с помощью расширенных средств БД, т.к. кеш штука опциональная. И помогло?

    ×