Cache data что это

cache — что это за папка на Андроиде?

• Разбираемся
• Можно ли удалить?
• Вывод

Приветствую уважаемые друзья! В этой небольшой заметке постараюсь простыми словами рассказать зачем нужна директория cache на Андроиде.

cache — что это за папка на Андроиде?

Сразу коротко ответ: содержит временные данные, которые необходимы для ускорения работы системы или приложений.

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

Например существует директория /data/dalvik-cache — она нужна для программы Dalvik, представляющая из себя Java-виртуальную машину, которая предназначена для корректного запуска apk-программ. Вот чтобы программы запускались быстрее — и нужен данный кэш.

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

• Быстрая скорость память. Это тип памяти, откуда данные считываются намного быстрее. Поэтому почему бы туда не копировать те файлы, которыми система или программа пользуется чаще всего? Вполне логично. Именно поэтому на компьютере в качестве кэша часто используется оперативная память — она намного быстрее как жесткого диска, так и твердотельного SSD.
• Второй вариант менее распространен — это область памяти, но скорость чтения из нее обычная. То все обычно. Вот только данные внутри папки имеют другой формат, они могут быть распакованными, а могут быть просто как-то иначе записаны, так, чтобы чтение происходило быстрее.

Неважно где именно располагается папка — важно то, что предназначение ее в 99% одно, это кэширование данных:

Можно ли удалить папку cache?

Тут зависит от того что именно внутри. Если там только кэш — удалить можно, но только содержимое, саму папку не нужно удалять.

Если мы имеем ввиду /data/dalvik-cache — то саму папку удалять не стоит, а вот содержимое удалить можно. Пустая все равно не грузит систему никак, она ведь пустая. Важно понимать, что в будущем кэш будет восстановлен.

Чтобы ответить на вопрос удалять или нет, нужно просто выяснить — что именно в папке cache, если там только кэш и никаких других данных нет — значит можно удалять, но только содержимое.

Ну и конечно, идеальнее всего перед вообще любыми изменениями/удалениями в системе — сделать резервную копию Android, то есть бэкап.

Заключение

• Папка cache на Андроиде, неважно где она присутствует, предназначена почти всегда для одного — кэширования данных, чтобы доступ к ним был быстрее, чем обычно.
• Можно ли очистить папку cache? Можно только в том случае, если внутри — 100% кэш, что там нет других папок и нет других важных данных кроме кэша. Но лучше именно очищать содержимое, саму папку удалять не стоит.

Надеюсь данная информация оказалась вам полезной, удачи и добра, до новых встреч друзья!

Память Андроид: очистить кэш и данные приложений

Память мобильных устройств — вопрос, интересующий многих владельцев Android-смартфонов. Объём доступной к использованию свободной памяти, предоставляемый производителями телефонов, за последние годы существенно увеличился, но объём данных, которые хранит пользователь в носимых гаджетах, растёт ещё быстрее.

В данной статье мы поговорим об одном из способов, позволяющих освободить место в памяти Андроид смартфона . Ниже речь пойдёт о том, что такое очистка кэша и что происходит при нажатии на кнопку Очистить данные у приложений в Android OS.

Накопитель заполнен на 75%. Перенести данные на SD-карту

Со временем, когда объём хранимой на смартфоне информации сильно увеличивается, пользователь может столкнуться с проблемой нехватки памяти на телефоне. Уведомление, оповещающее о том, что память заполнена , может выглядеть по-разному. Вот один из примеров:

О чём говорит это предупреждение? В данном случае система предупреждает, что на внутренней памяти устройства осталось меньше 25% свободного пространства. По большому счёту, это не критическая ошибка, доступная память ещё в наличии, но нужно иметь ввиду два момента:

1. Свободное место на телефоне скоро может закончиться, чтобы этого не произошло в самый неподходящий момент, заранее позаботьтесь об освобождении занятого простарнства.
2. Для комфортной работы с ОС желательно держать свободным некоторый объём памяти внутреннего накопителя. Это обеспечит поддержание уровня быстродействия и плавности в повседневном использовании.

В статье Память на Android. Все разделы памяти Андроид устройств мы подробно останавливались на разборе всех типов памяти Android OS. Там же приводилась следующая строчка:

Внутренняя память устройства (Internal phone storage) — та часть модуля памяти смартфона, которая не занята системными разделами и доступна пользователю для размещения приложений, медиа-контента и документов. Часть памяти, на которую устанавливается софт , определяется как раздел Data, а часть, занятая пользовательскими файлами — как User.
Зачастую реальной границы между этими областями нет, и тогда распределение памяти зависит только от нужд владельца устройства.

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

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

Если с удалением медиафайлов и документов всё более или менее понятно, то вопрос оптимизации памяти, занимаемой приложениями, рассмотрим подробнее.

Будьте осторожны! Все манипуляции с данными на своих устройствах вы производите исключительно на свой страх и риск! Ни администрация ресурса, ни автор статьи не несут ответственности за возможную потерю данных, вызванную неточными действиями пользователя или спецификой работы приложения

Из чего состоят приложения на Андроид

В первую очередь, стоит указать, что каждое Андроид приложение условно можно разделить на три части по типу используемых файлов:

1. Программа. Это само приложение, apk-файл .
2. Данные приложения. Это пользовательская информация, которая сохраняется в процессе всего периода жизни той или иной программы на смартфоне. Данные вносятся в программу пользователем или по его прямому запросу.
3. Кэш приложения. Это временно хранимые файлы. Грубо говоря, это та же пользовательская информация, с той лишь разницей, что её утрата не влияет на работоспособность приложения. Программа способна заполнить кэш нужными данными самостоятельно в процессе работы.

Теперь определим, где хранится программа, её данные и кэш приложения на Андроид.
Если продолжить отсылку к упомянутой выше статье о памяти на Android и воспользоваться классификацией разделов из неё, то можно смело утверждать, что и сама программа, и данные пользовательских приложений, и их кэш хранятся в Энергонезависимой памяти -> в Перезаписываемом разделе EEPROM -> Internal phone storage (внутренний накопитель) -> Data (то есть, данные).
Мы в данном случае не рассматриваем системные приложения, так как они расположены в Прошиваемом разделе System, и, без наличия root-прав, недоступны для удаления.
То есть, из вышесказанного делаем вывод, что и программа, и её данные с кэшем занимают память в разделе Data , а это значит, что очистка любой из этих составляющих, освобождает пользовательское место и, собственно, частично решает проблему нехватки памяти на Андроид устройстве.
Взглянем на все составные части приложений Android детальнее.

Удаление приложения на Андроид

Сначала отметим, что сама программа в системе Андроид — это не только apk-файл . Кроме него могут быть задействованы дополнительные библиотеки и дополнительные технические* файлы программы.
Под техническими файлами мы понимаем те ресурсы, которые хранятся вне исполнительного файла , но служат для обеспечения выполнения приложением своей работы.
И исполнительный файл программы, и сопутствующие ему файлы чаще всего располагаются в следующем каталоге от корня файловой системы:

/data/app/

В папке app располагается каталог приложения, в корне которого находится сам apk-файл , и папка lib, в которую помещаются системные библиотеки, если таковые имеются. В зависимости от программы, рядом с apk-файлом могут быть и папки с другим названием.

Содержимое папки с программой в каталоге /data/app/ хранится там на протяжении всего времени работы от момента установки до момента деинсталляции приложения.

То есть, при удалении приложения с телефона стирается именно папка программы по пути /data/app/ со всем её содержимым: и apk-файл , и системные файлы программы.

Очистить данные приложения Андроид

Теперь, что касается данных приложения. Данные — это, в первую очередь, пользовательская информация. В общем случае хранятся данные приложения в следующем каталоге:

/sdcard/Android/data/

В частном случае это может быть немного иной путь, что, в частности, соответствует общему каталогу, отличаясь только отображением иерархии каталогов:

/storage/emulated/0/Android/data/

Этой папкой возможные места хранения данных приложения на Андроид не ограничиваются. Часто программа при установке создаёт свой каталог в корне карты памяти: либо внутренней, либо внешней. Именно в этих папках программа сохраняет информацию, которую:

• вводит пользователь;
• скачивает само приложение по запросу юзера.

Кроме вышеперечисленных путей есть ещё один каталог, о котором нужно упомянуть отдельно. Речь пойдёт о папке obb, которая расположена по пути:

/sdcard/Android/obb/

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

Игровая индустрия развивается достаточно быстро. Вместе с этим растут и требования к аппаратной части, в том числе и к дисковому пространству. Всё это актуально и для Android OS. Серьёзные игры с красивой прорисовкой графики и серьёзным геймплеем требуют хранения большего объёма системной информации. Всё это привело к тому, что у многих игр появился ярко выраженный кэш. Но, как и в разных способах установки программ, есть несколько путей и в том, как поместить кэш игры в папку /Android/obb/:

