Оптимизация хранения данных

Хранение ваших данных

Ральф Вальдо Эмерсон, Эссе, 1841

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

Мы же с вами можем делать столько дискретных измерений, сколько пожелаем. Мы даже можем на ходу менять измерения, полагаясь на сложную логику. И, конечно, мы знаем, как работать с большими массивами данных. Так зачем же мы от них избавляемся? Вот, посмотрите на документацию одного популярного инструмента для анализа RRDtool:

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

Такой подход в корне неверен. И не только из-за пространственных суждений об оптимизации. Выбрасывать исходные данные и оставлять только собранную метрику во избежание захламления диска — очень непродуманно.

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

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

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

Таким образом, храните исходные данные в очень быстрых БД, но только в первые недели или месяцы использования. У вас всегда будет доступ к этим данным, чтобы провести нужный анализ. Затем вы можете запихнуть их в RRD или что-либо еще для хранения данных на длительной основе. На выходе мы имеем буфер со свежими и актуальными исходными данными для диагностики текущих проблем и предыдущие записи для сверки и сравнения.

Это приводит нас прямиком к системе Scuba, разработанной компанией Facebook. Когда Лиор Авраам и Дэвид Райс преподнесли нам эту идею, она показалась мне абсурдной. Хранить исходные данные в оперативной памяти? Без индексов? Каждый запрос как он есть? Чушь. Это были достаточно тяжелые времена, когда мы вынуждены были умещать все наши данные на дисках. О чем они вообще думали?

А думали они о будущем. Чопорность инструментов, с которыми ми имели дело в те времена, особенно зависимость от постоянного предугадывания, была нашей повседневной реальностью. Мы могли располагать только несколькими размерностями одновременно, и если проблема таилась где-то еще, мы просто застревали. Добавление других размерностей превращало работу в сплошную головную боль, которая, конечно же, не способствовала решению поставленной задачи. Исходные данные оказывались либо утерянными, либо доступ к ним был затруднен.

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

Ниже приведено начало README файла для системы анализа разработанной компанией Square, Inc.

Cube — это система сбора событий с присвоенными метками времени и последующим составлением метрики. Собирая события, а не уже готовую метрику, Cube позволяет составлять статистику постфактум. github.com/square/cube

Как же ее создать

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

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

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

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

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

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

Включение разной информации о среде в логи DERP позволит анализировать производительность большего числа компонентов системы. Загружаются ли сервера равномерно? А как насчет разных дата-центров, в которых они могут находиться? Как только этот набор данных собран, в поле sample_rate будет храниться сумма всех произведенных запросов.

Группируя запросы во временной размерности по 300 секунд, мы сможем увидеть, что заход на страницу /health, цель которой показывать нам, что сервер работоспособен и отвечает на запросы, показывает вполне стабильную производительность, что от него и ожидается.

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

Вкратце о моделировании данных

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

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

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

Оптимизация хранения корпоративных данных Текст научной статьи по специальности «Компьютерные и информационные науки»

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Ефимов И. Н., Жукова С. А.

Текст научной работы на тему «Оптимизация хранения корпоративных данных»

(показатель, уточняющий метрики сложности, ориентированные на оценку информационной энтропии).

Проведенные статистические исследования множества разноязычных текстов (русский, английский, немецкий, французский) позволяют оценить характеристики человека как канала связи (восприятия) с присущими ему пропускными показателями. Была разработана программа (язык С++) с алгоритмом, подсчитывающим количество букв в словах и количество слов в предложении. Результатом исследований явилось среднестатистическое значение показателя а=8 — количество параллельного восприятия человеком отдельных символов. Экспериментальный результат подтверждает вывод теории информодинамики о дискретности восприятия человеком с «мерой восприятия» а=2 =8. Сделанные выводы позволяют говорить о возможности применения «ментальных» мер сложности для оценки разноаспектных информационных структур.

Ментальные меры сложности. Процесс объективирования будем рассматривать с позиции двух составляющих.

1. Процесс обучения (education), осознания. В человеческом мозгу формируется множество A ментальных символов на основе новых визуальных образов и (или) нового семантического наполнения уже существующих, в зависимости от внешних условий (ограничений) и состава определяющих поведенческих задач. Формируется синтаксическое пространство B языка активного восприятия, воздействия, управления. В этом случае количество сравнительных операций внутри множества A равняется: ke=log2A, где ke — коэффициент обучения; A — мощность множества А.

