Нужны предложения по стратегии кэширования

У нас есть приложение для фэнтези-футбола, которое использует memcached и классический memcached-object-read-with-sql-server. -fallback.Это работает довольно хорошо, но недавно я размышлял о связанных с этим накладных расходах и о том, является ли это лучшим подходом.

Case in po int — нам нужно сгенерировать выпадающий список команд пользователей, поэтому мы следуем этому шаблону:

  1. Получить список команд пользователей из memcached
  2. Если он недоступен, получить список с SQL-сервера и сохранить в memcached.
  3. Сделайте мультигет, чтобы получить объекты команды.
  4. Возврат к загрузке объектов из хранилища sql.

Все это очень хорошо — каждый кэшированный фрагмент данных относительно легко кэшируется и становится недействительным, но у этого есть два основных недостатка:

1) Поскольку мы работаем с объектами, мы берем на себя довольно большие накладные расходы — одна команда занимает несколько сотен байт в memcached, и в этом случае нам действительно нужен только список имен и идентификаторов команд, а не все остальное в объектах команды.

2) Из-за отказа от загрузки отдельных объектов количество SQL-запросов, сгенерированных в пустом кеше или по истечении срока действия элементов, может быть огромным: 1 х Memcached multiget (что пропускает, что и вызывает) 1 x SELECT... FROM Team WHERE Id IN (...) 20 х Хранить в memcached Так что это 21 сетевой запрос только для этого одного запроса, а также запрос IN медленнее, чем конкретное соединение.

Очевидно, что мы могли бы просто

SELECT Id, Name FROM Teams WHERE UserId = XYZ

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

Тааак... Мой вопрос: есть ли у кого-нибудь из вас идеи по устранению упомянутых недостатков, или я должен просто смириться с тем, что есть накладные расходы и что промахи кэша — это плохо, смириться с этим?

6
задан Micael 14 June 2012 в 14:23
поделиться