Вопрос дизайна кеша - PullRequest
       6

Вопрос дизайна кеша

0 голосов
/ 07 февраля 2011

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

Ответы [ 4 ]

4 голосов
/ 07 февраля 2011

По моему опыту, «дизайн кеша» - это смесь чёрного искусства и точной науки. В то время как наука о науке имеет тенденцию быть чрезвычайно предсказуемой, это заставит вас думать, что есть формула или, по крайней мере, хорошее практическое правило, которое вы можете применить, чтобы получить полезные результаты. Черная часть искусства означает, что это правда, но она полностью фальсифицирована, но все же удается оставаться верной.

Одна вещь, которая остается неизменной, - это необходимость в комплексных метриках. Безусловно, вы должны иметь обширные цифры, основанные на профилировании вашего приложения с использованием Real World & trade; данные. Без этого вы просто угадываете. Десятилетия практического опыта снова и снова показывают, что если вы, как программист, гадаете о природе «где проблема производительности», то вы на 100% гарантированно поймете ее неправильно. Отсюда необходимость в достоверных эмпирических данных.

Если вы решите заняться этим, первое, что вам нужно сделать, прежде чем вы даже начнете «работать над проблемой», - это найти способ сбора эмпирических показателей. Поскольку вы не упоминаете, какой язык или инструменты вы используете, я не могу давать конкретные рекомендации, но практически в каждой цепочке инструментов есть инструменты для профилирования, специально разработанные для того, чтобы помочь вам понять, на что ваша программа тратит время.

Далее ваша интуиция в этом случае, вероятно, верна. Вы уже определили, что ваши шаблоны доступа, скорее всего, будут «смещены при записи». Очень распространенным свойством записей является то, что «они должны произойти, прежде чем вы сможете сделать что-то еще». Если это связано с записью данных на диск, вы, как правило, сталкиваетесь с затруднениями при ожидании завершения операции дискового ввода-вывода, что обычно приводит к снижению производительности. В этом случае кэширование вряд ли поможет вообще, поскольку вы не можете «кэшировать запись», потому что это должно произойти.

В некоторых случаях «кэширование записи» может помочь. Если ваш дизайн и требования допускают временную несовместимость версии данных в памяти с версией данных на диске, часто можно «объединить записи». По сути, это включает в себя задержку фиксации данных на диск из-за того факта, что для некоторых шаблонов доступа некоторые непоследовательные записи будут «обновлять» один и тот же «блок» в окне «сброс на диск».

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

EDIT

После перечитывания вашего вопроса не ясно, является ли это проблемой с производительностью, с которой вы столкнулись прямо сейчас, или которая, по вашему мнению, вы могли бы испытать. Если это позже, перечитайте, по крайней мере, три раза, второй абзац в моем ответе. только время, которое вы должны рассматривать при построении системы кэширования, - это когда вы определили с помощью твердых эмпирических данных, что у вас есть проблема с производительностью.

1 голос
/ 07 февраля 2011

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

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

Частота, а не размер записей обычно является показателем того, насколько горячим является кэш.

0 голосов
/ 07 февраля 2011

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

0 голосов
/ 07 февраля 2011

Кеш увеличивает производительность передачи. Часть увеличения аналогичным образом происходит из-за возможности того, что несколько небольших передач объединятся в один большой блок. Но основной выигрыш в производительности происходит потому, что есть большая вероятность, что один и тот же элемент данных будет считан из кэша несколько раз или что записанные данные вскоре будут прочитаны. Единственная цель кэша - уменьшить доступ к базовому медленному хранилищу. Поэтому вы должны уделять большое внимание тому, когда и что вы на самом деле кешируете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...