Почти четыре года назад мы начали проектировать принципиально новую распределенную почтовую систему Mailion, которая предназначена для корпоративных коммуникаций. Наше решение построено на Cloud Native микросервисной архитектуре, способно работать с более чем 1 000 000 пользователей одновременно и будет готово покрыть 100% потребностей крупных корпораций.
За время работы над Mailion команда выросла в несколько раз, и сейчас в продукт вовлечено почти 70 разработчиков. Мы прошли большой путь от идеи и первых прототипов до этапа пилотирования коммерческой версии. Настало время рассказать Хабру о том, что за продукт мы создаем, как устроена и работает наша почтовая система, какой стек технологий мы используем и почему за нашим решением будущее корпоративных коммуникаций. Погнали!
Хабр, привет! Меня зовут Антон Герасимов, я руковожу департаментом разработки в московском центре разработки компании МойОфис. Сегодня мы хотим представить Mailion принципиально новую российскую почтовую систему корпоративного класса, которая станет достойной альтернативой популярным иностранным решениям. Mailion обладает высокой нагрузочной способностью, беспрецедентными возможностями масштабирования и отказоустойчивости, а также требует минимального внимания со стороны системных администраторов.
Сейчас наша разработка находится в стадии бета-версии, но совсем скоро, по нашему плану до конца 2020 года, перейдет в статус пилотного внедрения коммерческого продукта.
По большей части эта статья содержит общие сведения рассказать о сложном программном продукте в одной публикации просто невозможно. Я планирую сделать серию статей с рассказом про ключевые технологии. А пока для вашего удобства предлагаю такое содержание:
МойОфис запустил открытый сервис, где любой желающий может поработать с текстовыми и табличными документами, а также оценить интерфейс, ключевые функциональные возможности и практическое удобство наших редакторов. Без скачивания каких-либо файлов, регистрации и установки браузерных расширений: для запуска демонстрационной версии веб-редакторов достаточно перейти по ссылке в браузере на вашем ПК или ноутбуке. В процессе работы с сервисом все документы остаются на компьютерах пользователей.
Привет, Хабр! В новом релизе 2021.01 мы провели комплексную работу над оптимизацией линейки продуктов МойОфис. Часть наиболее любопытных изменений коснулась технологии автономного модуля редактирования (АМР). Для иллюстрации возможностей AMP мы интегрировали модуль в корпоративный сайт МойОфис, и теперь работа с текстовым и табличным редакторами доступна всем посетителям сайта прямо из окна их браузера.
Если вашим ИТ-системам необходимы инструменты редактирования документов, вы можете запросить комплект средств для разработчиков, который позволит интегрировать АМР в собственные решения. Статус технологического партнера МойОфис откроет вам доступ к библиотеке справочных материалов по нашим продуктам и ускорит вашу разработку.
Что такое АМР?
АМР специальная версия редакторов МойОфис, которая разработана для веб-сервисов и интеграции в приложения сторонних разработчиков для работы с документами.
AMP не требует отдельного сервера и содержит полный набор средств редактирования и форматирования, при этом не имеет функций совместной работы.
Редактор в АМР обрабатывает только те файлы, которые передает ему информационная система приложение или сервис, куда интегрирован сам модуль АМР.
Что умеют веб-редакторы МойОфис на базе AMP?
Пользователям пробной версии веб-редакторов МойОфис доступно создание, открытие, редактирования и форматирования текстовых и табличных файлов. При этом можно вставлять изображения (а также копировать изображения в буфер обмена и вставлять их в другие приложения), таблицы, оглавление и колонтитулы в тексты, использовать формулы и строить графики в электронных таблицах.
Сохранение файлов осуществляется в форматах ODT, ODS, DOCX, XLSX, PDF.
В интерфейсе доступны режим рецензирования и работа с файлами в режиме правок. В зависимости от настройки информационной системы, в которую интегрирован АМР, открытие документа может происходить в режиме постоянного рецензирования без возможности его отключения. (Пример: система, в которую встроен АМР, управляет режимом работы с документом и выдает права принимать или отклонять исправления отдельным пользователям системы). Все правки и комментарии, которые будут оставлены в документе в режиме рецензирования, сохранятся в документе.
Печать документов осуществляется с помощью средств браузера и доступна прямо из интерфейса AMP. Для табличных документов реализована возможность предварительной настройки параметров печати размера и ориентации страницы, масштаба и области печати, ширины полей, а также отключение печати пустых страниц.
Перейти к работе с веб-редакторами МойОфис можно в том числе со страниц пробных версий продуктов на нашем сайте. При открытии страницы пробных версий с планшета или смартфона, пользователю будет предложено скачать бесплатное мобильное приложение МойОфис Документы, которое позволяет работать с текстами и таблицами в удобном для мобильного устройства формате.
Предлагаем читателям блога МойОфис ознакомиться с веб-редакторами и поделиться мнением в комментариях, а разработчикам программных продуктов оценить возможности интеграции АМР в свои ИТ-решения и стать технологическими партнерами. Будем рады вашей обратной связи по новому сервису!
Универсального решения нет, каждое из них соответствует своему контексту, целям и задачам использования.Поэтому при работе над панелью инструментов в редакторах документов МойОфис мы выработали свой подход, учитывающий плюсы и минусы аналогичных продуктов, привычки пользователей, а также цели, задачи и контекст использования.
Книги по архитектуре
Роберт Мартин (Robert C Martin). Чистая архитектура, Чистый код
Мартин Фаулер (Martin Fowler). Рефакторинг. Улучшение проекта существующего кода
Инструменты
для проектирования архитектуры
UML используем для проектирования.
PlantUML (PUML) библиотека и сервис, которые позволяют в текстовом виде описывать UML-диаграмму. Его можно хранить в git, следовательно можете к процессу обновления и обсуждения этих диаграмм подключить те инструменты, которые используете для работы с обычным кодом.
Кратко
- Проект с историей хорошее место для роста разработчика, если ему становится интересно заниматься не только написанием кода, но и задачами, которые помогут развиваться не только как программисту.
- В проектах с бэкграундом проблему создает не код, а люди, то есть такой менеджмент, когда от вас требуют чего-то очень быстрого и постоянно как в геймдеве, например.
- Работа с наследием точно должна быть комфортной для вас в первую очередь. Комфорт создает не код, а люди, потому что код вы переписать сможете, а исправить людей гораздо сложнее.
Недавно на Хабре вышли две статьи про новую корпоративную почтовую систему Mailion от МойОфис (1, 2) уникальную российскую разработку, которая отличается беспрецедентными возможностями масштабирования и способна работать в системах с более чем 1 миллионом пользователей.
Несложно подсчитать, что для обслуживания такого числа пользователей потребуется колоссальный объем дискового пространства вплоть до десятков петабайт. При этом почтовая система должна уметь быстро обрабатывать эту информацию и надежно хранить её. Сегодня мы объясним общие принципы организации хранения данных внутри почтовой системы Mailion и расскажем, к каким оптимизациям мы прибегли, чтобы значительно снизить количество операций ввода/вывода и сократить требования к инфраструктуре.
Хабр, привет! Меня зовут Виталий Исаев, я занимаюсь разработкой объектного хранилища почтовой системы Mailion. Этой статьёй мы открываем цикл публикаций, посвящённых архитектуре нашего хранилища, его масштабированию, отказоустойчивости и устройству его внутренних подсистем.
Структура электронного письма формировалась в течение последних пятидесяти лет. Этапы её развития зафиксированы несколькими стандартами. Первое электронное письмо было отправлено между компьютерами системы ARPANET ещё в 1971 г. Но разработчикам стандартов потребовалось ещё 11 лет на разработку RFC 822, который стал прообразом современного представления электронной почты. В нём был описан общий коммуникационный фреймворк текстовых сообщений. В это время электронное письмо рассматривалось просто как набор текстовых строк, а передача структурированных данных (изображений, видео, звука) не подразумевалась и никак не регламентировалась.
Примерно в середине 1990-х родилась концепция специальных расширений MIME (RFC 2045, RFC 2046, RFC 2047), которые позволили включать в состав электронного письма бинарные форматы данных в закодированном виде.
В 2001 году новый стандарт RFC 2822 отменил некоторые устаревшие положения RFC 822, и ввёл понятие частей сообщения message parts, или, проще говоря, "партов". А благодаря MIME появилась возможность создавать multipart-письма, которые могли бы состоять из множества частей различных типов. Наиболее актуальным стандартом электронной почты является RFC 5322, он был разработан в 2008 году.
На сегодняшний день типичное почтовое сообщение состоит из заголовка и "партов". В заголовке в структурированном виде хранятся метаданные, такие как идентификатор письма, электронные адреса отправителя и получателя, дата отправки и другие служебные поля. К "партам", которые составляют само тело письма, относятся основной и альтернативный текст, изображения, прикреплённые файлы. Объём заголовочной части письма редко превышает 1 килобайт текста, тогда как размер тела письма ограничен лишь лимитами почтовой системы и может достигать десятков и даже сотен мегабайт.
Когда письма поступают в Mailion по любому из транспортных каналов (SMTP, IMAP, API), они не сохраняются как единое целое, а разбиваются на составные части. В Mailion мы извлекаем информацию о структуре письма и некоторые другие служебные данные, и затем сохраняем их в хранилище метаинформации. "Парты" писем, которые составляют основной объем данных, направляются в объектное хранилище.
Рис. 1. Разбиение электронного письма на фрагменты и сохранение по частям в хранилище метаданных и объектном хранилище.
Поток данных, который проходит через почтовую систему, отличается следующими важными особенностями:
Письма часто пишутся и ещё чаще читаются. Работа пользователей с почтовой системой порождает огромное количество операций ввода-вывода в хранилище.
Письма иммутабельны однажды отправленное или полученное письмо хранится в почтовой системе в неизменном виде на протяжении всего своего жизненного цикла. Черновики писем могут редактироваться, но сами письма никогда.
Многие письма частично совпадают по содержимому. Например, в длинной цепочке писем могут встречаться взаимные цитирования. Это порождает совпадающие фрагменты текста. Пересылка писем со вложениями приводит к дублированию вложенных файлов. Кроме того, всеми сотрудниками одной компании используется в подписи идентичная картинка с логотипом. В корпоративной среде помимо этих совпадений бывают и другие, которые создаются информационными системами предприятия, например, шаблонными письмами с ответами календаря или системы управления задачами.
В корпоративной среде часто встречаются полные дубликаты писем. Это связано как с широким применением рассылок (например, отправка новостей компании всем сотрудникам), так и с практикой использования копий и скрытых копий. Наконец, у каждого письма всегда есть минимум две копии для отправителя и получателя, и в случае внутрикорпоративной переписки обе копии хранятся в одной и той же почтовой системе.
После детального анализа особенностей потока данных мы сформулировали основной принцип проектирования хранилища: оно должно эффективно проводить дедупликацию почтовых сообщений. Правильная работа с дубликатами позволяет экономить не только дисковое пространство, но и операции ввода-вывода за счёт кэширования наиболее часто встречающихся фрагментов данных. Недорогие, но ёмкие HDD-накопители не отличаются высокой пропускной способностью, их показатели IOPS часто являются лимитирующим фактором для производительности всей системы. Благодаря дедупликации данных увеличивается не только экономическая эффективность хранилища, но и его производительность.
Представьте, что вам необходимо выполнить массовую рассылку письма по компании с 1000 сотрудников. В подписи отправителя письма находится картинка с логотипом компании, её размер составляет 256 Кб. Давайте оценим затраты ресурсов на чтение рассылки всеми сотрудниками компаниями.
В классических почтовых системах mbox-формата, в которых копии писем разных пользователей хранятся в разных файлах, данная операция будет порождать поток произвольных чтений (random read) с диска. Стандартные HDD в этом режиме работы выдают производительность около 100 IOPS. При размере блока в 4 Кб чтение картинки в худшем случае, когда блоки файла при записи не были размещены последовательно, потребует 64 операции чтения. Следовательно, для чтения всех писем с картинками будет необходимо выполнить 64000 операции (64 операции * 1000 пользователей). Для того, чтобы обработать данную операцию за 1 секунду, потребуется 640 HDD одновременно. Если же в системе присутствует только один накопитель, то он будет работать со 100% утилизацией более 10 минут.
Дедупликация позволяет обойтись лишь однократной загрузкой картинки с диска, после чего она попадёт в кеш и при дальнейших запросах будет отдаваться напрямую оттуда. Экономическая эффективность системы с дедупликацией многократно превышает эффективность системы с классической архитектурой.
Безусловно, дедупликация не бесплатна и сильно усложняет процесс записи и чтения, налагает дополнительные расходы на CPU и RAM. Однако иммутабельность данных частично компенсирует этот рост сложности. Благодаря неизменности писем, можно не поддерживать операцию записи по смещению (при необходимости его можно реализовать по принципу copy-on-write) и сохранять интерфейс хранилища максимально простым. На данный момент он состоит из записи, чтения, удаления данных и ещё пары вспомогательных методов.
На момент старта проекта Mailion ни в одном из известных нам объектных хранилищ с открытым кодом подобные оптимизации не были реализованы. Например, в Minio отказались от реализации дедупликации ещё в 2017 г. Попытки доработки других готовых решений, таких, как Elliptics, Riak или Swift, при очевидных и значительных трудозатратах также не гарантировали успеха. ZFS в течение долгих лет не поддерживалась в Linux и по причине лицензионных разногласий официально не может поставляться в дистрибутивах, отличных от Oracle, да и к производительности дедупликации в этой файловой системе есть вопросы.
В Ceph дедупликация появилась в 2019 г., но Ceph имеет репутацию сложного для эксплуатации хранилища с большим количеством историй неуспеха. Многим известны истории отказа Ceph в Росреестре и DigitalOcean и даже потеря бизнеса компанией DataMouse. В багтрекере Ceph можно найти большое количество тикетов с зависаниями, сегфолтами и другими ошибками. Причем некоторые баги, даже в статусе Immediate, могут не устраняться по полгода и больше. Это наводит на мысли о том, что Ceph дорог не только с точки зрения эксплуатации, но и с точки зрения разработки: ресурсы разработчиков будут уходить на стабилизацию самого Ceph, а не на разработку собственного продукта.
Мы убедились в отсутствии подходящих для наших задач продуктов с открытым исходным кодом, и решили разработать собственное хранилище с поддержкой дедупликации в самом ядре системы. Мы вдохновились программной статьей аналитиков из компании Storage Switzerland, в которой кратко описываются принципы проектирования современных программно-ориентированных хранилищ, и решили назвать наш продукт Dispersed Object Store (DOS). Код DOS написан на языках Go (95%), C и C++ (5%).
Иерархия сущностей DOS включает в себя четыре уровня:
документы;
версии документов;
чанки (chunks);
сегменты.
Версия документа является синонимом традиционного понятия объект. Каждый успешный запрос на запись в DOS порождает новую версию определённого документа. В зависимости от бизнес-логики клиента каждый документ может обладать либо единственной версией, либо целой коллекцией версий. При этом версии одного документа могут быть упорядочены, например, по значению логического времени создания версии.
Каждый документ со стороны публичного API адресуется идентификатором, который состоит из пространства имён (namespace) и собственно ключа (key). В рамках одного пространства имён все ключи являются уникальными. Непосредственно в хранилище из внешнего идентификатора и с помощью криптографической хеш-функции генерируется внутренний ключ (storekey), который обладает свойством глобальной уникальности. Во внутренних API все документы адресуются уже через storekey.
В DOS применяется стриминговая запись. В рамках обработки одного запроса на запись поток данных, который поступает на сервер, частично буферизуется в оперативной памяти и только по накоплению определенного объёма сохраняется в персистентном хранилище. Полной буферизации крупных файлов не происходит никогда, поскольку это привело бы к чрезмерным расходам RAM. Частичная буферизация данных (но не только она) предопределяет в модели данных DOS появление чанков крупных байтовых последовательностей. Каждая версия документа может состоять из одного или нескольких чанков.
Чанки, в свою очередь, с помощью специальных алгоритмов разделяются на сегменты более короткие байтовые последовательности. Они выступают в роли элементарных единиц хранения в DOS. У сегментов тоже есть свои идентификаторы, ими являются хеши от их содержимого. В каком-то смысле, внутренним адресом данных в DOS являются сами данные (эта идея не нова и используется, например, в P2P-файловом хранилище IPFS).
Все документы, версии, чанки и сегменты в совокупности формируют внутренние метаданные DOS. Для персистентного хранения метаданных (документов и сегментов) вводятся индексы. В качестве хранилища индексов используется широко известная встраиваемая key-value база данных RocksDB. Индексы с метаданными должны размещаться на быстрых SSD дисках.
В свою очередь раздробленные на сегменты данные размещаются в бэкендах хранения на медленных HDD дисках. На ранних этапах разработки для этого использовался простой файловый бэкенд, в котором каждое тело сегмента хранилось в отдельном файле. Впоследствии был разработан более совершенный блобовый бэкенд, в котором сегменты объединяются в крупные файлы (блобы), тем самым экономятся файловые дескрипторы и снижается количество переключений контекста между пространством пользователя и пространством ядра.
Рис. 2. Иерархия внутренних сущностей DOS.
В нашей системе дедупликация реализована на двух разных уровнях: на уровне сегментов (блочная дедупликация); на уровне версий документов.
Каждый из этих подходов имеет свои плюсы и минусы. Дедупликация на уровне сегментов достигается за счёт совместного использования одних и тех же сегментов различными версиями документов. Каждый сегмент поддерживает внутри себя счётчик ссылок (reference counter) со стороны версий документов. В момент записи новой версии документа поток входящих данных разбивается на сегменты. Для каждого из них по индексу выполняется проверка существования. Если подобный сегмент встречается впервые, то выполняется его запись в бэкенд. Если же сегмент уже сохранялся ранее, то он просто получает новую ссылку со стороны только что созданной версии документа. Тем самым обеспечивается хранение каждого сегмента в единственном экземпляре.
Этот способ дедупликации работает постоянно и позволяет обнаруживать совпадения между разными версиями документов, которые могут отличаться по размеру, времени создания, типу данных и другим параметрам. Он вносит значительный вклад в оптимизацию дискового пространства и операций ввода-вывода. Популярные сегменты, постоянно использующиеся при обработках запроса на чтение, почти наверняка окажутся в кешах.
Однако есть и минусы: существенные накладные расходы на поддержание счётчиков ссылок. Например, одна ссылка потребует от 8 до 40 байт, поэтому для очень популярных сегментов с сотнями тысяч ссылок такие счётчики могут достигать размера в несколько десятков мегабайт. Индекс сегментов раздувается, тяжёлые сегменты становятся слишком большими для пересылки по сети, в результате начинает возрастать время отклика. Для решения этой проблемы приходится вводить сложную систему шардирования счётчика ссылок.
В результате хеширования содержимого сегмента создается идентификатор, обладающий свойством глобальной уникальности. Коллизии идентификаторов сегментов неизбежно приведут к повреждению данных, поэтому для хеширования используется криптографическая функция BLAKE3. Она вносит весомый вклад в потребление CPU при обработке запроса на запись. В случае, если клиент готов ради экономии CPU пожертвовать глобальной уникальностью (например, для короткоживущих данных в небольших инсталляциях хранилища), он может выбрать более быстрые хеш-функции, не обладающие свойством криптографической стойкости.
Второй способ дедупликации несёт значительно меньше накладных расходов, но требует более глубокого вовлечения клиента. Внутрь версии документа встроена очень компактная структура счётчика копий (copy counter). Клиенту DOS предоставляются методы для проверки наличия версии документа и модификации её счётчика копий. Если бизнес-логика клиента позволяет выявить ранее записанную версию, то её повторная запись сводится лишь к дешёвой операции инкремента счётчика копий. В почтовой системе именно так реализовано сохранение партов письма: клиент использует хеш от содержимого парта для построения идентификатора документа, проверяет наличие документа с таким идентификатором и при его наличии просто увеличивает счётчик копий нужной версии на единицу. Иммутабельность данных версии документа даёт гарантию того, что все накопленные инкременты счётчика копий версии относились к одним и тем же данным.
Дедупликация на уровне версий документов фактически обеспечивает ещё один (очень экономичный) вариант записи, при котором оптимизируется не только дисковое пространство и операции ввода-вывода, но ещё и CPU и RAM, а также снижается нагрузка на сеть за счёт облегчения запросов.
Рис. 3. Два уровня дедупликации данных в DOS.
Если сегмент существует в единственном экземпляре, то что произойдёт в случае его потери? Если диск, на котором хранится популярный сегмент выйдет из строя, будет ли это означать невозможность чтения всех ссылающихся на него версий?
Для борьбы с этой проблемой в хранилищах самых разных классов (компакт-диски, RAID-массивы, промышленные СХД) традиционно используются коды коррекции ошибок. Наибольшую популярность получили коды Рида-Соломона (Подробнее в статьях на Хабре: 1, 2, 3).
В DOS во время записи чанк разбивается на заданное количество сегментов равного размера (data segments, d). С помощью кодирования Рида-Соломона из сегментов данных генерируются избыточные сегменты (parity segments, p). При потере любые p из d + p сегментов могут быть восстановлены из имеющихся d с помощью обратной операции. Таким образом, отказоустойчивость приобретается путём дополнительных расходов дискового пространства. Конкретные значения параметров определяются на этапах внедрения и эксплуатации системы. Исходя из потребностей в отказоустойчивости инсталляции, пользователи могут выбирать между стоимостью хранения и возможностью восстановления (часто встречаются комбинации d + p = 2 + 1 и d + p = 5 + 2).
Для гарантии восстановления каждого чанка DOS размещает все входящие в его состав сегменты на бэкенды, которые находятся на независимых HDD. Таким образом, при выходе из строя одного диска не произойдет повреждение сразу нескольких сегментов одного чанка.
При чтении чанка выполняется вычитывание не только сегментов данных, но и избыточных сегментов. Если какие-то из сегментов оказались потеряны, удалены, либо была нарушена их целостность, выполняется попытка их регенерации и повторного сохранения.
Конечно, коды Рида-Соломона могут спасти далеко не всегда. Поэтому в DOS имплементирован ещё один способ восстановления данных: при запросе на инкремент счётчика копий клиент может получить ответ о том, что версия была повреждена и что надо заново записать точно такую же. В этом случае вновь записанная версия восстановит старые поврежденные.
Отдельного рассмотрения требует тема отказоустойчивости метаданных. Мы вернёмся к ней позже в публикациях, посвящённых кластеру DOS.
Во время обработки запроса на запись DOS буферизует первые несколько килобайт из входящего потока и отправляет их в библиотеку сигнатурного анализа файлов. Оттуда хранилище получает вычисленный MIME-тип данных. В контексте DOS все возможные MIME-типы подразделяются на группы форматов. Для каждой из групп в DOS организован отдельный конвейер преобразований (pipeline) и разные оптимизации.
Текстовые данные хорошо сжимаются. Для некоторых текстов с помощью алгоритмов ZSTD, Snappy, Brotli удаётся добиться более чем двукратного сжатия. Это существенная экономия дискового пространства и операций ввода-вывода, и она стоит дополнительных затрат CPU на компрессию и декомпрессию.
Для текстовых данных также можно повысить вероятность обнаружения дубликатов с помощью алгоритма content-defined chunking (CDC). Сущность алгоритма заключается в вычислении хеша Рабина в небольшом окне, скользящем по входящему потоку данных. В позициях, на которых вычисленный хеш принимает определённое значение, ставится граница между чанками. В результате поток разбивается на небольшие чанки разных размеров, однако при этом повышается вероятность обнаружения аналогичных чанков в других версиях с частично совпадающим содержимым.
В отношении данных бинарных форматов, по которым нет понимания, как правильно организовать оптимизацию, применяется подход к работе с обычной байтовой последовательностью. Такой поток данных быстро разбивается на крупные чанки одного размера и в неизменённом виде отправляется на хранение в бэкенд.
Рис. 4. Различия в конвейерной обработке бинарных и текстовых данных в DOS.
Таким образом, конвейер для бинарных данных настроен на повышение пропускной способности сервера и на снижение времени отклика. А конвейер текстовых данных оптимизирует уровень потребления дискового пространства и IOPS ценой повышенного потребления CPU. Насколько же эффективны эти оптимизации?
Мы выполнили эксперименты с помощью генератора текстов, созданного коллегами из отдела разработки поискового ядра, и показали, что для характерного в корпоративной среде потока данных можно достичь примерно двукратного сокращения потребления дискового пространства.
В систему сохраняется 10000 писем. Письма состоят только из текста и не включают в себя какие-либо бинарные объекты. Медианный размер письма около 500 Кб. При этом 70% писем имеют 50% совпадающих данных, остальные полностью уникальны. Полностью эквивалентные письма отсутствуют, поскольку они дедуплицировались бы на уровне счётчиков копий и сильно завысили бы итоговый результат. Настройки кодирования Рида-Соломона d + p = 2 + 1, избыточность данных составляет 50%.
При прохождении через текстовый конвейер объем данных изменяется следующим образом: Входящий поток разделяется на чанки и компрессируется со средним коэффициентом сжатия 2.3. Затем кодирование Рида-Соломона увеличивает количество данных в 1.5 раза. Дедупликация cегментов (блочная дедупликация) снижает полученный с учётом избыточности объем данных в 1.17 раза.
Итоговое отношение записанных данных к хранимым данным составляет 2.3 * 1.17 / 1.5 = 1.79. При этом в нашей модели количество метаданных составляет 0.2% от количества данных, однако этот показатель очень вариативен и сильно зависит как от настроек конвейера, так и от характера и количества самих данных.
В условиях совместного владения сегментами удаление версии документа становится нетривиальной операцией. Её нужно проводить очень аккуратно, чтобы, с одной стороны, не удалить данные, которые ещё кому-то нужны, а с другой не допустить утечек дискового пространства. Связи между всеми сущностями в DOS можно представить в виде большого ациклического ориентированного графа, в котором начальными вершинами являются документы, а конечными вершинами - сегменты. Также есть и промежуточный уровень версий документов. Для каждой из сущностей действуют свои правила удаления: Документ удаляется, если не содержит версий. Версия документа удаляется, если её счетчик копий равен нулю либо истекло время её жизни (TTL). Сегмент удаляется, если не имеет ссылок со стороны версий документов.
Клиент напрямую работает лишь с версиями документов; доступный клиенту метод удаления позволяет декрементировать счётчик копий у конкретной версии. Далее в действие приходят два асинхронных сборщика мусора (GC), один из которых проходит по индексу документов, а другой по индексу сегментов. GC документов удаляет версии с обнулённым счётчиком копий или истекшим TTL, собирает пустые документы и очищает счётчики ссылок сегментов от идентификаторов удаляемых версий. GC сегментов удаляет сегменты с пустыми счётчиками ссылок. Оба GC запускаются в фоновом режиме в периоды, свободные от пользовательской нагрузки.
Рис. 5. Иллюстрация работы сборщиков мусора (1 - граф связей в исходном состоянии; 2 - клиент декрементирует до нуля счётчик копий у одной из версий; 3 - GC документов удаляет версию и владеющий ей документ, GC сегментов удаляет сегмент без ссылок; 4 - граф связей в итоговом состоянии).
Хранение больших объёмов электронной почты - крайне непростая и ресурсоёмкая задача. Однако производительность и экономическую эффективность почтовой системы можно значительно увеличить, если реализовать дедупликацию и компрессию электронных писем. Если вам близка эта тема, и вы тоже хотите создавать уникальные российские программные продукты, то приходите на работу в МойОфис. Прямо сейчас нашей команде требуется разработчик бэкенда откликайтесь, возможно, это именно вы.
В этой статье мы рассмотрели ключевые оптимизации, которые реализованы в объектном хранилище DOS. В дальнейших публикациях мы продолжим описание его архитектуры, а сейчас будем рады обсудить с вами возникшие вопросы в комментариях.
Я давно хотела попробовать занятия йогой, но как-то на это все не было времени. Онлайн-приложение стало для меня классной возможностью не выходя из дома освоить новый вид спорта.
Елена К.
Мне всегда нравились кардионагрузки работа сидячая, за день движения практически нет. Но посещение качалок никогда не приносило удовольствия, поэтому несколько лет назад я приобрел велотренажер, пару гантелей, ролик для пресса и старался хотя бы через день выполнять упражнения по 30-40 минут. Если есть свободное время, предпочитаю передвигаться по городу пешком, в позапрошлом году меня увлекла йога. С приходом карантина открыл для себя бег. Я живу возле лесопарка, и пробежки удобно совершать и утром, и вечером. В лесу можно тренироваться подальше от людей, такие нагрузки полезны для сердца и легких. Во время бега обожаю слушать подкасты на английском, тем самым еще и развивая listening skill. Так и живу в хорошую погоду бегаю, в плохую у меня велотренажер и занятия на домашнем инвентаре.
Cloud Sport порадовал разнообразными упражнениями на любой вкус, пожелания и настроение всегда можно выбрать то, что подойдет тебе именно сегодня.Приложение импонирует мне и тем, что в нем все видео с реальными людьми и реальными тренировками, а не пластилиновыми качками, которые делают какие-то повторяющие движения.После сложного рабочего дня просто выдохнуть и перезагрузиться самое то. Да и утренние 15-минутные разминки помогают проснуться и скинуть с себя пелену сна, размяться. Отдельно хочу отметить челенджи, они держат в тонусе и не дают лениться, это мотивирует дойти до конца.Конечно, поначалу сложно заставить себя вставать утром раньше, чем обычно, но когда понимаешь, что делаешь это для себя и своего здоровья, поднимаешься и не жалеешь. Главное выработать привычку, а потом уже все будет на автомате.
Сергей Н., победитель челленджа FITМасленица
С Cloud Sport я открыл идеальный для меня способ расслабления медитации. Это возможность отвлечься от суеты, справиться со стрессом, прислушаться к себе. Мне такие практики очень помогли, я стал более спокойным и уравновешенным.
Павел М.
Я больше 10 лет занималась легкой атлетикой, затем фитнесом (бег, TRX, плавание, танцы, хатха йога, йога на полотнах, бокс и т.д.), потом начались проблемы с коленом. В пандемию, после операции, стала сильно ограничена в упражнениях. Пыталась заниматься йогой дома, но все же было рановато, мало времени прошло после хирургического вмешательства. Еще мне было интересно попробовать медитации, но поняла, что это не совсем мое. А вот зарядка в Cloud Sport мне очень подходит, несмотря на то, что часть упражнений я адаптирую под себя, исключая нагрузку на колено. С приложением удобно заниматься в любое время я люблю делать зарядку утром, перед работой, после прогулки с собакой. Даже короткая разминка поднимает настроение, даёт позитивный настрой на весь день.
Алина Х.
До начала пандемии мы регулярно устраивали мероприятия в офисе. Поздравления именинников, 23 февраля и 8 марта, Хэллоуин, турниры по спортивному покеру, вечеринки в честь релизов... А на удалёнке поддерживали командный дух дистанционно: наши ребята участвовали онлайн в кулинарных мастер-классах, челленджах, викторинах, квизах и конкурсах.
Идея кибертурнира появилась не спонтанно. Мы всегда открыты к новым форматам взаимодействия внутри коллектива, а коммуникация в онлайн-играх бывает не менее интенсивной, чем в более традиционных видах тимбилдингов. Но главное, инициативу поддержали сами коллеги: благодаря опросу мы убедились, что киберспорт в нашей компании интересен многим.
Привет, Хабр! Меня зовут Мария Зернова, я менеджер отдела внутренних коммуникаций и корпоративной культуры МойОфис. Наша команда отвечает за работу с HR-брендом, мероприятия, информирование коллег, уровень их вовлеченности и в целом счастье сотрудников.
Мы никогда не придерживались идеи движуха ради движухи, поэтому в условиях пандемии ставили перед собой вполне конкретные цели: сплотить кроссфункциональную команду и найти новую площадку для неформального общения, чтобы собраться вне работы, пусть даже удаленно. Чемпионат по киберспорту состязание сотрудников в популярной компьютерной игре показался нам отличным способом решить актуальные задачи и воодушевить коллектив. Вот как проходила наша первая организация этого события.
Что необходимо сделать перед запуском любой развлекательной активности для коллег? Разумеется, уточнить, нужно ли им это. При положительном ответе предоставить опции. Так что первым делом мы провели опрос-голосование на тему "интересен ли вам в принципе чемпионат по киберспорту", попросили выбрать одну из игр (потенциальных дисциплин), указать приоритетные даты и время. Около 10% респондентов (это 60 человек) откликнулось в пользу проводить, и эта цифра показалась нам достаточной, чтобы начать подготовку.
Пообщавшись с сотрудниками-любителями онлайн-игр, мы составили список возможных дисциплин для турнира: Counter-Strike: Global Offensive, DOTA2, Hearthstone, Fortnite, PUBG Mobile, Mobile Legends. Чемпионаты по этим известным многопользовательским играм успешно проходят сегодня по всему миру.
Часть коллег предрекала победу Counter-Strike или DOTA2 одной из наиболее популярных высокоинтенсивных игр с тактическим элементом. Кто-то из ребят даже сравнил их с футболом и хоккеем классические, понятные и знакомые большинству состязания, куда без них? Прогнозы оказались близки к истине: лидером голосования со значительным отрывом стала Counter-Strike, второе место досталось DOTA2. "Бронзу" получила Heartstone, карточная онлайн-игра по вселенной Warcraft.
Согласно условиям, голосовать можно было сразу за несколько вариантов. Некоторые коллеги интересовались разными играми из списка, и мы решили не ограничивать выбор.В организации нам помогал центр киберспорта click-storm: логично и удобно было советоваться с теми, кто постоянно проводит подобные турниры, осведомлен в теме и может ответить на любые вопросы. Подрядчик также обеспечил техническую поддержку события.
На участие в турнире можно было записаться в составе уже сформированной команды либо же довериться случайному распределению, что в плане командообразования тоже оказалось отличным вариантом. Когда мы собрали кворум, то провели для ребят вебинар с организаторами: в рамках этого мини-ивента участники освежали в памяти игру (если требовалось), привыкали к платформе и заранее регистрировались. Каждая команда назначила себе капитана коллеги сами сделали выбор. Разумеется, завели чат для общения.
Турнирным форматом выбрали Double Elimination. Это компромисс между круговой системой (каждый сражается с каждым) и олимпийской сеткой (с выбыванием после первого поражения). Такой формат позволяет проиграть один раз и не выбыть из игры, но в то же время не затягивает турнир, как это возможно при круговой системе: наш чемпионат длился в итоге не более пяти часов.
Пример турнирной схемы Double Elimination для четырех команд.На каждом этапе организации была предусмотрена своя форма коммуникации с сотрудниками: голосование за игру на корпоративном портале, запись в команду (в общем документе), публикация информации о времени и месте, приглашение на вебинар и на саму игру. Напоминание о событии мы несколько раз отправляли как участникам, так и потенциальным болельщикам многим коллегам оказалось интересно посмотреть ход сражений.
Для регистрации на площадке достаточно было залогиниться через любую удобную социальную сеть в один клик, далее привязать Steam-аккаунт. Это позволяло проверить соответствие никнейма в игре с пользователем на площадке, убедиться, что никто не использует забаненный игровой аккаунт. После старта турнира на платформе автоматически открылись чаты между командами. Судьи выдавали реквизиты турнирных серверов.
Турнирные серверы одна из самых важных деталей чемпионата. Очень важен низкий пинг и высокий тикрейт сервера. На платформе были специально настроенные турнирные серверы со 128-битным тикрейтом. Скорость обработки информации вдвое выше, чем у обычных серверов. Это позволяло быстрее засчитывать выстрел и значительно повышало удовольствие от игры.
Трансляция на Twitch или YouTube важный элемент корпоративного кибертурнира, если на нем предусмотрены зрители. Речь об аналоге спортивного матча в прямом эфире с комментированием. Мы выбрали Twitch. На стрим пригласили опытного комментатора и фаната Counter-Strike, который легко и динамично рассказывал о ходе игр. Важно было, чтобы комментатор с уважением относился к участникам и отдавал себе отчёт, что сопровождает непрофессиональный турнир; выделял лучшие моменты, подбадривал и заряжал игроков. Как мы впоследствии узнали из отзывов, работой выбранного нами профессионала сотрудники остались очень довольны.
Наш первый кибертурнир в целом состоялся удачно: был очевиден опыт большинства игроков, все так или иначе уже играли в CS и освоились в Global Offensive довольно быстро. Атмосфера сложилась позитивная, весело было даже тем командам, которые проигрывали.
Ребята высоко оценили активность те, кто по их собственному признанию не играли в CS лет десять, ощутили приятную ностальгию. Новичкам периодически не хватало подготовки (тут мы поставили для себя галочку): встречались вопросы в духе не понятно, где консоль, что такое банан и т.д. Были и те, кто попросил на будущее составлять графики турниров, чтобы можно было поработать в паузах между матчами.
Карточка события на сайте организаторов.Чуть позже мы провели второй турнир по CS: GO. В его процессе стало хорошо заметно, что коллеги уже полностью освоились с сайтом, игрой, и все в этот раз знают, что им нужно делать. По сравнению с прошлым чемпионатом серьезно повысился упор на командную работу.
Запись с нашего второго корпоративного турнира:
С удовольствием почитаю о вашем личном опыте организации тимбилдингов в режиме удаленки. Если у вас есть интересные примеры, обязательно расскажите о них в комментариях!