1. Если объём кэша не очень велик , то разработчик может заархивировать данные, поместить их непосредственно в apk-файл или просто привязать загрузку кэша к загрузке самой игры. При установке такой игры кэш самостоятельно распакуется в нужную папку. Эту возможность разработчики иногда используют как дополнительную защиту от взлома, так как в случае, если вы скачали игру не из магазина Google Play, а из альтернативного источника, игра при запуске не найдёт кэш и откажется запускаться.
2. Если в apk-файле всех файлов игры не размещено, то, по умолчанию, кэш игры скачивается через интернет автоматически самим приложением при его первом запуске.
   Нужно отметить ещё одну причину, по которой кэш игр не очень удобно упаковывать изначально в apk-файл. Дело в том, что, зачастую, кэш для разных телефонов будет отличаться в зависимости от разрешения экрана, типа видеочипа и процессора, а иногда и от модели смартфона. А если скачивать кэш при первом запуске игры, то не придётся передавать на смартфон пользователя те данные, которые не подходят для его устройства.
3. Всё*, что скачивается конкретным приложением, можно скачать вручную. То есть, кэш игры можно качать не через саму игру, а отдельно . Это возможно в том случае, если кто-нибудь скачает подходящий вам кэш (по разрешению экрана, типу видеоускорителя и так далее) и выложит его в сеть. Тогда нам останется скачать архив с кэшем и поместить его в нужный каталог: obb или data, в зависимости от игры (в частных случаях путь хранения кэша может отличаться и указывается дополнительно).

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

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

При нажатии кнопки Очистить данные в менеджере приложений Андроид происходит удаление всей пользовательской информации конкретной программы, в том числе и кэша игр (опять же, в общем случае). То есть, после очистки данных приложения оно возвращается в такое же состояние, как и в момент сразу после установки.

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

Очистить кэш приложения Андроид

Для начала определим, что такое кэш приложения :

Кэш — это хранилище информации, буфер, содержащий данные, к которым должен быть обеспечен оперативный доступ

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

Мы заходим на определённую статью на сайте, которая содержит, допустим, 5 картинок. Для того, чтобы отобразить эти картинки пользователю, браузер скачивает их превьюшки и сохраняет на жёсткий диск или в память телефона. Теперь, когда мы зайдём на эту же статью в следующий раз, браузеру не придётся повторно качать те же изображения, он выдаст их нам из кэша , что позволяет увеличить общую скорость загрузки страницы.

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

Давайте рассмотрим пример, который объясняет смысл понятий программа, данные приложения и кэш приложения простыми словами.

Предположим у нас, как у пользователя , в офисе сидит секретарша офис-менеджер Татьяна. Татьяна — это, в нашем случае, приложение . На рабочем столе Татьяны стоит компьютер, которым офис-менеджер постоянно пользуется — это данные приложения . Кроме компьютера на рабочем столе всегда находятся ручка, блокнот, степлер, дырокол и калькулятор — это кэш нашего приложения .

В какой-то момент времени мы переезжаем в другой офис (прошивка или смена устройства), он больше и просторнее, но в нём пока нет ничего. В первую очередь, приходит офис-менеджер (установка программы). Однако, она пока не может работать, у неё нет данных, поэтому мы устанавливаем ей компьютер (подгрузка данных приложения). Работа закипела. Но пока стол пуст (кэш очищен), скорость работы офис-менеджера ниже прежней: каждый раз, чтобы скрепить документы или посчитать большие суммы, ей приходится отвлекаться на поиски нужных инструментов. Поэтому, постепенно на столе у Татьяны вновь появляется степлер и кулькулятор (заполнение кэша). А вот блокнот, оказывается, нужен не так часто, поэтому он может лежать в выдвижном шкафу, а на освободившееся на столе место мы поместим календарь, обращение к которому происходит чаще. Благодаря этому Татьяна теперь справляется со своими задачами ещё быстрее.

Это грубый пример того, как очистка кэша благотворно влияет на работу приложения .

Кэш приложения также может размещать по разным папкам. Чаще всего это одноимённый каталог cache, который расположен, например, в папке приложения из /Android/data/

При нажатии кнопки Очистить кэш в менеджере приложений Андроид происходит удаление всей временной информации , к которой программа обращалась ранее. В ходе дальнейшей работы с программой наполнение кэша происходит заново .

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

Соответственно, отвечая на вопрос: «Удалится ли кэш игры при очистке кэша приложения?» — можно сказать, что нет, содержимое папки /Android/obb/ в общих случаях не затрагивается, если иное не предусмотрено разработчиком системы или приложения.

Обзор кэширования

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

Как работает кэширование?

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

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

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

Кэширование с помощью Amazon ElastiCache

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

Преимущества кэширования

Повышение производительности приложений

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

Сокращение затрат на базы данных

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

Снижение нагрузки на серверную часть

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

Прогнозируемая производительность

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

Устранение проблемных мест в базах данных

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

Повышение пропускной способности операций чтения (количество операций ввода-вывода в секунду)

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

Примеры использования и отрасли

Примеры использования
Примеры использования
Узнайте о различных примерах использования кэширования

Кэширование баз данных

Производительность, как с точки зрения скорости, так и с точки зрения пропускной способности базы данных, может оказаться тем фактором, который больше всего влияет на общую производительность приложения. Несмотря на то, что сегодня немало баз данных отличается относительно высокой производительностью, для многих примеров использования вашим приложениям может требоваться больше. Благодаря кэшированию баз данных можно значительно повысить пропускную способность и понизить задержки получения данных, связанные с серверными базами данных, что в результате повышает общую производительность ваших приложений. Кэширование выполняет роль смежного уровня доступа к вашей базе данных, и приложения могут использовать его для повышения производительности. Уровень кэша баз данных можно расположить перед базой данных любого типа, в том числе перед реляционной базой данных и базой данных NoSQL. Для загрузки данных в кэш обычно используются такие методы, как отложенная загрузка и сквозные операции записи. Подробнее см. по ссылке.

Сеть доставки контента (CDN)

Если ваш сетевой трафик географически рассредоточен, не всегда целесообразно и, конечно же, не экономично создавать во всем мире полные реплики инфраструктуры. CDN предоставляет вам возможность доставлять клиентам кэшированные копии веб-контента, например видео, веб-страниц, изображений и т. д. с помощью глобальной сети периферийных местоположений. Чтобы сократить время ответа, CDN использует самое близкое к клиенту или исходному запросу периферийное местоположение. Пропускная способность значительно повышается, причем веб-ресурсы доставляются из кэша. Если нужно использовать динамические данные, многие CDN можно настроить для получения данных от исходных серверов. Amazon CloudFront является сервисом CDN, ускоряющим доставку ваших веб-сайтов, API, видеоконтента или других сетевых ресурсов. Он интегрирован с другими продуктами Amazon Web Services и позволяет разработчикам и компаниям легко обеспечить ускоренную доставку контента конечным пользователям без обязательств по минимальному объему использования. Подробнее о CDN см. здесь.

Кэширование DNS

Каждый запрос к домену, отправленный по Интернету, фактически опрашивает серверы кэша DNS, чтобы определить IP-адрес, связанный с именем домена. Кэширование DNS может осуществляться на многих уровнях, в том числе на уровне ОС, поставщика услуг Интернета и серверов DNS. Amazon Route 53 – это высокодоступный и масштабируемый облачный веб-сервис системы доменных имен (DNS).

Управление сеансами

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

API

Большинство современных веб-приложений создано на основе API. По своей сути API представляет собой веб-сервис RESTful, к которому можно обращаться по протоколу HTTP и который предоставляет доступ к ресурсам, позволяющим взаимодействовать с приложением. При проектировании API важно принять во внимание ожидаемую нагрузку на API, авторизацию для его использования, влияние изменения версий на потребителей API и, что самое важное, простоту использования. API не всегда представляет бизнес-логику и (или) отправляет фоновые запросы к базе данных при каждом запросе. Иногда самым оптимальным и экономичным ответом является предоставление кэшированного результата выполнения запроса к API. Это особенно справедливо в ситуации, когда вы можете кэшировать ответ API в соответствии со скоростью изменения данных. Предположим, что вы предоставляете пользователям API списка продуктов, и категории продуктов изменяются только раз в день. Поскольку ответ на запрос к API для получения категории продукта будет одним и тем же в течение дня, достаточно кэшировать ответ API на данный день. Кэшируя ответы API, вы устраняете нагрузку на инфраструктуру, в том числе на серверы приложений и на базы данных. Еще одно преимущество заключается в сокращении времени ответа, благодаря чему вы предоставляете более эффективный API. Amazon API Gateway – это полностью управляемый сервис для разработчиков, предназначенный для создания, публикации, обслуживания, мониторинга и обеспечения безопасности API в любых масштабах.

Кэширование для гибридных сред

В гибридных облачных средах могут встречаться облачные приложения, которым необходимо часто обращаться к локальной базе данных. Для взаимодействия между облачной и локальной средой можно использовать многие сетевые топологии, в том числе VPN и Direct Connect. А поскольку задержка при взаимодействии VPC с локальным центром обработки данных может быть малой, лучше всего кэшировать локальные данные в облачной среде, чтобы повысить скорость их получения.

Веб-кэширование

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

Общий кэш

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

Интегрированный кэш

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

Узнайте о различных отраслях и примерах использования кэширования

Мобильные технологии

Мобильные приложения – это сегмент рынка, который растет с невообразимой скоростью, учитывая быстрое освоение устройств потребителем и спад в использовании традиционного компьютерного оборудования. Практически для каждого сегмента на рынке, будь то игры, коммерческие приложения, медицинские программы и т. д., есть приложения с поддержкой мобильных устройств. С точки зрения разработки создание мобильных приложений очень похоже на создание любых других приложений. Вы сталкиваетесь с теми же вопросами на уровнях представления, бизнеса и данных. Несмотря на разницу в пространстве экрана и инструментах для разработчиков, общей целью является обеспечение качественного взаимодействия с клиентом. Благодаря эффективным стратегиям кэширования ваши мобильные приложения могут обеспечивать такой уровень производительности, которого ожидают ваши пользователи, масштабироваться до любых размеров и сокращать общие затраты. AWS Mobile Hub – это объединенная консоль для удобного поиска, настройки и использования облачных сервисов AWS, предназначенных для разработки и тестирования мобильных приложений, а также мониторинга их использования.

Интернет вещей (IoT)

Интернет вещей – это концепция сбора информации с устройств и из физического мира с помощью датчиков и ее передачи в Интернет или в приложения, которые принимают эти данные. Ценность IoT заключается в способности понимать собранные данные в режиме, близком к реальному времени, что в конечном счете позволяет системе и приложениям, принимающим эти данные, быстро реагировать на них. Возьмем, к примеру, устройство, которое передает свои GPS-координаты. Ваше приложение IoT может предложить интересные места, которые находятся поблизости от этих координат. Кроме того, если вы сохранили предпочтения пользователя устройства, то можете подобрать наиболее подходящие рекомендации для этого пользователя. В этом отдельном примере скорость ответа приложения на полученные координаты критически важна для достижения качественного взаимодействия с пользователем. Кэширование может сыграть в нем важную роль. Интересные места и их координаты можно хранить в хранилище пар «ключ – значение», например в Redis, чтобы обеспечить их быстрое получение. С точки зрения разработки вы можете запрограммировать свое приложение IoT, чтобы оно реагировало на любое событие, если для этого существуют программные средства. При создании архитектуры IoT необходимо рассмотреть некоторые очень важные вопросы, в том числе время ответа при анализе полученных данных, создание архитектуры решения, масштаб которого охватывает N устройств, и экономичность архитектуры. AWS IoT – это управляемая облачная платформа, которая позволяет подключенным устройствам просто и безопасно взаимодействовать с облачными приложениями и другими устройствами. Дополнительные сведения: Managing IoT and Time Series Data with Amazon ElastiCache for Redis

Рекламные технологии

Современные приложения в сфере рекламных технологий особо требовательны к производительности. Примером важной области развития в этой сфере является торг в режиме реального времени (RTB). Это подход к трансляции рекламы на цифровых экранах в режиме реального времени, основанный на принципе аукциона и работающий со впечатлениями на самом подробном уровне. RTB был преобладающим способом проведения транзакций в 2015 году, учитывая то, что 74,0 процента рекламы было куплено программными средствами, что в США соответствует 11 миллиардам долларов (согласно eMarketer Analysis). При создании приложения для торгов в режиме реального времени важно учитывать то, что одна миллисекунда может решать, было ли предложение предоставлено вовремя, или оно уже стало ненужным. Это значит, что нужно крайне быстро получать данные из базы. Кэширование баз данных, при использовании которого можно получать данные о торгах за считанные доли миллисекунды, – это отличное решение для достижения такой высокой производительности.

Игровые технологии

Интерактивность – это краеугольный камень каждой современной игры. Ничто так не раздражает игроков, как медленная игра и долгое ожидание реакции. Такие игры редко становятся успешными. Мобильные многопользовательские игры еще требовательнее к производительности, потому что информацию о действии одного игрока необходимо предоставлять другим игрокам в режиме реального времени. Кэширование игровых данных играет решающую роль в бесперебойной работе игры благодаря тому, что время ответа на запросы к часто используемым данным исчисляется в долях миллисекунды. Также важно решить проблемы востребованных данных, когда множество одинаковых запросов отправляется к одним и тем же данным, например «кто входит в первую десятку игроков по счету?» Подробнее о разработке игр см. здесь.

Мультимедиа

Мультимедийным компаниям часто требуется передавать клиентам большое количество статического контента при постоянном изменении количества читателей или зрителей. Примером является сервис потоковой передачи видео, например Netflix или Amazon Video, которые передают пользователям большой объем видеоконтента. Это идеальный случай для использования сети доставки контента, в которой данные хранятся на серверах кэширования, расположенных во всем мире. Еще одним аспектом медиаприложений является пикообразная и непредсказуемая нагрузка. Возьмем, к примеру, публикацию в блоге на веб-сайте, о которой некоторая знаменитость только что отправила сообщение в Twitter, или веб-сайт футбольной команды во время Суперкубка. Такой высокий пик спроса на маленькое подмножество контента – вызов для многих баз данных, потому их пропускная способность для отдельных ключей ограничена. Поскольку пропускная способность оперативной памяти гораздо выше, чем у дисков, кэш базы данных помогает решить эту проблему путем перенаправления запросов чтения в кэш в памяти.

Интернет-коммерция

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

Социальные сети

Приложения для социальных сетей взяли мир штурмом. У таких социальных сетей, как Facebook, Twitter, Instagram и Snapchat, очень много пользователей, и объем контента, который они потребляют, все больше растет. Когда пользователи открывают свои ленты новостей, они ожидают, что увидят свежий персонализированный контент в режиме реального времени. Это не статический контент, поскольку у каждого пользователя разные друзья, фотографии, интересы и т. д., за счет чего обостряется необходимость в усложнении платформы, на которой основано приложение. Кроме того, приложения для социальных сетей подвержены пикам использования во время крупных развлекательных мероприятий, спортивных и политических событий. Устойчивость к пиковым нагрузкам и высокая производительность в режиме реального времени возможны благодаря использованию нескольких уровней кэширования, включая сети доставки контента для статического контента, например изображений, кэш сеансов для учета данных текущих сессий пользователей и кэш баз данных для ускорения доступа к часто запрашиваемому контенту, например последним фотографиям и свежим новостям от близких друзей.

Здравоохранение и здоровый образ жизни

В сфере здравоохранения происходит цифровая революция, благодаря которой медицинское обслуживание становится доступным все большему количеству пациентов во всем мире. Некоторые приложения позволяют пациентам общаться с врачами по видеосвязи, а многие крупные клиники предлагают своим клиентам приложения, в которых можно посмотреть результаты анализов и связаться с медицинским персоналом. Для поддержания здорового образа жизни существует множество приложений: от программ для отслеживания показаний датчиков (например, FitBit и Jawbone) до полных курсов тренировок и подборок данных. Поскольку эти приложения по своей сути интерактивные, необходимо, чтобы они были высокопроизводительными и удовлетворяли бизнес-требованиям и требованиям к данным. Вооружившись эффективной стратегией кэширования, вы сможете обеспечить быструю работу приложений, сократить общие затраты на инфраструктуру и масштабировать ее по мере роста востребованности. Подробнее о создании приложений для сферы здравоохранения на AWS см. здесь.

Финансы и финансовые технологии

За последние годы потребление финансовых сервисов очень изменилось. Существуют приложения для доступа к банковским и страховым услугам, функциям выявления мошенничества, сервисам инвестирования, оптимизации капитальных рынков с использованием алгоритмов, которые работают в режиме реального времени, а также многие другие приложения. Очень сложно предоставлять доступ к финансовым данным клиента и возможность проведения таких транзакций, как перевод средств или совершение платежей, в режиме реального времени. Во-первых, к приложениям для этой сферы применяются те же ограничения, что и к приложениям для других сфер, в которых пользователю требуется взаимодействовать с приложением в режиме, близком к реальному времени. Кроме того, финансовые приложения могут предъявлять дополнительные требования, например относительно повышенной безопасности и выявления мошенничества. Для того чтобы производительность отвечала ожиданиям пользователя, крайне важно создать эффективную архитектуру с использованием стратегии многоуровневого кэширования. В зависимости от требований приложения уровни кэширования могут включать кэш сеансов для хранения данных о сессиях пользователя, сеть доставки контента для передачи статического контента и кэш базы данных для передачи часто запрашиваемых данных, таких как последние 10 покупок клиента. Подробнее о финансовых приложениях на AWS см. здесь.

Как работает SSD-кэширование в системах хранения данных

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

SSD-кэширование — это технология, при которой твердотельные накопители используются в качестве буфера для часто запрашиваемых данных. Система определяет степень «теплоты» данных и перемещает их на быстрый накопитель. За счет этого чтение и запись этих данных будут выполняться с большей скоростью и с меньшей задержкой.

Про SSD-кэширование часто говорят, когда речь идет о системах хранения данных, где эта технология дополняет HDD-массивы, повышая производительность за счет оптимизации случайных запросов. Устройство HDD-накопителей позволяет им успешно справляться с последовательным паттерном нагрузки, но имеет естественное ограничение для работы со случайными запросами. Объем SDD-кэша при этом обычно составляет около 5–10% от емкости основной дисковой подсистемы.

Системы, которые используют SSD-кэш вместе с HDD-дисками, принято называть гибридными. Они популярны на рынке СХД, так как значительно доступнее по цене, чем all-flash конфигурации, но при этом способны эффективно работать с достаточно широким спектром задач и нагрузок.

Когда SSD-кэш будет полезен

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

На практике появление случайных запросов среди равномерной последовательной нагрузки совсем не редкость. Это может происходить при одновременной работе на сервере нескольких различных приложений. Например, одно имеет установленный приоритет и работает с последовательными запросами, а другие время от времени обращаются к данным (в том числе, повторно) в случайном порядке. Другим примером возникновения случайных запросов может быть так называемый I/O Blender Effect, который перемешивает последовательные запросы.

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

Рисунок 1. Равномерный временной интервал с предсказуемой частотой обращений

При большом количестве таких обращений пространство SSD-накопителей будет быстро заполняться, и производительность системы будет стремиться к скорости работы на HDD-накопителях.

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

• случайные запросы на чтение или на запись имеют низкую интенсивность и неравномерный временной интервал;
• количество операций ввода-вывода на чтение значительно больше, чем на запись;
• количество «горячих» данных будет предполагаемо меньше размеров рабочего пространства SSD.

Как работает SSD-кэш в СХД

Функция кэша — ускорять выполнение операции за счет размещения часто запрашиваемых данных на быстрых носителях. Для кэширования самых «горячих» данных используется оперативная память (RAM), в СХД это кэш первого уровня (L1 Cache).

Кэш первого уровня может быть дополнен менее быстрыми твердотельными накопителями. В этом случае у нас появляется кэш второго уровня (L2 Cache). Такой подход используется для реализации SSD-кэширования в большинстве существующих СХД.

Рисунок 2. Традиционный SSD-кэш второго уровня.

Традиционный SSD-кэш второго уровня работает следующим образом: все запросы после RAM попадают в буфер SSD (рисунок 3).

Работа кэша на чтение

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

Работа кэша на запись

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

Алгоритмы заполнения кэша

Один из главных вопросов в работе SSD-кэша — выбор данных, которые будут помещаться в буферное пространство. Так как объем хранения тут ощутимо ограничен, то при его заполнении нужно принимать решение о том, какие блоки данных вытеснять и по какому принципу производить замещение.

Для этого применяются алгоритмы заполнения кэша. Коротко рассмотрим наиболее распространенных в сегменте СХД.

FIFO (First In, First Out) — из кэша последовательно вытесняются наиболее старые блоки, замещаясь наиболее свежими.

LRU (Least Recently Used) — из кэша первыми вытесняются блоки данных с наиболее давней датой обращения.

LARC (Lazy Adaptive Replacement Cache) — блоки данных попадают в кэш, если они были запрошены как минимум дважды за определенный промежуток времени, а кандидаты на замещение отслеживаются в дополнительной LRU-очереди в оперативной памяти.

SNLRU (Segmented LRU) — данные из кэша вытесняются по принципу LRU, но при этом они проходят несколько категорий (сегментов), обычно это: «холодные», «теплые», «горячие». Степень «теплоты» здесь определяется частотой обращений.

LFU (Least Frequently Used) — из кэша первыми вытесняются те блоки данных, к которым было меньше всего обращений.

LRFU (Least Recently/Frequently Used) — алгоритм комбинирует работу LRU и LFU, вытесняя сначала те блоки, которые попадают под рассчитываемый параметр из даты и количества обращений.

В зависимости от типа алгоритма и качества его реализации будет определяться итоговая эффективность SSD-кэширования.

Особенности SSD-кэширования в RAIDIX

В RAIDIX реализован параллельный SSD-кэш, который имеет две уникальные особенности: разделение входящих запросов на категории RRC (Random Read Cache) и RWC (Random Write Cache) и использование Log-структурированной записи для собственных алгоритмов вытеснения.

