Сколько хранятся файлы в облаке майл ру: Сколько хранится информация на облаке Майл.Ру?

На индексы и тела приходится только 15 % объема хранилища, тогда как 85 % занимают файлы. Итак, оптимизацию файлов (то есть вложений) стоит изучить подробнее. В то время у нас не было дедупликации файлов, но мы подсчитали, что это может уменьшить общий размер хранилища на 36%, потому что многие пользователи получают одни и те же сообщения, такие как прайс-листы из интернет-магазинов и информационные бюллетени из социальных сетей, которые содержать изображения и так далее. В этой статье я опишу, как мы внедрили систему дедупликации под руководством PSIAlt.

Дополнительная литература на SmashingMag:

• Как улучшить рабочий процесс электронной почты с помощью модульного дизайна
• Упрощение кодирования электронной почты с адаптивным HTML с помощью MJML
• Шаблоны электронной почты для веб-дизайнеров и разработчиков
• Дизайн для электронной почты (электронная книга) 90 028

Хранилище метаданных

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

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

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

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

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

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

1. Система получает запрос на удаление электронной почты.
2. Система проверяет индексы электронной почты.
3. Система видит наличие вложения (SHA-1).
4. Система отправляет запрос на удаление файла.
5. Произошел сбой, поэтому письмо не удаляется.

В этом случае письмо остается в системе, но счетчик уменьшается на 1. Когда система получает второй запрос на удаление этого письма, счетчик снова уменьшается — и мы можем столкнуться с ситуацией, когда файл все еще прикреплен к электронному письму, но счетчик уже на 0,

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

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

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

Рассмотрим пример. У нас есть файл с именем sha1 . Он загружается один раз, и письмо генерирует для него случайное (магическое) число, равное 345.

Затем приходит новое письмо с тем же файлом. Он генерирует собственное магическое число (123) и загружает файл. Новое магическое число добавляется к текущему значению магического числа (345), а счетчик увеличивается на 1. В результате в FileDB мы имеем магическое число со значением 468 и счетчиком, установленным на 2.

После того, как пользователь удалит второе письмо, магическое число, сгенерированное для этого письма, вычитается из текущего значения магического числа (468), а счетчик уменьшается на 1.

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

Теперь предположим, что что-то пойдет не так: второе письмо отправляет два запроса на удаление. Значение счетчика, равное 0, означает, что ссылок на файл больше нет, но магическое число, равное 222, сигнализирует о проблеме: файл нельзя удалить, пока данные не будут согласованы.

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

В качестве меры предосторожности, когда счетчик достигает 0, а магическое число нет (в нашем случае магическое число равно 222, а счетчик равен 0), файлу присваивается флаг «Не удалять». Таким образом, даже если — после серии удалений и загрузок — и магическое число, и счетчик каким-то образом станут 0, мы все равно будем знать, что этот файл проблемный и его нельзя удалять. Системе не разрешено генерировать магический одноранговый узел 0. Если вы отправите 0 в качестве магического числа, вы получите сообщение об ошибке.

Назад к FileDB. Каждая сущность имеет набор флагов. Планируете ли вы их использовать или нет, они вам понадобятся (если, скажем, файл нужно пометить как неудаляемый).

У нас есть все атрибуты файла, кроме того, где файл находится физически. Это место определяется сервером (IP) и диском. Таких серверов и два таких диска должно быть два. Мы храним две копии каждого файла.

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

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

Также нам нужно знать, сколько свободного места есть на каждом диске — отсюда и соответствующие поля.

Чтобы все работало быстро, FileDB и PairDB должны быть резидентными в оперативной памяти. Раньше мы использовали Tarantool 1.5, теперь нужно использовать последнюю версию. FileDB имеет пять полей (длиной 20, 4, 4, 4 и 4 байта), что в сумме дает 36 байтов. Кроме того, каждая запись имеет 16-байтовый заголовок, а также 1-байтовый указатель длины на поле, в результате чего общий размер записи составляет 57 байт. 93) = 179 ГБ

Всего нужно 800 ГБ оперативной памяти. И давайте не будем забывать о репликации, которая удваивает объем требуемой оперативной памяти.

Если мы купим машины с 256 ГБ ОЗУ на борту, нам понадобится восемь из них.

Мы можем оценить размер PairDB. Средний размер файла составляет 1 МБ, а емкость диска — 1 ТБ, что позволяет хранить около 1 миллиона файлов на одном диске; Итак, нам потребуется около 28 000 дисков. Одна запись PairDB описывает два диска. Таким образом, PairDB содержит 14 000 записей — ничтожно мало по сравнению с FileDB.

Загрузка файла

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

• inc(sha1, magic) увеличивает счетчик. Если файл не существует, он возвращает ошибку. Напомним, что нам также понадобится магическое число, которое поможет предотвратить некорректное удаление файла.
• upload(sha1, magic) следует вызывать, если inc вернул ошибку, что означает, что этот файл не существует и должен быть загружен.
• dec(sha1, magic) следует вызывать, если пользователь удаляет электронное письмо. Счетчик сначала уменьшается.
• GET /sha1 загружает файл по HTTP.

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

Имя команды сообщает нам длину заголовка, поэтому мы сначала читаем заголовок. Теперь нам нужно узнать длину файла origin-len . Для его загрузки необходимо выбрать пару серверов. Мы просто извлекаем все записи (несколько тысяч) из PairDB и используем стандартный алгоритм для поиска нужной пары: Берем отрезок длиной, равной сумме свободных мест на всех парах, случайным образом выбираем точку на этом отрезке, и выберите любую пару, которой принадлежит эта точка.

Однако выбирать пару таким образом рискованно. Предположим, что все наши диски заполнены на 90% — и тогда мы добавляем новый пустой диск. С большой долей вероятности все новые файлы будут загружаться на этот диск. Чтобы избежать этой проблемы, мы должны суммировать не свободное пространство пары дисков, а n-й корень этого свободного места.

Итак, мы выбрали пару, но наш демон потоковый, и если мы начинаем заливать файл в хранилище, обратного пути нет. При этом перед загрузкой реального файла мы сначала загрузим небольшой тестовый файл. Если тестовая загрузка прошла успешно, мы будем читать filecontent из сокета и загрузить его в хранилище; в противном случае выбирается другая пара. Хэш SHA-1 можно прочитать на лету, поэтому он также проверяется при загрузке.

Теперь рассмотрим загрузку файла из загрузчика на выбранную пару дисков. На машинах с дисками настраиваем nginx и используем протокол WebDAV. Приходит электронное письмо. В FileDB этого файла пока нет, поэтому его нужно залить на пару дисков через загрузчик.

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

Nginx, скорее всего, решит эту ситуацию правильно, но нам нужно контролировать весь процесс, поэтому мы сохраним файл со сложным именем.

Часть имени, выделенная красным цветом, — это место, где каждый загрузчик помещает случайное число. Таким образом, два метода PUT не будут перекрываться и загружать два разных файла. Как только nginx отвечает 201 (ОК), первый загрузчик выполняет атомарную операцию MOVE , которая указывает окончательное имя файла.

Когда второй загрузчик завершит загрузку файла и также выполнит MOVE , файл перезапишется, но ничего страшного, ведь файл один и тот же. Как только файл окажется на дисках, необходимо добавить новую запись в FileDB. Наша версия Tarantool разделена на два пространства. До сих пор мы использовали только space0 .

Однако вместо простого добавления новой записи в FileDB мы используем хранимую процедуру, которая либо увеличивает счетчик файлов, либо добавляет новую запись в FileDB. Почему? За то время, которое прошло с тех пор, как загрузчик убедился, что файл не существует в FileDB, загрузил его и приступил к добавлению новой записи в FileDB, кто-то другой мог загрузить этот файл и добавить соответствующую запись. Мы рассмотрели именно такой случай: на одно письмо указываются два получателя, поэтому загружать файл начинают два загрузчика; как только второй загрузчик завершает загрузку, он также добавляет новую запись в FileDB.

В этом случае второй загрузчик просто увеличивает счетчик файлов.