Основанием логарифма выступает 2, так как необходимо классифицировать (сравнить попарно) каждый элемент множества А друг с другом.

2. Процесс манипуляции (manipulation), действия, восприятия. Манипулируя ментальными образами B, человек формирует команды (на основе

синтаксиса выработанного языка) и осуществляет целенаправленное воздействие на систему или анализ системы (управление). Процесс действия или восприятия характеризуем коэффициентом манипуляции кт: кт=^8А.

Основываясь на двух введенных коэффициентах, введем понятие информационной меры мен-тальности: коэффициент сложности управления (соиХго) Кс — количество ментальных операций, необходимых человеку для работы с системой управления, чтобы задействовать максимум операций за минимум времени:

Если мы хотим рассчитать производительность интерфейса по образу «закона Хика», то можно воспользоваться формулой:

где с и й — физические характеристики человека: с — время, затрачиваемое на ментальное сравнение одного символа; й — время, затрачиваемое на ментальное сравнение восьми символов.

По существу, можно предположить, что величины с и й совпадают (¿=с=й), так как являются показателями одной и той же производительности мозга («количество времени, затрачиваемое мозгом на обработку информации за один «такт») и тогда формула (1) примет вид:

Время (мс) = г4/3-1о^2А. (2)

На основании введенных характеристик мы можем проводить оценку сложности программного обеспечения. Для этого необходимо рассматривать программу как управляющую систему. Тогда можно говорить о метрике ментальной структурной сложности «алгоритмических» программ М5:

где ^ — количество переменных; М2 — количество операций всего; Р — количество подпрограмм.

Аналогично можно осуществить расчет объектно-ориентированных и потоковых программ, манипулируя понятием обучение и управление.

ОПТИМИЗАЦИЯ ХРАНЕНИЯ КОРПОРАТИВНЫХ ДАННЫХ

И.Н. Ефимов, д.т.н.; С.А. Жукова

(Чайковский технологический институт (филиал) ИжГТУ, Пермский край, г. Чайковский)

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

актов и внутрикорпоративных стандартов, предписывающих длительное хранение некоторых видов информации, иногда в течение 5-10 лет. А это значит, что компания, имеющая корпоративные данные скромного объема в 1 Тбайт и показывающая рост этих объемов на 60 % в год, через 10 лет будет хранить уже 110 Тбайт информации. Проблема взрывного роста объемов данных тесно

связана с другой проблемой — постоянно усложняющимися процессами управления хранением данных.

