Стремление к совершенству

Ответственный и бескомпромиссный подход к своему делу всегда высоко ценится. Давайте посмотрим на релиз 1.19 и узнаем, как разработчики отшлифовали своё творение. Ещё поговорим о влиянии слайсов на производительность и заценим, какую облачную файловую систему создали с помощью Go. 

Релиз Go 1.19

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

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

Модель памяти Go теперь приближена к той, которая используется в C, C++, Java, JavaScript, Rust и Swift. Размер исходных стеков горутин теперь динамически изменяется для уменьшения копирования стека. Почти во всех Unix-системах использование дополнительных файловых дескрипторов теперь задействуется автоматически.

Пакет os/exec больше не учитывает относительные пути при поиске в PATH. Мыши плакали, кололись, но продолжали жрать кактус. Если вам позарез нужно искать относительные пути в PATH, то задействуйте пакет execabs. Но обязательно помните о безопасности.

Однако, нюанс

Во многих языках массивы достаточно универсальны. После создания и заполнения данными их можно изменять, добавляя и убирая элементы, лишь бы совпадал тип данных. Но Golang не так прост. Массивы в нём неизменяемы и фиксированного размера. Это не баг, а фича. А если нужна гибкость, то стоит взглянуть на срезы (slice).

Срезы основаны на массивах и представляют собой последовательность данных переменной длины, но одного типа. Их можно рассматривать как обёртку для массивов. Срез не обладает фиксированным размером, а элементы можно добавлять/удалять в течение всего срока жизни приложения. Фактически это ссылка на часть данных массива (или массив целиком). Проблема при использовании срезов в том, что гибкость приносится в жертву производительности.

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

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

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

Сочная JuiceFS

Бурное развитие облачных услуг видоизменило не только привычный подход к созданию приложений и сервисов. Оно породило новые сущности, такие как облачные файловые системы. Чтобы понять, как это работает, начнём с простого — локальных ФС. У пользователей Windows чаще всего встречается NTFS, поклонники Linux задействуют EXT4, а маководы — APFS. 

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

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

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

Прелесть в том, что для такой системы можно сделать ещё более высокоуровневую абстракцию. Для этого нужно два ключевых компонента: база данных и место для фактического хранения. Если взять какой-нибудь Redis/TiKV/MySQL, а сами данные хранить в объектном хранилище, например, Amazon S3 — можно создать облачную ФС поверх облачной ФС. Такая концепция легла в основу JuiceFS.

Есть вопрос, который всегда расставляет всё по своим местам — зачем? Ответ прост — чтобы любое облачное хранилище можно было смонтировать в систему так, словно оно локальное. Это позволяет не переделывать софт для обработки данных. Особенно такое полезно при работе с массивами Big Data.

Кроме простого монтирования JuiceFS можно прикрутить к кластеру Kubernetes с помощью соответствующего CSI-драйвера. Присутствует и Hadoop Java SDK для использования JuiceFS в распределённых приложениях. Разработчики заявляют высокую скорость работы и обеспечение консистентности данных.

Конкурсы для разработчиков

Митапы

Вакансии