1. Категории RRC и RWC

Пространство кэша разделено на две функциональные категории: для случайных запросов на чтение — RRC, для случайных запросов на запись — RWC. Для каждой из этих категорий есть свои правила попадания и вытеснения.

За попадание отвечает специальный детектор, который квалифицирует поступающие запросы.

Рисунок 3. Схема работы SSD-кэша в RAIDIX

Попадание в RRC

В область RRC попадают только случайные запросы с частотой обращения больше 2-х (ghost-очередь).

Попадание в RWC

В область RWC попадают все случайные запросы на запись, у которых размер блока меньше устанавливаемого параметра (по умолчанию 32KB).

2. Особенности Log-структурированной записи

Log-структурированная запись — это способ последовательной записи блоков данных без учета их логической адресации (LBA, Logical Block Addressing).

Рисунок 4. Визуализация принципа Log-структурированной записи

В RAIDIX Log-структурированная запись используется для заполнения выделенных областей (с установленным размером в 1 ГБ) внутри RRC и RWC. Эти области применяются для дополнительного ранжирования при перезаписи пространства кэша.

Вытеснение из буфера RRC

Выбирается самая холодная область RRC, и в нее перезаписываются новые данные из ghost-очереди (данные с частотой обращений больше 2-х).

Вытеснения из буфера RWC

Область выбирается по принципу FIFO, а затем из нее последовательно, в соответствии с LBA (Logical Block Address), вытесняются блоки данных.

Возможности SSD-кэширования в RAIDIX

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

Алгоритмы вытеснения используют log-структурированную запись для более эффективного замещения данных в кэше. Благодаря этому снижается количество обращений к flash-накопителям и существенно сокращается их износ.

Сокращение износа SSD-накопителей

Благодаря детектору нагрузки и алгоритмам перезаписи суммарное количество write hits на массив SSD накопителей в RAIDIX составляет 1.8. В аналогичных условиях работа кэша второго уровня с алгоритмом LRU имеет значение 10.8. Это означает, что количество требуемых перезаписей на флеш-накопители в реализованном подходе будет в 6 раз меньше, чем во многих традиционных СХД. Соответственно, SSD-кэш в RAIDIX будет использовать ресурс твердотельных накопителей значительно эффективнее, увеличивая срок их жизни примерно в 6 раз.

Эффективность SSD-кэширования на различных нагрузках

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

Мы провели тестирование SSD-кэша, эмулируя различные рабочие ситуации с разными типами нагрузок. Сравнив полученные результаты со значениями системы без SSD-кэша, можно наглядно оценить прирост производительности при разных типах запросов.

Конфигурация системы:
SSD кэш: RAID 10, 4 SAS SSD, объем 372 GB
Основное хранилище: RAID 6i, 13 HDD, объем 3072 GB

Тип паттерна	Тип запроса	Значение с SSD-кэшированием	Значение без SSD-кэширования	Увеличение производительности
Случайное чтение (100% попадание в кэш)	random read 100%	85.5K IOps	2.5K IOps	В 34 раза
Случайная запись (100% попадание в кэш)	random write 100%	23K IOps	500 IOps	В 46 раз
Случайное чтение (80% попадание в кэш, 20% попадание на HDD)	random read 100%	16.5K IOps	2.5K IOps	В 6.5 раз
Случайное чтение из кэша, запись на HDD	random read 50%	40K IOps	180 IOps	В 222 раза
	sequential write 50%	870 Mbps	411 Mbps	В 2 раза
Случайное чтение и запись (100% попадание в кэш)	random read 50%	30K IOps	224 IOps	В 133 раза
	random write 50%	19K IOps	800 IOps	В 23 раза
Последовательные запросы с большим блоком, случайная нагрузка 100% попадает в SSD-кэш	random read 25%	2438 IOps	56 IOps	В 43 раза
	random write 25%	1918 IOps	82 IOps	В 24 раза
	sequential read 25%	668 Mbps	120 Mbps	В 5.5 раз
	sequential write 25%	382 Mbps	76.7 Mbps	В 5 раз

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

Заключение

Технология SSD-кэширования позволяет повысить производительность СХД при работе со смешанным типом нагрузки. Это доступный и простой способ получить эффективно работающую систему в случаях, когда HDD накопители не имеют физической возможности обеспечить желаемый результат.

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

SSD-кэш, реализованный в СХД RAIDIX, обладает особым набором свойств, который позволяет ему не только ускорять работу системы, но и продлевать срок используемых SSD-накопителей.