информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяSpanning Tree Protocol: недокументированное применениеАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 HP закрыла 16-летнюю уязвимость... 
 Microsoft советует пользователям... 
 MS Edge обогнал FireFox 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Интересная тема, есть куча мыслей. 11.06.05 16:13  Число просмотров: 2879
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Я так понимаю, что обсуждение будет затрагивать файловый кэш и как его разновидность кэш информации в базе данных.
Задача правильной работы грамотного кэша заключается в том, чтоб минимизировать случаи непопадания в кеш. То есть, чтоб с бОльшей вероятностью запрашиваемый элемент был удовлетворен из кэша при его объеме, меньше чем область кэшируемых данных. Здесь нужно понять то, что ни одна из стратегий не будет гарантировать абсолютную эффективность его работы при различных методах доступа к данным. В принципе неплохой реализацией было бы внесение нового элемента в кэш тех данных, которые скоро в последствии будут затребованы вновь, причем количество обращений к ним будет больше, чем к самому редко использующемуся элементу. При этом из кэша удаляется тот элемент, который в последствии будет наименее востребован. В предположении того, что сложно заранее определить какие данные в последствии будут наиболее часто запрошены и какие элементы кэша будут наиболее редко использоваться, сформулировать самый оптимальный алгоритм кэширования невозможно, но можно придумать что-то наиболее приемлемое.
Глядя на настройки работы файлового кэша в сетевой операционной системе Новэль, мне представился очень интересный алгоритм, который, вероятно, там реализован. Суть его в следующем: Каждому элементу таблицы кэша отводится структура данных, главным элементом в ней является признак активности использования этого элемента. Это значение увеличивается по мере удовлетворения запроса к данным из этого элемента кэша. Периодически происходит процесс уменьшения признаков активности использования для всех элементов. При доступе к очередным данным, при условии что они не были найдены в кэше, ищется элемент с наименьшим признаком активности. Если это значение ниже порогового, то он заменяется новыми данными и ему выставляется начальное, отличное от нуля, но небольшое значение признак активности. Таким образом наиболее долго будут находиться в кэше данные, к которым было наибольшее число обращений, поскольку на очередную востребованность у них вероятность будет наиболее высока – раз уж к ним так часто обращались, то вероятно еще много раз обратятся. Однако даже и они все равно когда-нибудь удалятся из кэша, если к ним долгое время не будет обращений. Данные же, которые очень мало были востребованы, просуществуют в кэше совсем небольшое время.
В этом методе может быть очень много параметров, которыми можно адаптировать кэш к конкретной задаче. Например начальное значение активности может быть выше всего двух – трех наименьших элементов, чтоб дать возможность этой области данных «доказать» свое право присутствия в кэше. Метод периодического понижения активности может быть как логарифмический, так и экспоненциальный. То есть в зависимости от значения признака активности он будет быстрее или медленнее уменьшаться. А так же предельное его значение и скорость роста в зависимости от значения, периодичность уменьшения значений признаков. Причем эти параметры можно изменять динамически. То есть кэш будет подстраиваться под данный метод обращения к данным.
Предположим, что в процессе работы было очень много обращений к небольшой области данных так, что она «осела» в кэши. Потом произошло последовательное обращение к большому объему данных. При этом будут (или даже не будут) обновляться только два- три элемента кэша, а относительный приоритет других элементов останется высоким, хотя абсолютные значения признаков уменьшатся.
При начальном последовательном обращении элементы будут заполнены первыми запрошенными данными и в процессе последовательного обращения будут (или не будут в зависимости от начального значения признака) заменяться очередными данными.
Можно отдельно вести небольшую таблицу статистики обращений без кэширования самих данных с тем, чтоб уже в кэш попадали «достойные того кандидаты».
Естественно, можно придумать такой метод обращения к данным, при котором этот алгоритм будет проигрывать другим по эффективности.

Если это нужно для курсовой/дипломной работы, то далее можно не читать, а с посетителями форума хотелось бы, пользуясь случаем, обсудить смысл собственной реализации кэширования.
Я лично считаю, что не только не стоит заниматься кэшированием, но и в буфферизации совершенно нет никакого смысла.
А именно, для обработки большого файла данных можно каждый раз лазить в файл, поскольку реализация кэширования в операционке заведомо лучше, чем реализуешь сам. Что нужно и так будет удовлетворено без обращения к накопителю. Единственный минус – накладные расходы на обращение к системе.
Можно поступить наоборот, сразу прочитать в оперативку весь файл и делать с ним что хочешь. Если оперативки не хватает, то операционка сама воспользуется накопителем для свопа и, причем, наилучшим образом, а сама програмка будет проще, меньше и быстрее написана. Хочется повысить быстродействие при увеличившемся объеме данных – просто добавь модуль оперативной памяти, скорость работы будет расти то тех пор, пока оперативки не будет достаточно.
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach