Как стать автором
Обновить

S3-FIFO: новый эффективный алгоритм вытеснения из кэша на основе очередей FIFO

Уровень сложностиСредний
Время на прочтение18 мин
Количество просмотров8.1K
Всего голосов 69: ↑69 и ↓0+69
Комментарии5

Комментарии 5

Эту статью надо назвать - как изобрести заново и добавить в алгоритмы FIFO три поколения из современных сборщиков мусора с поколениями (generational garbage collection). Интересно, действительно изобрели заново или скопировали, но ни разу не упомянули GC?

Ловкость рук =)) Принцип FIFO сломан же, первым выходит не первый вошедший.

"Если количество запросов до следующего повторного использования объекта больше, чем размер кэша / показатель промахов "

Т.е. чем больше промахов и меньше кэш, тем цель ближе. Если промахов нет, то приплыли. Очень сомнительная метрика.

Подскажите почему вам нужно три куска кеша и почему это быстрее чем один?

Вас что-то заминусовали так как будто мы тут на стаковерфлоу, давайте представим что ваша жена открыла лавку с пирожками(кеш) или не представим ?

Через некоторое время вы быстро поймёте что клиенты любят не просто пирожки(от простого наличия кеша ничего не поменяется), а перекусывать в удобное время не утруждая себя готовкой(использование кеша для ускорения работы).

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

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

А 3 очереди это просто дизайн вашей лавки, эти исследователи обнаружили что это эффективнее всех остальных известных вариантов.

Хех, как-то давно пилил сборку мусора для самописного key-value персистентного хранилища,
там было 8 уровней частоты изменения объектов и принцип "чехарды" (ну почти FIFO) - когда активные данные (на которые есть ссылки) переносились в конец секционированного лог-журнала, как бы "перепрыгивая" через другие данные, а мусорные записи оставались и когда в начальной секции не оставалось активных данных, начальная секция удалялась.
Также, если данные с прошлой сборки мусора не менялись, они переносились в конец следующего по частоте изменения уровня (на 0 уровне хранились наиболее часто изменяемые данные, на последнем 7-м - самые редко изменяемые).
Из преимуществ - можно было приостанавливать сборку мусора и делать бекапы файлов хранилища "на лету", в т.ч. rsync'ом, без рисков потери согласованности (ну это у всех лог-журнальных схем хранения так).
Короче, похожая тема, 3 бита в адресе под уровень частоты изменения и 1 бит под признак изменённости с прошлой сборки мусора. Адреса, соответственно, кратны 16...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий