Источник

Когда говорят «конец света», значит, хотят продать кукурузные хлопья,
а вот если говорят «без паники», тут уж дело серьезнее.
Стивен Кинг. «Буря столетия»

Говорят, что наиболее оптимистичные пессимисты верят в счастливый конец света. Применительно к телекому эта мысль имеет второе дно. Все учебные пособия по телекоммуникациям сходятся в одном: когда взамен медных линий стали применяться волоконно-оптические линии связи (ВОЛС) вкупе с лазерами, для отрасли наступило долгожданное и практически вечное счастье, по крайней мере в части обеспечения высокой пропускной способности для почти мгновенной (буквально со скоростью света) доставки множества информационных потоков. Так в отрасли началось время чудес. Да будет свет!

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

На Yelp хранится более 100 миллионов пользовательских фотографий, от картинок ужинов и причёсок до одной из наших последних фич, #yelfies. Эти изображения составляют основную часть трафика для пользователей приложения и веб-сайта, а их хранение и передача обходятся недёшево. Стараясь предоставить людям наилучший сервис, мы усиленно работали над оптимизацией всех фотографий и добились среднего уменьшения размера на 30%. Это экономит людям время и трафик, а также сокращает наши расходы на обслуживание этих изображений. Ах да, и мы сделали это без ухудшения качества фотографий!

Исходные данные

Yelp хранит пользовательские фотографии уже 12 лет. Мы сохраняем lossless-форматы (PNG, GIF) как PNG, а все остальные форматы в JPEG. Для сохранения файлов используются Python и Pillow, а загрузки фотографий начинаются примерно с такого сниппета:

# do a typical thumbnail, preserving aspect ratio
new_photo = photo.copy()
new_photo.thumbnail(
    (width, height),
    resample=PIL.Image.ANTIALIAS,
)
thumbfile = cStringIO.StringIO()
save_args = {'format': format}
if format == 'JPEG':
    save_args['quality'] = 85
new_photo.save(thumbfile, **save_args)

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

В тесте принимали участие следующие программы.

Для PNG:

1. Leanify 0.4.3 (x64)
2. pingo v0.79c
3. pinga v0.09
4. OptiPNG 0.7.6
5. pngout
6. PngOptimizer 2.5 (x64)
7. advpng aka AdvanceCOMP v1.23
8. ECT 0.6 (x64)
9. TruePNG 0.6.2.2
10. pngwolf-zopfli 1.1.1 (x64)

Для JPEG:

1. Leanify 0.4.3 (x64)
2. pingo v0.79c
3. ECT 0.6 (x64)
4. mozjpeg 3.2 (x64)
5. jhead 3.00
6. jpegoptim v1.4.4 (x64)
7. jpegtran

Для сохранения одного бита информации на жестком диске требуется порядка 100 тыс. атомов. 8 марта ученые из IBM Research представили результаты своего исследования, в котором показали, что можно сохранить такое же количество информации всего в одном атоме. Распространение этой технологии позволит записать музыкальный каталог Apple из 26 миллионов песен на запоминающее устройство размером с небольшую монетку.

Анонс новых функциональных возможностей HPE 3PAR StoreServ от 13 февраля 2017 года был назван некоторыми комментаторами в корпоративном блоге самым важным с момента запуска
семейства 3PAR 7000 четыре года назад. Это очень громкое заявление. За это время в индустрии многое поменялось, флеш-накопители обогнали жесткие диски по объемам продаж, а некоторые компании, производящие системы хранения, потеряли свою независимость или вообще разорились.

Интересно, что 13 февраля были объявлены, по большому счету, только программные улучшения. Единственная аппаратная новинка – это четырехпортовые адаптеры для семейства 3PAR 8000. Это важная вещь для тех, кто использует File Persona или iSCSI, но звания «самого важного анонса» не заслуживает. Так в чем же дело?

Мы в 1cloud стараемся освещать новости из мира технологий. Например, мы уже писали о необычных и революционных системах хранения данных и новых разработках, используемых в дата-центрах. Сегодня мы решили рассказать о том, что IBM Corp. обновила и дополнила свою линейку массивов хранения данных DS8880 их all-flash-версиями, имеющими большие объемы и поддерживающими работу с когнитивными и другими требовательными нагрузками.

Об авторе. Арчи Рассел (Archie Russell) — инженер бэкенда во Flickr

Одна из самых затратных статей в работе сервиса вроде Flickr — это хранение. За последние годы мы описывали различные техники для снижения стоимости: использование COS, динамическое изменение размера на GPU и перцептивное сжатие. Эти проекты были очень успешны, но мы продолжали терять много денег на хранении данных.

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

История затрат

Небольшие арифметические расчёты на салфетке показывают, что затраты на хранение представляют собой предмет реального беспокойства. В день с высокой посещаемостью пользователи Flickr загружают до 25 млн фотографий. Каждая из них требует в среднем 3,25 МБ, что в сумме составляет 80 ТБ. Наивно размещая их на облачном хостинге вроде S3 фотографии одного дня потянут на $30 тыс. в год и продолжат генерировать затраты каждый последующий год.

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


СХД системы резервного копирования на базе Commvault в дата-центре OST-2.

Пришло время рассмотреть все мифы и узнать где правда в вопросах дедупликации для массивов данных.



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

/ фото grover_net CC

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

На днях озадачился резервным копированием данных в облако. Нашёл подходящий сервис попробовал, и понял, что существует необходимость в сжатии бэкапа перед отправкой (думаю нет необходимости объяснять зачем). Не стал заморачиваться в поиске готовых решений и решил сам написать скромный скриптик для этой цели. Исходные файл или папка жмутся в .tar.xz с уровнем сжатия 9, что позволяет сохранить права и выдаёт хорошую компрессию на выходе (у меня снэпшот системы сжимается 4 раза). Результатом остался доволен, думаю для малого бизнеса, да и для личных целей многим пригодиться.

Возможности скрипта:

• гибкая настройка
• проверка на доступность ресурсов (источник, директория назначения, рабочая директория)
• проверка на файл блокировки (предотвращает выполнение если источник еще создаётся)
• вывод информации о сжатии (размер источника, размер архива, соотношение этих размеров)
• логирование и дебагинг (вывод дополнительной информации о процессе выполнения)
• возможность менять вывод (как в консоль и лог-файл, так и только в лог-файл)
• сохраняет и ротирует предыдущие архивы
• возможность форматирования текста вывода
• отправка e-mail-а в случае успешного и/или неуспешного завершения

Я не хочу разжигать очередную священную войну, но комментарии на мой последний пост о «сжатии» в RAR навеяли на некоторое количество мыслей и рассуждений, которые я хочу донести до сообщества. Но перед этим хочу отметить, что я работаю под Windows'ем, поэтому всё ниже изложенное будет касаться именно его. Плюс к прочему попрошу отнестись к топику, как к информации к размышлению, а не как к красной тряпке для быка. Итак, давайте поговорим о форматах сжатия данных с пользовательской точки зрения.

Я давно заметил (впрочем, вон там есть и свежий пример того), что некоторые видеоподкастеры предпочитают не заливать своё видео на некоторые популярные видеохостинги (такие, как YouTube или Google Video), заранее зная, что эти видеохостинги если и принимают видеозаписи любого формата, то у себя преобразуют их (со значительным сжатием) в формат FLV, после чего мелкие детали подкаста расплываются во Flash-видеопроигрывателе.

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

При помощи программы Any Video Converter Free Version (или других аналогичных простых бесплатных средств) можно заранее изготовить FLV-видеоролик необходимой длины и качества, чтобы затем закачать его на RuTube.