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

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



Когда я был ребёнком, меня всегда завораживали истории о древних цивилизациях. Я зачитывался книгами об Атлантиде, об истории открытия Трои Генрихом Шлиманом, о греках, римлянах, империи инков и Древнем Египте. И меня всегда восхищали их продвинутые знания в области астрономии, математики и медицины, их невероятные достижения, возведение этих огромных монументов и построение высокофункциональных социальных систем. Что ещё более невероятно, так это то, что всё это было сделано за тысячи лет до появления христианской культуры!

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

Single-page Application (SPA) – это набор статических JavaScript и HTML файлов, а так же картинок и других ресурсов. Поскольку они не изменяются динамически, опубликовать их в интернете очень просто. Для этого существует большое количество дешёвых и даже бесплатных сервисов, начиная с простого GitHub Pages (а для кого-то даже с narod.ru) и заканчивая CDN вроде Amazon S3. Однако мне нужно было другое.

Мне нужен был Docker-образ с SPA, чтобы его легко можно было запустить как в продакшене в составе Kubernetes-кластера, так и на машине back-end разработчика, который понятия не имеет, что такое SPA.

UPD 07.07.20: Посмотерть самому на то, что в итоге получилось, можно тут: https://github.com/alexxxnf/spa-docker-example

Я для себя определил следующие требования к образу:

• простота в использовании (но не в сборке);
• минимальный размер как с точки зрения диска, так и с точки зрения RAM;
• настройка через переменные окружения, чтобы образ можно было использовать в разных средах;
• максимально эффективная раздача файлов.

Сегодня я расскажу как:

• выпотрошить nginx;
• собрать brotli из исходников;
• научить статические файлы понимать переменные окружения;
• ну и конечно как собрать из всего этого Docker-образ.

Цель этой статьи поделиться моим опытом и спровоцировать опытных участников сообщества на конструктивную критику.

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

Возьмём классический пример — реестр Windows. Этот странный артефакт инженерной мысли представляет некое подобие иерархической БД для хранения абсолютно всех настроек — и системных, и приложений, и драйверов. Центральное бинарное хранилище заменило массу файлов .ini, разбросанных по всей системе и должно было упростить жизнь. Но вышло наоборот. И глядя на монструозный тормозящий конструкт, возникает только один вопрос: как это исправить? Ответ тоже простой: «Если вкратце, то никак». И так во всём. Мы создаём монстров, а потом не можем от них избавиться.

Привет Хабр! Хочу представить свою С/С++ библиотеку libral, которая с недавних пор стала open source под лицензией GPL3. Возможно кому-то она будет полезна. Библиотека предоставляет единый интерфейс к различным алгоритмам сжатия данных без потерь.
На данный момент поддерживаются библиотеки:

• libc — без сжатия
• zlib — www.zlib.net
• lzo — www.oberhumer.com/opensource/lzo
• snappy — code.google.com/p/snappy
• bzip2 — www.bzip.org

Любительница поэзии и программист Джулия Эванс написала красивую программку gzip.jl, которая показывает, как gzip осуществляет декомпрессию текста, сжатого с помощью алгоритма LZ77.

_{(лучше смотреть без звука)}


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

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

Часть первая – историческая.

Введение

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

В жизни каждого мужчины наступает момент, когда трафик растёт и сервак умирает необходимо задуматься об оптимизации. В последнем дайджесте PHP (№ 40) была упомянута ссылкой статья «How GZIP Compression Works». Исходя из статистики, 56% веб-сайтов используют GZIP. Я надеюсь, эта статья раскроет перед читателем достоинства этой технологии.

Недавно появился проект pako, это порт на яваскрипт известной библиотеки для компрессии и декомпрессии данных — zlib.

Очень любопытен результат тестов.

Еще недавно в моей памяти отложился анонс SQL Server 2016, которую лично презентовал Сатья Наделла. И вдруг, как снег на голову, стали одна за одной выходить свежие Community Technology Preview (на данный момент самая свежая версия – CTP3.1). По мере знакомства с новой версией, все больше хотелось поделиться впечатлениями…

Далее обзор новых синтаксических фишек SQL Server 2016: JSON, GZIP, DROP IF EXISTS, TRUNCATE TABLE по секциям, новые функции…

#1 – DROP IF EXISTS

CREATE TABLE dbo.tbl (
    a INT, b INT,
    CONSTRAINT ck CHECK (a > 1),
    INDEX ix CLUSTERED (a)
)

Если раньше перед удалением объекта приходилось делать проверку:

IF OBJECT_ID(N'dbo.tbl', 'U') IS NOT NULL
    DROP TABLE dbo.tbl

То сейчас появился более компактный синтаксис:

DROP TABLE IF EXISTS dbo.tbl

igzip — высокопроизводительная библиотека для выполнения сжатия gzip или DEFLATE. Она была изначально описана в статье Высокопроизводительное сжатие DEFLATE для процессоров с архитектурой Intel. В этой статье описывается связанный выпуск исходного кода, содержащий необязательные (во время сборки) оптимизации для повышения степени сжатия геномных наборов данных в форматах BAM и SAM. igzip работает примерно в 4 раза быстрее, чем Zlib при настройке на максимальную скорость, и с примерно такой же степенью сжатия для геномных данных. Мы считаем, что igzip можно схожим образом оптимизировать для других областей применения, где наборы данных отличаются от обычных текстовых данных.

CDN-провайдер CloudFlare в прошлом году разработал протокол Railgun для сжатия сетевого трафика. Бинарный протокол, написанный на языке программирования Google Go, передаёт хэши веб-страниц и diff’ы между ними, с поддержкой версионности. После внедрения этой технологии степень сжатия в некоторых случаях достигает 99.6%, что недостижимо с помощью gzip. Сайты 4Chan и Imgur после внедрения Railgun сократили некэшируемый трафик примерно на 50%.

Сейчас компания CloudFlare объявила, что поддержка протокола реализована также у Amazon Web Services и около 30 крупнейших хостинговых компаний. Поставить Railgun теперь как никогда просто: есть плагины для WordPress, Joomla, Drupal и прочих CMS, выпущены пакеты для большинства популярных дистрибутивов Linux и BSD.

Один из сотрудников Google в свободное время разработал новый алгоритм сжатия Zopfli, который на 3,7-8,3% эффективнее, чем стандартная библиотека zlib на максимальном уровне сжатия. Изначально алгоритм создавался для формата сжатия без потерь WebP, но его можно применять и для другого контента.

Новый алгоритм является реализацией стандартных алгоритмов Deflate, поэтому он совместим с zlib и gzip, а разархивирование данных уже поддерживается всеми браузерами. Достаточно подключить Zopfli на сервере. Например, его можно использовать с веб-сервером Nginx без изменений в модуле gzip, просто указав новый «прекомпрессор».

Правда, сжатие с помощью Zopfli требует примерно в 100 раз больше ресурсов, чем gzip, зато декомпрессия в браузере осуществляется с той же скоростью.

Часть 1

Техники сжатия данных

Для сжатия данных придумано множество техник. Большинство из них комбинируют несколько принципов сжатия для создания полноценного алгоритма. Даже хорошие принципы, будучи скомбинированы вместе, дают лучший результат. Большинство техник используют принцип энтропийного кодирования, но часто встречаются и другие – кодирование длин серий (Run-Length Encoding) и преобразование Барроуза-Уилера (Burrows-Wheeler Transform).

Проблема — в часы пик не справляется сетевой интерфейс с передаваемым объёмом данных.
Из доступных вариантов решения был выбран сжатие хранимых данных
tl;dr: экономия памяти >50% и сети >50%. Речь пойдёт о плагине для predis, который автоматически сжимает данные перед отправкой в redis.

Старые методы по-прежнему работают

[Обновление] Теперь я в каком-то списке спецслужб, потому что написал статью про некий вид «бомбы», так?

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

Когда я в возрасте 13 лет впервые захостил свою маленькую Linux-коробочку с доступом по SSH, я смотрел логи и каждый день видел IP-адреса (в основном, из Китая и России), которые пытались подключиться к моей сладенькой маленькой коробочке (которая на самом деле была старым ноутом ThinkPad T21 со сломанным дисплеем, жужжавшим под кроватью). Я сообщал эти IP их провайдерам.

На самом деле если у вас Linux-сервер с открытым SSH, то можете сами посмотреть, сколько попыток подключений происходит ежедневно:

grep 'authentication failures' /var/log/auth.log

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

tl;dr: меньше кода = меньше парсинг/компиляция + меньше передача + меньше распаковка

Сеть

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



Это может стать проблемой даже в странах первого мира, поскольку эффективный тип сетевого соединения у пользователя необязательно 3G, 4G или WiFi. Вы можете сидеть в кафе с WiFi, но быть подключённым к хотспоту через сотовую связь со скоростью 2G.

Ускорить доставку элементов фронтенда на устройство пользователя можно несколькими способами. Разработчик Артём Белов из самарского офиса норвежской компании Cxense попробовал самые многообещающие: HTTP/2, Server Push, Service Worker, а также оптимизацию в процессе сборки и на стороне клиента. Итак, что же нужно сделать, чтобы сократить время отклика приложения до минимума?

Выясняется, что алгоритмы сжатия существуют уже давно. Это произошло где-то в июне — видимо, где-то над Самарой пролетал метеорит и идея проверить новые алгоритмы сжатия, Zopfli и Brotli, пришла мне и парню из соседней компании. Больше чем уверен, вы читали его статью, это Александр Субботин. Статья разошлась на Medium, и он известен, а я нет.

Не так давно в Яндекс приезжал Геннадий Пехименко — профессор Университета Торонто и PhD Университета Карнеги-Меллон. Он прочитал лекцию об алгоритмах кодирования, которые позволяют обходить проблему ограничения памяти GPU при обучении глубоких нейронных сетей.


— Я вхожу в несколько групп Университета Торонто. Одна из них — Computer Systems and Networking Group. Есть еще моя собственная группа — EcoSystem Group. Как видно из названий групп, я не специалист непосредственно в машинном обучении. Но нейронные сети сейчас достаточно популярны, и людям, которые занимаются компьютерной архитектурой и сетями, компьютерными системами, приходится сталкиваться с этими приложениями на постоянной основе. Поэтому последние полтора-два года этой темой я тоже плотно занимаюсь.

Перевод статьи подготовлен в преддверии старта курса «C# ASP.NET Core разработчик».

---

В этом эпизоде моей серии статей о gRPC и ASP.NET Core мы рассмотрим подключение функции сжатия ответов (response compression) служб gRPC.

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

Эта статья является частью серии о gRPC и ASP.NET Core.

Когда следует включать сжатие в GRPC?

Короткий ответ: это зависит от ваших полезных нагрузок (payloads).
Длинный ответ:
gRPC использует protocol buffer в качестве инструмента сериализации сообщений запросов и ответов, отправляемых по сети. Protocol buffer создает двоичный формат сериализации, который по умолчанию предназначен для небольших эффективных полезных нагрузок. По сравнению с обычными полезными нагрузками в формате JSON, protobuf дает более скромный размер сообщений. JSON довольно подробный и удобочитаемый. В результате он включает имена свойств в данные, передаваемые по сети, что увеличивает количество байтов, которые должны быть переданы.