Управление информацией включает решение задач, связанных с организацией хранения, доступа, защищенности, производительности, то есть с обеспечением гарантированного уровня обслуживания. Размещение информации должно осуществляться, с одной стороны, на тех носителях, характеристики которых удовлетворяют заданным параметрам уровня обслуживания. С другой стороны, необходимо добиваться снижения затрат на их хранение. При организации хранения информации выбор носителя является определяющим (Жесткие диски вчера, сегодня, завтра //Системы хранения данных. 2005, №3).

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

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

Таким образом, можно сформулировать задачу, заключающуюся в оптимизации параметров многоуровневой среды хранения ИР с заданными локальными характеристиками каждого уровня и в то же время объединенными совокупностью ограничений на всю среду хранения. Оптимальным планом является номенклатура дисковых массивов и количество внешних запоминающих устройств (ВЗУ), составляющих дисковый массив, при минимальной суммарной стоимости хранения. В такой постановке задачу можно рассматривать как задачу математического программирования с блочной (многоуровневой) структурой. Одна система ограничений содержит все переменные и образует блок-связку, другая — лишь часть переменных и формирует блочную структуру (Глухов В.В., Медников М.Д., Коробко С.Б. Математические методы и модели для менеджмента. СПб., 2000).

С учетом вышесказанного дадим формализованное описание задачи. Пусть имеем P уровней и mp, p=1..P параметров, характеризующих ресурс, наличие каждого 1-го параметра составляет наи-

меньшее Ьр и наибольшее Вр¡, 1=1. тр (значения в соответствующих единицах измерений). Эти параметры предназначены для формирования пр типов дисковых массивов. Каждая единица 7-го типа дискового массива содержит ау единиц ¿-го параметра ресурса. Требуется определить, какие типы дисковых массивов и какое количество дисков необходимо для формирования многоуровневой среды хранения с наилучшими показателями для принятого критерия оптимальности.

Обозначим через Хр количество единиц у-го типа дисковых массивов на р-м уровне, тогда математическую постановку задачи можно записать в виде:

Оптимизация хранения данных

Хранилища данных: оптимизация неизбежна

Изменение цифровой картины мира в связи с повсеместным взрывным ростом количества информации требует новых подходов к построению хранилищ данных. Речь идет о качественно иной парадигме – вместо наращивания вычислительных мощностей систем хранения – их оптимизация.

По данным IDC, общие объемы информации, хранимые в мире на всех существующих цифровых носителях, могут превысить к началу 2012 года 1800 экзабайт. А по прогнозам экспертов Cisco, среднемесячный объем глобального IP-трафика достигнет уровня 44 экзабайта (528 экзабайт в год).

Объем российского рынка СХД, $ млн

Источник: IDC, 2011

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

Проектировать ответственно

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

Результат один – BI-система перестает удовлетворять заявленным требованиям по производительности. «И тогда встает вопрос о трансформации всей системы хранения данных, – говорит Гаяне Арутюнян, архитектор решений по бизнес-аналитике, IBM в России и СНГ. – Возможность оптимизации хранилища закладывается уже на этапе планирования системы, в процессе разработки ее архитектуры. Правильно спроектированная система должна предусматривать возможность масштабирования хранилища. Именно на этом этапе должны приниматься решения по всем ключевым вопросам: скорости передачи данных, времени их хранения, возможности интеграции данных из различных приложений, способам и механизмам их очистки. Такой подход позволит сделать хранилище данных изначально оптимизированным».

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

Подобные задачи были решены и в ходе проекта, выполненного компанией «Форс» в Федеральной миграционной службе РФ. Здесь была произведена консолидация больших объемов разнородных данных из нескольких учетных систем. Функциональные возможности хранилища были существенно расширены за счет интеграции с дополнительными источниками данных, реализована возможность ретроспективного и предиктивного анализа.

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

Виктор Митин, архитектор ECM-решений компании «Босс-Референт», отмечает, что прежде всего нужно максимально использовать инструментарий и функциональные возможности, заложенные в самой платформе. В качестве примера можно привести политики хранения, позволяющие определить, каким образом лучше хранить тот или иной контент. Для больших медиафайлов, доступ к которым сотрудникам требуется не часто, лучше использовать объемные, но не быстрые накопители. Для нормативно-справочной информации, наоборот, можно использовать быстрые и необъемные накопители. Конфиденциальная информация требует более защищенного хранения с резервным копированием на уровне устройства хранения. А некоторые документы после 3–5-летнего хранения подлежат удалению без возможности восстановления.

Храните только нужное

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

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

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

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

Что храним – то имеем

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

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

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

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

Однако, по словам Дмитрия Харлашко, чистка данных в самом хранилище требуется не всегда: «Сегодня никто из наших заказчиков не чистит данные в хранилищах. Это связано с тем, что даже очень большие объемы накопленной информации не влияют на производительность системы». Неактуальные показатели и редко востребованные виды отчетов просто помечаются соответствующим образом, но не удаляются из системы. «Временно отложить решение задачи по оптимизации хранилища можно. Для этого нужно либо существенно увеличить производительность серверного оборудования, либо отключить часть функционала хранилища (чаще всего на уровне витрин/отчетов).

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

Освобождение места в хранилище на компьютере Mac

Для экономии места на диске храните содержимое в iCloud или используйте встроенные инструменты для поиска и удаления крупных или ненужных файлов.

Функция оптимизации хранения в macOS Sierra и более поздних версий* экономит место на диске, храня содержимое в iCloud и делая его доступным по требованию. Когда требуется освободить место в хранилище, файлы, фотографии, фильмы, вложения электронной почты и другие редко используемые файлы автоматически отправляются в iCloud. Каждый файл остается в состоянии на момент последнего сохранения и загружается, когда вы его открываете. На компьютере Mac остаются файлы, которые недавно использовались, а также оптимизированные версии фотографий.

* Если вы еще не обновили свою операционную систему до macOS Sierra или более поздней версии, узнайте о других способах освобождения места в хранилище<.

Определение доступного объема хранилища на компьютере Mac

Перейдите в меню Apple  > «Об этом Mac», затем щелкните «Хранилище». Это обзор доступного места в хранилище на компьютере Mac, а также места, используемого другими категориями файлов:

Нажмите кнопку «Управлять», чтобы открыть окно «Управление хранилищем», показанное ниже. (Кнопка «Управлять» доступна только в macOS Sierra и более поздних версий.)

Управление хранилищем на компьютере Mac

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

Хранение в iCloud

Нажмите кнопку «Сохранить в iCloud», затем выберите один из этих вариантов:

• Папки «Рабочий стол» и «Документы». Хранить все файлы из этих двух папок в iCloud Drive. Когда требуется освободить место в хранилище, на компьютере Mac остаются только недавно использованные файлы, что позволяет легко работать без подключения к Интернету. Рядом с файлами, которые хранятся только в облаке, отображается значок загрузки , дважды щелкнув который можно загрузить исходный файл. Узнать больше об этой функции.
• Фото. Хранить оригиналы всех фотографий и видеозаписей с полным разрешением с помощью функции Фото iCloud. Когда требуется освободить место в хранилище, на компьютере Mac остаются только оптимизированные версии фотографий, занимающие мало места. Чтобы загрузить оригинал фотографии, просто откройте ее.
• Сообщения. Хранить все сообщения и вложения в iCloud. Когда требуется освободить место в хранилище, на компьютере Mac остаются только недавно использованные файлы. Дополнительные сведения о программе «Сообщения» в iCloud.

Для хранения файлов в iCloud используется емкость хранилища в текущей подписке iCloud. При достижении или превышении предельного объема хранилища iCloud просто купите дополнительное место в хранилище iCloud или освободите место в хранилище iCloud. Тарифные планы для хранилища iCloud начинаются от 50 ГБ за 0,99 доллара в месяц, и купить дополнительное место в хранилище можно непосредственно с устройства Apple. Подробные сведения о тарифах для вашего региона.

Оптимизация хранилища

Нажмите кнопку «Оптимизировать», затем выберите один из следующих вариантов.

• Автоматически удалять просмотренные фильмы и телешоу. Когда требуется освободить место в хранилище, фильмы или телешоу, купленные в магазине iTunes Store и уже просмотренные, удаляются с компьютера Mac. Щелкните значок загрузки рядом с фильмом или телешоу, чтобы загрузить его повторно.
• Загружать только недавние вложения. Программа «Почта» автоматически загружает только недавно просмотренные вложения. Можно вручную загрузить нужные вложения в любое время, открыв сообщение электронной почты или вложение, или сохранив вложение на компьютере Mac.
• Не загружать вложения автоматически. Программа «Почта» загружает вложение, только когда пользователь открывает сообщение электронной почты или вложение, либо сохраняет вложение на компьютере Mac.

При оптимизации хранения фильмов, телешоу и вложений электронной почты не используется хранилище iCloud.

Автоматическая очистка Корзины

Параметр «Очищать Корзину автоматически» удаляет без возможности восстановления файлы, которые находятся в Корзине более 30 дней.

Удаление мусора

Параметр «Удалить мусор» помогает находить большие файлы и файлы, которые, возможно, больше не нужны. Нажмите кнопку «Просмотреть файлы», затем выберите любые категории файлов на боковой панели, такие как «Программы», «Документы», «Создание музыки» или «Корзина».

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

Где находятся настройки для каждой функции

Кнопка для каждой рекомендации в окне «Управление хранилищем» влияет на одну или несколько настроек в других программах. Этими настройками также можно управлять непосредственно в каждой из программ.

• Если используется macOS Catalina, перейдите в меню Apple  > «Системные настройки», щелкните Apple ID, затем выберите iCloud на боковой панели: функция «Хранение в iCloud» активирует параметр «Оптимизировать хранилище Mac» справа. Затем щелкните «Параметры» рядом с iCloud Drive: функция «Хранение в iCloud» активирует параметр «Папки «Рабочий стол» и «Документы»». Чтобы полностью отключить iCloud Drive, снимите флажок iCloud Drive.
  В macOS Mojave или более ранних версии перейдите в меню Apple > «Системные настройки», щелкните iCloud, затем щелкните «Параметры» рядом пунктом iCloud Drive. Функция «Хранение в iCloud» активирует параметры «Папки «Рабочий стол» и «Документы»» и «Оптимизировать хранилище Mac».
• В программе «Фото» выберите «Фото» > «Настройки», затем щелкните iCloud. Функция «Хранение в iCloud» активирует параметры «Фото iCloud» и «Оптимизировать хранилище Mac».
• В программе «Сообщения» выберите «Сообщения» > «Настройки», затем щелкните iMessage. Функция «Хранение в iCloud» активирует параметр «Использовать Сообщения в iCloud».

• Если используется macOS Catalina, откройте программу Apple TV, выберите TV > «Настройки» в строке меню, затем щелкните «Файлы». Функция «Оптимизировать хранилище» активирует параметр «Автоматически удалять просмотренные фильмы и телешоу».
  В macOS Mojave или более ранней версии откройте iTunes, выберите iTunes > «Настройки» в строке меню, затем щелкните «Дополнительно». Функция «Оптимизировать хранилище» активирует параметр «Автоматически удалять просмотренные фильмы и телешоу».
• В программе «Почта» выберите «Почта» > «Настройки» в строке меню, затем щелкните «Учетные записи». В разделе «Информация учетной записи» справа функция «Оптимизировать хранилище» выбирает значение «Недавние» и «Нет» в раскрывающемся меню «Загрузить вложения».

Очищать Корзину автоматически: в Finder выберите Finder > «Настройки», затем щелкните «Дополнительно». Функция «Очищать Корзину автоматически» активирует параметр «Удалять объекты из Корзины по истечении 30 дней».

Другие способы автоматической экономии пространства в ОС macOS

При использовании macOS Sierra или более поздней версии компьютер Mac для экономии места на диске автоматически выполняет следующие дополнительные действия:

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

Освобождение места в хранилище вручную

Даже без использования функций оптимизации хранения в ОС macOS Sierra или более поздней версии вы можете выполнить ряд действий для освобождения места в хранилище.

• Музыка, фильмы и другие медиафайлы могут занимать много места в хранилище. Узнайте, как удалить музыку, фильмы и телешоу со своего устройства.
• Удалите файлы, в которых вы больше не нуждаетесь, переместив их в Корзину, а затем очистив ее. Ненужные файлы часто копятся в папке «Загрузки».
• Переместите файлы на внешнее устройство хранения.
• Сожмите файлы.
• Удалите ненужные сообщения электронной почты, выбрав в программе «Почта» пункт «Ящик» > «Стереть спам». Если вам больше не нужны письма в корзине, выберите «Ящик» > «Стереть удаленные объекты».

Мало памяти на iPhone? Есть выход

1. Проверьте свободное место

Для начала необходимо узнать объём свободной и занятой памяти. Эту информацию можно получить следующим образом:

Перейти в «Настройки» > «Основные».

Выбрать пункт «Хранилище и iCloud».

Здесь вы сразу увидите, сколько осталось свободного пространства. Следите за тем, чтобы на iPhone оставалось не меньше 1 ГБ.

Чтобы подробнее узнать о том, что больше всего занимает памяти, нажмите пункт «Управление» в разделе «Хранилище».

2. Удалите большие приложения

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

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

3. Удалите лишнюю музыку, видео и подкасты

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

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

4. Оптимизируйте iMessage

Если вы много общаетесь в iMessage, то у вас, скорее всего, скопилось немало принятых фотографий и файлов, которые занимают значительный объём памяти. Чтобы ненужные файлы не засоряли память iPhone, вы можете ограничить срок хранения истории сообщений до одного года или 30-ти дней.

Выбрать срок хранения переписки можно в разделе «Настройки» > «Сообщения» > «Оставить сообщения».

5. Храните фотографии правильно

Больше всего памяти на iPhone могут занимать фотографии и видеозаписи в приложении «Фото».

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

Перейдите в «Настройки» > «iCloud».

Выберите раздел «Фото».

Поставьте галочку напротив «Оптимизация хранилища на iPhone».

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

При необходимости исходные фотографии и ролики всегда можно загрузить на устройство.