Теперь рассмотрим метод dec . У нашей системы есть две первоочередные задачи: надежно записать файл на диск и быстро отдать его клиенту с этого диска. Физическое удаление файла создает определенную нагрузку и замедляет выполнение этих двух задач. Вот почему мы выполняем удаление в автономном режиме. Сам метод dec уменьшает значение счетчика. Если последнее становится равным 0, как и магическое число, то это означает, что файл больше никому не нужен, поэтому мы перемещаем соответствующую запись из пробел 0 в пробел 1 в Tarantool.

декремент (sha1, магия) {
    прилавок--
    current_magic –= магия
    если (счетчик == 0 && current_magic == 0){
        двигаться (ша1, пробел1)
    }
}
 

Valkyrie

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

Но после вызова метода dec и перемещения файла по адресу space1 Valkyrie может потребоваться некоторое время, чтобы найти этот файл. Это означает, что за время между этими двумя событиями файл может быть перезалит и, таким образом, снова перемещен на space0 .

Вот почему Valkyrie также проверяет, существует ли файл в space0 . Если это так и pair_id соответствующей записи указывает на пару дисков, на которых работает данный экземпляр Valkyrie, то запись удаляется из space1 .

Если в space0 не найдено ни одной записи, то файл является потенциальным кандидатом на удаление. Однако между запросом к space0 и физическим удалением файла все еще есть временное окно, в котором новая запись, соответствующая этому файлу, может появиться в space0 . Чтобы справиться с этим, мы помещаем файл в карантин.

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

Теперь вспомним, что есть два диска, на каждом из которых работает экземпляр Valkyrie. Два экземпляра не синхронизированы. Отсюда вопрос: Когда запись должна быть удалена с пробел1 ?

Мы сделаем две вещи. Во-первых, для рассматриваемого файла давайте сделаем один из экземпляров Valkyrie мастером. Это легко сделать, используя первый бит имени файла: если он равен нулю, то disk0 является мастером; в противном случае disk1 является ведущим.

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

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

Итак, мы рассмотрели ситуацию, в которой демон Valkyrie находит файл с именем sha1 , и этот файл (являющийся потенциальным кандидатом на удаление) имеет соответствующую запись в space1 . Какие еще варианты возможны?

Предположим, что файл находится на диске, но в FileDB нет соответствующей записи. Если в рассмотренном выше случае мастер-экземпляр Valkyrie по каким-то причинам какое-то время не работал, это будет означать, что у слейва было достаточно времени, чтобы поместить файл в карантин и удалить соответствующую запись из пробел1 . В этом случае мы также помещаем файл в карантин, используя sha1.deleted.timestamp .

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

Что произойдет, если второй загрузчик загрузит файл в другую пару, чем первый? Он увеличит счетчик на space0 , но пара дисков, на которую был загружен файл, будет содержать несколько ненужных файлов. Что нам нужно сделать, так это убедиться, что эти файлы могут быть прочитаны и что они соответствуют ша1 . Если все в порядке, такие файлы можно сразу удалить.

Кроме того, Valkyrie может обнаружить файл, помещенный в карантин. Если карантин закончится, этот файл будет удален.

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

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

Результат

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

После внедрения новой системы нам удалось уменьшить общий размер на 18 ПБ: 9-38.

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

Особенности файловой системы, с которыми мы столкнулись при разработке механизма синхронизации с Облаком Mail.Ru | Антон Скогорев

 $ rm 1.txt && echo «hello» > 1.txt 

  wchar_t  имя[] = {0xDCA9, 0x2E, 0x74, 0x78, 0x74, 0x00}; 

  wchar_t  name2[] = { 0xFFFD, 0x2E, 0x74, 0x78, 0x74, 0x00 };  // «� .txt»  

 $ touch 1. txt 
 $ ls -i 
 999999999 1.txt 
 $ echo «hello» > 1.txt 
 $ ls -i 
 223 1.txt 

 $ touch 1.txt 
 $ ls -i 
 270 1.txt 
 $ rm 1.txt && touch 2.txt 
 $ ls -i 
 270 2.txt