У нас есть приложение для фэнтези-футбола, которое использует memcached и классический memcached-object-read-with-sql-server. -fallback.Это работает довольно хорошо, но недавно я размышлял о связанных с этим накладных расходах и о том, является ли это лучшим подходом.
Case in po int — нам нужно сгенерировать выпадающий список команд пользователей, поэтому мы следуем этому шаблону:
Все это очень хорошо — каждый кэшированный фрагмент данных относительно легко кэшируется и становится недействительным, но у этого есть два основных недостатка:
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
И кэшировать этот результат, но это означало бы, что эти данные должны быть специально аннулированы всякий раз, когда пользователь создает новую команду. В этом случае это может показаться относительно простым, но у нас есть много запросов такого типа, и многие из них работают с осями, которые нелегко аннулировать (например, список идентификаторов и названий команд, которые ваши друзья создали в определенном месте). игра).
Тааак... Мой вопрос: есть ли у кого-нибудь из вас идеи по устранению упомянутых недостатков, или я должен просто смириться с тем, что есть накладные расходы и что промахи кэша — это плохо, смириться с этим?