Что кэшируется?
Я хотел отфильтровать строки dfbc, у которых был BUSINESS_ID, который также был в BUSINESS_ID dfProfilesBusIds
. Наконец, он работал:
dfbc = dfbc[(dfbc['BUSINESS_ID'].isin(dfProfilesBusIds['BUSINESS_ID']) == False)]
9 ответов
Кэширование является просто практикой того, чтобы хранить данные в и получения данных из высокоэффективного хранилища (обычно память) или явно или неявно.
Позволяют мне объяснить. Память быстрее к доступу, чем файл, удаленный URL (обычно), база данных или любое другое внешнее хранилище информации, которую Вы любите. Таким образом, если действие использования одного из тех внешних ресурсов значительно затем, можно извлечь выгоду из кэширования для увеличения производительности.
Knuth однажды заявил, что преждевременная оптимизация является корнем всего зла. Ну, преждевременное кэширование является корнем всех головных болей, что касается меня. Не решайте проблему до Вас , имеют проблема. Каждое решение, которое Вы делаете, приходит по стоимости, которую Вы оплатите, чтобы реализовать его теперь и заплатить снова для изменения его позже так, чем дольше можно отложить принимать решение и изменять систему, тем лучше.
Поэтому сначала определяют, что у Вас на самом деле есть проблема и где это . Профилирование, вход и другие формы тестирования производительности помогут Вам здесь. Я не могу подчеркнуть достаточно, насколько важный этот шаг. Количество раз я видел, что люди "оптимизируют" что-то, что не является проблемой, колеблется.
хорошо, таким образом, у Вас есть проблема производительности. Скажите, что Ваши страницы выполняют запрос, который занимает много времени. Если это - чтение затем, у Вас есть много опций:
- Выполнение запрос как отдельный процесс и помещенный результат в кэш. Все страницы просто получают доступ к кэшу. Можно обновлять кэшированную версию так часто, как является соответствующим (один раз в день, один раз в неделю, один каждые 5 секунд, независимо от того, что является соответствующим);
- Кэш прозрачно через Вашего поставщика решения для хранения данных, ORM или что бы то ни было. Конечно, это зависит, на какой технологии Вы используете. Hibernate и Ibatis, например, поддерживают кэширование результата запроса;
- Имеют Ваши страницы, выполняет запрос, если результат не находится в кэше (или это является "устаревшим", означая, что он вычисляется дольше назад, чем указанный "возраст"), и поместите его в кэш. Это имеет проблемы параллелизма, если два (или больше) отдельные процессы все решают, что они должны обновить результат, таким образом, Вы заканчиваете тем, что выполнили тот же (дорогой) запрос восемь раз сразу. Можно обработать эту блокировку кэша, но это создает другую проблему производительности. Можно также отступить к методам параллелизма на языке (например, API Java 5 параллелизма).
, Если это - обновление (или обновления происходят, который должен быть отражен в Вашем кэше считывания) затем это немного более сложно, потому что это бесполезно наличие старого значения в кэше и более нового значения в базе данных, таким образом, что Вы затем предоставляете своим страницам непоследовательное представление данных. Но вообще говоря существует четыре подхода к этому:
- Обновление кэш и затем ставят запрос в очередь для обновления соответствующего хранилища;
- Запись посредством кэширования: поставщик кэша может обеспечить механизм, чтобы сохранить обновление и заблокировать вызывающую сторону, пока то изменение не внесено; и
- Запись - позади кэширования: то же как запись - посредством кэширования, но это не блокирует вызывающую сторону. Обновление происходит асинхронно и отдельно; и
- Персистентность как услуга модели: это предполагает, что Ваш механизм кэширования поддерживает некоторую наблюдательность (т.е. слушатели события кэша). В основном совершенно отдельный процесс - неизвестный вызывающей стороне - прислушивается к обновлениям кэша и сохраняет их по мере необходимости.
то, Которое из вышеупомянутых методологий Вы выбираете, будет во многом зависеть от Ваших требований, какие технологии Вы используете и большое количество других факторов (например, кластеризируете, и поддержка кластерных систем требуется?).
трудно быть более конкретным, чем это и дать Вам указания на то, что обойтись без знания очень [еще 1118] деталь о Вашей проблеме (как то, есть ли у Вас проблема).
Существует два значения, о которых я знаю.
<час>Каждый приложение, кэширующееся . Это - когда, если данные не спешат заставлять от где-нибудь (например, из-за сети) или медленный вычислять, то кэши приложения копия данных (так, чтобы это не должно было получать его снова или повторно вычислять: это уже кэшируется). Реализация кэша берет немного дополнительного прикладного программного обеспечения (логика для использования кэша) и дополнительная память (в котором можно сохранить кэшированные данные).
Это "кэширует" быть используемым, поскольку Вы заключаете в кавычки здесь:
<час>От контекста я могу получить смысл его, чтобы сохранить часто полученное значение в оперативную память и иметь quicklook доступ к нему.
Другой ЦП, кэширующийся , который описан в эта статья Wikipedia. Кэширование ЦП происходит автоматически. Если Вы делаете большое чтение из небольшого объема памяти, то ЦП может сделать большинство тех чтений от своего кэша. OTOH, если Вы читаете из большого объема памяти, он не может все поместиться в кэш, и ЦП должен провести больше времени, работая с более медленной памятью.
Это "кэширует" быть используемым, поскольку Вы заключаете в кавычки здесь:
, Когда кто-то говорит, что они нашли часть кода, который повредит кэширование и после того, как они зафиксировали его, это улучшило скорость их приложения, о чем они говорят?
Это означает, что они нашли способ перестроить их код для порождения меньше Неудачные обращения в кэш .
<час>Что касается [1 115] база данных, кэширующаяся , я не знаю.
кэширование берет результат длинного или CPU интенсивный алгоритм и сохраняет ответ так, чтобы Вы не выполняли алгоритм снова, Вы просто снова используете результат.
Кэширование не обязательно только относится 'часто к полученным' значениям, но к чему-либо, на чем можно сэкономить время путем сокращения количества раз, Вы повторно вычисляете его. Простой пример, который приходит на ум, вычисляет последовательность fibonacci . Самая простая рекурсивная реализация похожа на это (в psuedo-коде):
function f(n)
if n < 2 then
return n;
return f(n - 1) + f(n - 2)
Это может быть улучшено с кэшированием уже для предотвращения перевычисления известных значений:
fib_cache = {}
function f(n)
if n < 2 then
return n;
if fib_cache.contains(n) then
return fib_cache[n]
fib_cache[n] = f(n - 1) + f(n - 2)
return fib_cache[n]
Это, вероятно, легче, чем Вы могли вообразить - и вот почему люди пытаются закрыть его.
Это просто означает хранить значения в Вашей памяти, а не возвращаться к базе данных для них каждый раз.
существует много способов сделать так, но само понятие тривиально.
Редактирование: Это может быть сделано на ЛЮБОМ уровне также - что-либо, что занимает много времени, может кэшироваться где-нибудь, что можно добраться до более быстро.
Кэширование в базах данных обычно является функцией база данных, и этим управляет автоматически база данных. Кэширование в приложениях собирается варьироваться от одной платформы до другого.
объектный кэш является механизмом, который можно использовать для помещения наиболее часто используемых объектов в память так, чтобы Вы не должны были оплачивать стоимость, чтобы получить данные и воссоздать их. Этим обычно управляют с помощью кода и варьируется, на каком кэшировании решения Вы используете.
существуют распределенные решения для кэша, которые включают установку сервисов на несколько серверов, чтобы дать Вам своего рода ферму кэша. Это обеспечивает масштабируемость и дублирование. Клиенты могут запросить кэшируемую информацию по сети. Снова это - ручная процедура в Вашем коде. Примером распределенного поставщика кэша является memcached:
http://www.danga.com/memcached/
примером определенного типа кэширования было бы кэширование asp.net. Asp.net поддерживает несколько видов кэша. Существует традиционный объектный кэш (который может использоваться во всех видах приложений .NET, не просто веб-сайтах). Существуют также возможности кэширования, которые позволяют Вам страницам настройки и пользовательским элементам управления автоматически кэшировать их вывод. Это не кэширует данные, они кэшируют конечный результат (HTML страницы) и подают это, когда пользователь запрашивает ту же страницу с теми же детскими колясками строки запроса как предыдущий пользователь.
Вы будете, скорее всего, читать о кэшировании в контексте веб-приложений. Из-за природы сети кэширование может сделать большое различие в производительности.
Рассматривают следующее:
запрос веб-страницы А добирается до веб-сервера, который передает запрос на сервер приложений, который выполняет некоторый код, который представляет страницу, которая должна обратиться к базе данных для динамичного получения данных.
Эта модель не масштабируется хорошо, потому что, поскольку количество запросов на страницу повышается, сервер должен сделать то же самое много раз для каждого запроса.
Это становится еще большим количеством проблемы, если веб-сервер, сервер приложений и база данных находятся на других аппаратных средствах и связываются по сети друг с другом.
, Если у Вас есть большое количество пользователей, поражающих эту страницу, имеет смысл не идти полностью до базы данных для каждого запроса. Вместо этого Вы обращаетесь к кэшированию на разных уровнях.
Кэш Набора результатов
кэширование Набора результатов хранит результаты запроса базы данных наряду с запросом в приложении. Каждый раз, когда веб-страница генерирует запрос, проверки приложений, кэшируются ли результаты уже, и если они, вытягивают их от набора данных в оперативной памяти вместо этого. Приложение все еще должно представить страницу.
Кэш Компонента
веб-страница А состоит из различных компонентов - pagelets, или независимо от того, что можно хотеть назвать их. Стратегия кэширования компонента должна знать, какие параметры использовались для запроса компонента. Например, немного панели "Последних новостей" на сайте использует географическое положение пользователя или предпочтение для показа локальных новостей. Следовательно, если новости для местоположения кэшируются, компонент не должны представлять и можно вытянуть от кэша.
Кэш Страницы
Одна стратегия кэширования всех страниц состоит в том, чтобы сохранить строку запроса и/или параметры заголовка наряду с полностью renderered HTML. Файловая система достаточно быстра для этого - это - все еще путь, менее дорогой для веб-сервера для чтения файла, чем позвонить на сервер приложений, чтобы представить страницу. В этом случае каждый пользователь, который отправляет ту же строку запроса, получит то же кэшируемое содержание.
Объединение этих стратегий кэширования разумно является единственным способом создать действительно масштабируемые веб-приложения для больших количеств параллельных пользователей. Как можно легко видеть, потенциальный риск здесь состоит в том, что, если часть содержания в кэше не может быть однозначно определена, он является ключевым, люди начнут видеть неправильное содержание. Это может стать довольно сложным, особенно когда у пользователей есть сессии и существует контекст защиты.
Понятие кэша является перегруженным термином здесь. Я не знаком с основными деталями кэширования базы данных.
В приложениях существует два использования термина.
, Когда кто-то говорит, что они нашли часть кода, который повредит кэширование и после того, как они зафиксировали его, это улучшило скорость их приложения, о чем они говорят?
В этом случае они ссылаются на кэш ЦП.
кэш ЦП НА ПАМЯТИ ЦП, это намного более быстро, чем RAM, но это не имеет произвольного доступа. То, что ЦП решает загрузить в кэш, может стать немного сложным. Посмотрите Ulrich Dreppers , Что каждый программист должен знать о памяти для большого количества деталей.
Являющийся помнящим кэш ЦП может ускорить вещи вполне прилично - просто необходимо обратить на немного больше внимания туда, где дела идут к помещенному друг относительно друга в физической памяти и когда они, вероятно, будут использоваться.
Один пример (также, вероятно, антишаблон для пригодности для обслуживания), это - Вы, имеют массив структур, и Вы делаете большое цикличное выполнение по членам структуры, Вы могли бы быть лучше обслужены со структурой, где поля являются всеми массивами. Если данные, Вы - законченное цикличное выполнение, непрерывны в памяти, у Вас есть лучший шанс при не нарушении кэша.
Все виды вещей могут произвести эффективность Вашего использования кэша - предсказание ветвлений для кода, загруженного в кэш, размер и выравнивание структур данных и схем доступа, где и когда объявить локальные переменные, которые будут помещенными на стек.
другое общее использование термина для прикладного программирования может быть сделано чем-то позвонившим memoization. Факториальный пример на том, что страница Википедии объясняет вещи лучше, чем, я сделал бы.
Существует несколько проблем.
Один, гранулярность. Ваше приложение может иметь очень прекрасные уровни кэширования свыше того, что делает база данных. Например, база данных вероятна просто страницами кэша данных, не обязательно определенными строками.
Другая вещь состоит в том, что приложение может хранить данные в своем "собственном" формате, тогда как DB очевидно только кэши в его внутреннем формате.
Простой пример.
Скажите, что у Вас есть Пользователь в базе данных, которая сделана из столбцов: USERID, FIRSTNAME, LASTNAME. Очень простой.
Вы хотите загрузить Пользователя, USERID=123, в Ваше приложение. Что включены шаги?
- Издавание приказа базы данных
- Парсинг запроса (
SELECT * FROM USER WHERE USERID = ?) - Планирование запроса (т.е. как система собирается выбрать данные),
- Выборка данных из диска
- Потоковая передача данных от базы данных до приложения
- Преобразование данных Базы данных к данным приложения (т.е.
USERIDк целому числу, скажем, имена к Строкам.
Кэш базы данных будет, вероятно, шаги 2 и 3 кэшей (это - кэш оператора, таким образом, он не проанализирует или повторно запланирует запрос), и кэширует блоки фактической дисковой емкости.
Так, вот ключ. Ваш пользователь, USER ID 123, имя JESSE JAMES. Вы видите, что это не много данных. Но база данных кэширует дисковые блоки. У Вас есть индексный блок (с 123 на нем), затем блок данных (с фактическими данными и всеми другими строками, которые соответствуют на том блоке). Таким образом, что является номинально, скажем, 60-70 байтами данных, на самом деле имеет кэширование и влияние данных на DB, вероятно, 4K-16K (зависит от размера блока).
Положительная сторона? Если Вам нужна другая строка, это является соседним (сказать USER ID = 124), разногласия высоки, индекс и данные уже кэшируются.
Но даже с тем кэшированием, все еще необходимо оплатить стоимость для перемещения данных через провод (и это - alway по проводу, если Вы не используете локальный DB, затем это - обратная петля), и Вы "не упорядочиваете" данные. Таким образом, преобразовывая его от битов Базы данных до битов языка, к битам Приложения.
Теперь, однажды Приложение получают USER ID 123, это наполняет значение в долговечной карте хеша.
Если приложение когда-нибудь захочет это снова, то это посмотрит в локальной карте, кэше приложения, и сохранит поиск, проводной транспорт и упорядочивающие затраты.
Темная сторона кэширования приложения является синхронизацией. Если кто-то входит и делает a UPDATE USER SET LASTNAME="SMITH" WHERE USERID=123, Ваше приложение "не знает, что", и таким образом кэш грязен.
Так, затем существует набор деталей в обработке тех отношений для хранения приложения в синхронизации с DB.
Наличие БОЛЬШОГО КОЛИЧЕСТВА кэша базы данных очень хорошо для выполнения больших запросов по "горячему" набору данных. Чем больше памяти Вы имеете, тем больше "горячих" данных Вы можете иметь. До точки, если можно кэшировать весь DB в RAM, Вы устраняете ввод-вывод (по крайней мере, для чтений) задержка движущихся данных с диска на буфер RAM. Но у Вас все еще есть транспорт и упорядочивающие затраты.
Приложение может быть намного более выборочным, таким как кэширование более ограниченных подмножеств данных (DBS просто блоки данных кэша), и наличие данных "ближе" к приложению восполняет ту намного лучшую производительность.
Вниз сторона - то, что не все кэшируется в Приложении. База данных имеет тенденцию хранить данные более эффективно, в целом, чем приложение. Вы также испытываете недостаток в языке "запроса" против своих кэшированных данных приложения. Большинство людей просто кэш через простой ключ и идет оттуда. Легкий найти USER ID 123, тяжелее для "ВСЕХ ПОЛЬЗОВАТЕЛЕЙ НАЗВАЛ JESSE".
Кэширование базы данных имеет тенденцию быть "бесплатным", Вы определяете буферный номер, и DBMS обрабатывает остальных. Низко повлияйте, уменьшает полный ввод-вывод и дисковые задержки.
Кэширование приложения, ну, в общем, специализировано.
Это работает очень хорошо на изолированные "статические" данные. Это очень легко. Загрузите набор материала в к справочным таблицам при запуске и перезапустите приложение, если они изменяются. Это легко сделать.
После того, как та сложность начинает увеличиваться, как Вы добавляете в "грязной" логике и т.д.
То, к чему все это сводится, tho, то, что, пока у Вас есть Данные API, можно кэшироваться инкрементно.
Так, пока Вы звоните getUser(123) везде вместо того, чтобы поразить DB, затем можно позже возвратиться и добавить кэширование к getUser не влияя на Ваш код.
Так, я всегда предлагаю некоторый Уровень доступа к данным в общем коде, для обеспечения того бита слоя абстракции и перехвата.