Обновить
148.22

Высоконагруженные системы *

Методы получения высокой производительности систем

Сначала показывать
Порог рейтинга

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

  • как выбирать между опенсорсным Kubernetes и вендорскими платформами;

  • из чего складывается реальная стоимость владения;

  • когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

  • Михаил Савин, SRE Community Lead в Авито;

  • Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

  • Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

  • Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
+21
Комментарии1

Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».

Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.

На вебинаре поговорим:

— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды
— 5 классов интеграционных решений: когда какой работает, а когда — категорически нет
— Как мы строили матрицу зрелости и кто в итоге получил номинацию
— Что планируем исследовать дальше — и как повлиять на приоритеты

Будет живой эфир с интерактивом, не просто «говорящая голова».

Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.

📅 12 февраля 2026, 11:00 МСК
📍 Онлайн, бесплатно

👉 Нужна регистрация: тут

Теги:
0
Комментарии0

Что с Релизом ?!

На днях случайно наткнулся на такую вот интересную картинку с глубокой мыслью про релиз и как говорится "зацепило".

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

За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).

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

В этом посте расскажу одну историю. Если тема "зайдет", то подробно систематизирую все известные мне архетипы и напишу уже полноценную статью.

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

Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки.
Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.

Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)

Все конечно изменилось по мере роста сложности системы и вызовов перед командой разработки, но это как говорится "уже совсем другая история". Был ли у вас похожий опыт и как вы относитесь к такому устройству процесса релиза? видите ли все таки в нем плюсы или это "не правильно\в книжках пишут не так" ?

Всем добра и тихих релизов !

Теги:
0
Комментарии0

Open Table Formats — Iceberg vs Paimon — практика использования

В блоге партнеров GlowByte вышла новая статья.

Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.

Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.

Читать статью полностью по ссылке.

Теги:
+4
Комментарии0

Всё зелёное — значит, всё ок?

В новом выпуске подкаста «В SREду на кухне» обсуждаем суть мониторинга и причины его хронических сбоев. В фокусе — метрики и алерты: как не утонуть в потоке предупреждений, отсеять ложные сигналы и выстроить эффективную систему. Говорим о том, как SRE анализируют графики, какие показатели бизнес считает ключевыми, и развенчиваем миф о том, что «зелёный» статус всегда означает успех.

Ведущие:

  • Михаил Савин, SRE Community Lead в Авито;

  • Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

  • Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
+25
Комментарии0

Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными

В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.

Ребята рассказывают о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и делятся планами по развитию Data Ocean Nova.

Теги:
+4
Комментарии0

Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL

PostgreSQL по умолчанию не имеет нативной поддержки горизонтального масштабирования — и это вызывает сложности при достижении пределов единственного экземпляра Postgres. В качестве решения часто используют разделение таблиц по ключам и установку рядом с приложением координатора, который знает, на какой шард направить запрос. 

Однако у такого подхода множество недостатков: сложность миграций, проблемы с масштабированием метаданных и балансировкой и не только. 

Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции. 

Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.

Подробная история о том, что стало отправной точкой для создания SPQR, какие задачи он помогает решать, на чём основано решение и что помогает ему быть довольно простым в эксплуатации — в статье разработчика команды Managed Sharded Postgres Дениса Волкова на Хабре.

Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:

Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.


Но большинство незавершённых проектов создают инфраструктуру для того, чтобы какие‑то другие проекты могли завершиться и причинить пользу.

Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL

Читайте статью Андрея о том, как не получилось сделать PostgreSQL лучше (и почему это нормально)

Теги:
+8
Комментарии0

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

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

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.

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

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии1

Нагрузочное тестирование YMatrix

В партнерском материале расширяются результаты нагрузочного тестирования из статьи «Нагрузочное тестирование GP6 vs GP7 vs Cloudberry» и презентуются результаты тестирования YMatrix. Это дополнение к предыдущей статье, призванное сформировать понимание сравнимости результатов различных форков GreenPlum.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Оптимизации функционала Apache Iceberg в задачах real-time загрузки и обработки данных

В блоге Data Sapience, технологического партнера GlowByte, вышла новая статья.

Технические лидеры направления разработки Apache Spark в составе платформы Data Ocean рассказывают:

  • С какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg;

  • Что такое equality delete;

  • Почему они создают нагрузку при чтении таблиц в Apache Iceberg;

  • Как оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Нагрузочное тестирование YMatrix

Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.

Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше. 

Добро пожаловать в статью! Комментарии приветствуются.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Как оптимизировать бюджет на интеграции в 2026 году: практики и инструменты для DATAREON

11 декабря в 12:00 проведём практический вебинар для ИТ-директоров и архитекторов, которые хотят сократить стоимость интеграций на DATAREON и избавиться от рутинных трудозатрат.

Чаще всего для интеграций, особенно на предприятиях с большим количеством 1С, мы используем DATAREON Platform. Удобный 1С-коннектор, широкое распространение и доступная стоимость лицензий делают его одним из самых популярных решений для интеграционных задач.

Однако цена лицензии — лишь часть картины: важную роль играет также стоимость внедрения и дальнейшего сопровождения.

Сколько на самом деле стоит интеграционный проект? 

Какие существуют реальные способы снизить расходы без потери качества? 

Об этом мы поговорим на вебинаре.

Что покажем на вебинаре

Технический директор ИТ-интегратора «Белый код» Сергей Скирдин разберёт реальные кейсы и продемонстрирует, какие технические решения ускоряют работу и снижают стоимость интеграционного проекта:

  • Использование API DATAREON для создания типов данных. 

  • Генерация обработчиков 1С.

  • Отладка обработчиков и функций без боли.

  • Использование формата Enterprise Data как основы для интеграции типовых объектов 1С

  • Заглянем в будущее — покажем, как с помощью ИИ-агента можно дорабатывать интеграционный проект в DATAREON.

Какой эффект получит бизнес

✔ Снижение стоимости интеграций. Автоматизация процессов уменьшает объём ручной работы и бюджет проекта.
Быстрый запуск интеграций. Готовые инструменты ускоряют разработку и ввод в эксплуатацию.
Масштабируемость интеграций. Единые стандарты позволяют быстро подключать новые системы без усложнения архитектуры.

Кому будет полезно

  • Руководителям, которые выбирают подрядчика для внедрения интеграционной шины и хотят объективно оценить подходы и стоимость.

  • Архитекторам перерабатывающим технологию замены существующего интеграционного решения на DATAREON Platform

  • Компаниям с большим количеством систем на 1С и активными интеграционными задачами, которые хотят выстроить оптимальную архитектуру и ускорить ввод в эксплуатацию новых интеграционных потоков.

Регистрируйтесь и приходите!
Принять участие

Теги:
Рейтинг0
Комментарии0

5 Ошибок Рефакторинга

А ты надел каску перед рефакторингом ?
А ты надел каску перед рефакторингом ?
  1. Добавлять в рефакторинг улучшения
    Строго отделяйте рефакторинг т.е. преобразование кода из одной формы в другую с полным сохранением поведения от любых даже самых незначительных улучшений, оптимизаций, украшательства и тд и тп

  2. Делать один огромный коммит
    Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.

  3. Рефакторить без промежуточных проверок
    Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"

  4. Затягивать и долго не релизить рефакторинг
    Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.

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

    В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!

    Всем удачного рефакторинга!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Ближайшие события

Как нагрузочное тестирование на бою помогает платёжному сервису готовиться к сезону распродаж

День холостяка, Чёрная пятница, предновогодние распродажи — для платёжного сервиса ЮKassa это не просто даты в календаре, а особенно важное время. Тех, кто одновременно нажимает на кнопку «Оплатить» в онлайн-магазинах, становится в разы больше, и за считанные минуты нагрузка на инфраструктуру нашего сервиса многократно увеличивается.

Главный инструмент, который помогает нам успешно справиться с повышенной нагрузкой на сервис, — это определённо нагрузочное тестирование, которое мы проводим не только на тесте, но и на бою.

Для тестов на продакшене мы используем контролируемое нагрузочное тестирование, при котором синтетические платежи генерируются через боевые API и проходят полный цикл обработки: магазин → наш шлюз → банк → маркетплейс → платёжная система. Весь тестовый трафик маркируется и не подлежит биллингу — это гарантия отсутствия финансовых рисков. Нагрузка наращивается по двум сценариям — сначала ступенчато (step load), а затем резкими краткосрочными пиками (bursts), — чтобы достоверно сымитировать ситуацию в момент старта распродажи.

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

Более подробно о боевых стрельбах рассказываем в большой статье.

Теги:
Рейтинг0
Комментарии0

Бенчмарк бенчмарка Lakehouse-движков, в котором побеждает объективная реальность

В блоге Data Sapience, технологического партнера GlowByte, вышла крутая статья технического идеолога Lakehouse-платформы данных Data Ocean Nova Евгения Вилкова.

Недавно на Хабре вышла статья с громким заголовком “Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех”. В своей статье авторы из Кверифай Лабс выбрали методику TPC-DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

В качестве отступления замечу, что данный эксперимент не имеет ничего общего с массивно-параллельными вычислениями и Lakehouse. Архитектура раздельных вычислений предполагает интенсивный сетевой обмен не только между storage и compute, но и между узлами compute-движка. Как заметили в комментариях к оригинальной статье, с тем же успехом можно было включить в тест и MySQL. Складывается впечатление, что методика тестирования была выбрана исключительно из-за заявленных компетенций в области оптимизатора движка, а запрос – исходя из наличия собственных доработок для обработки схожего случая. Главной же целью было на частном выводе убедить аудиторию в общем выводе. Отдадим должное коллегам – они не скрывают субъективность своего отношения к упражнению.

Заинтригованы? Добро пожаловать в статью Евгения! Комментарии приветствуются.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как организовать хранение кадровых документов 1,5 млн пользователей в облаке: опыт HRlink 📄

Когда ваш бизнес обслуживает более 6 400 корпоративных клиентов, а платформу используют 1,5 млн человек, вы точно задумаетесь об отказоустойчивости, надежном хранении данных, соответствии 152-ФЗ, да и на вопросы производительности СУБД взглянете по-новому.

С такими задачами столкнулась компания HRlink. Рассказываем, как на IT-инфраструктуре Selectel она:

  • развернула сервис в облаке с возможностью гибкого масштабирования,

  • повысила производительность более 5 000 баз данных,

  • организовала надежное хранение кадровых документов,

  • обеспечила безопасную обработку персональных данных.  

Подробности кейса читайте в Академии Selectel, а также оставляйте заявку на бесплатную миграцию ➡️

Теги:
Всего голосов 7: ↑6 и ↓1+10
Комментарии2

Яндекс снова на обложке, хотя теперь под именем Nebius. После сделки с Microsoft акции в США улетели на +71%. Формально — всё красиво: дата-центр в Нью-Джерси, контракт на $17+ млрд до 2031 года. Но за кулисами это выглядит чуть иначе.

Главная проблема индустрии — NVIDIA ограничивает квоты на свои чипы. Это значит, что даже гиганты вроде Microsoft не могут прийти и сказать: «Дайте нам вагон H100, мы оплатим картой». Карточек тупо нет столько, сколько всем нужно. Поэтому Microsoft вынужден искать партнёров, у которых есть доступ к чипам через свои каналы.

Появляется Nebius. У компании свой лимит на железо, свои отношения с NVIDIA — и теперь кусок этого лимита фактически «арендован» Microsoft. То есть вместо того, чтобы напрямую выбивать квоты, корпорация берёт вычислительные мощности у бывшей «Яндекс N.V.».

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии1

Про сеть и инфраструктуру RUTUBE в подкасте linkmeup

В этом выпуске Эльдар Ниязов, директор департамента развития и эксплуатации ИТ-инфраструктуры RUTUBE, рассказывает об устройстве видеохостинга, ЦОДах, сетях и делится историями, которые не вошли в доклад об архитектуре.

Из видео узнаете:

  • Сколько нужно серверов, чтобы построить национальный видеохостинг.

  • Сколько легаси осталось от прошлых итераций (спойлер: совсем мало).

  • Как пережить взрывной рост и с какими ещё вызовами сталкивается команда.

  • Где живёт RUTUBE.

  • Зачем понадобилось написать собственный S3 (а более подробно о том, как устроено хранилище — в этом видео).

  • Как оптимизируется CDN и многое другое.

Как видно на превью, это интервью было записано на конференции HighLoad++. Следующая встреча разработчиков высоконагруженных систем уже не за горами и там снова выступят специалисты из RUTUBE — в этом году фокус на ML:

  • «Как RAG ускоряет поддержку RUTUBE: от гибридного поиска до мониторинга галлюцинаций». Виктор Леньшин объяснит, как устроена архитектура системы, которая уже в 80% случаев генерирует готовый ответ на запрос в поддержку.

  • «Платформа для создания субтитров на весь UGC в RUTUBE». Дмитрий Лукьянов расскажет, как платформа сейчас обрабатывает новые видео почти без задержек, справляется с экстремально длинными записями и не привирает на музыке, шумах и спецэффектах.

Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активов «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Мемо: в ожидании Python 3.14

Финальный релиз Python 3.14 запланирован на 7 октября 2025. Уже вышел RC2 (14 августа), а финальный кандидат RC3 ожидается 16 сентября.
Этот пост — краткая шпаргалка, чтобы помнить, какие изменения стоит протестировать и чего ждать в новой версии.

1. Свободная многопоточность (Free-Threaded Python, без GIL)

Зачем нужно: наконец-то полноценный параллелизм и многопоточность на многоядерных системах без глобальной блокировки интерпретатора.

# Включение free-threaded режима при сборке
# ./configure --disable-gil
import threading

def cpu_bound_task(n):
    return sum(i*i for i in range(n))

threads = [threading.Thread(target=cpu_bound_task, args=(10**6,)) for _ in range(4)]
[t.start() for t in threads]
[t.join() for t in threads]

Free-Threaded Python теперь не будет экспериментальным и будет официально поддерживаться, но пока пока будет являться опциональным, по умолчанию остаётся GIL.

2. Отложенная оценка аннотаций типов

Зачем нужно: ускорение работы и избавление от кавычек при forward references. Появился новый модуль annotationlib для работы с аннотациями.

# from __future__ import annotations
import annotationlib

class Node:
    def __init__(self, value: int, next: Node | None = None):
        self.value = value
        self.next = next

print(annotationlib.get_annotations(Node.__init__))

Аннотации больше не обрабатываются при определении функций, классов и модулей. Они сохраняются в специальных функциях аннотирования и обрабатываются при необходимости.
Импорт from future import annotations можно удалить при поддержке Python 3.14 и новее.

3. Template-строки (t-строки)

Зачем нужно: безопасное форматирование строк, полезное для веба и DSL, расширение возможностей f-строк.

name = "<script>alert('xss')</script>"
age = 25

tpl = t"Hello {name}, you are {age}"
safe = tpl.format(name=escape_html(name), age=age)
print(safe)

4. Zstandard-сжатие

Зачем нужно: современный алгоритм сжатия, быстрее gzip и удобнее для больших блоков данных.

import compression.zstd

data = b"Large dataset" * 1000
compressed = compression.zstd.compress(data, level=3)
decompressed = compression.zstd.decompress(compressed)

print(f"Ratio: {len(data) / len(compressed):.2f}")

5. Удалённая отладка процессов

Зачем нужно: можно подключать отладчик к работающему приложению без перезапуска и накладных расходов.

import sys
import pdb

# Подключение отладчика к работающему процессу
sys.remote_exec("""
import pdb; pdb.set_trace()
""", target_pid=12345)

# Безопасное выполнение кода в удаленном процессе
result = sys.remote_exec("print('Debug info:', some_variable)", target_pid=12345)

6. Экспериментальный JIT-компилятор

Зачем нужно: ускорение выполнения вычислительно интенсивных задач.

# Включается флагом при запуске
# python --jit script.py

def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

# JIT автоматически оптимизирует "горячие" функции
result = fibonacci(35)  # Заметно быстрее с JIT

7. REPL с подсветкой синтаксиса

Зачем нужно: удобнее писать и отлаживать код прямо в интерактивной оболочке.

>>> def hello(name: str) -> str:
...     return f"Hello, {name}!"
>>> hello("World")
'Hello, World!'

Что стоит попробовать?

  1. Потестировать free-threaded режим на CPU-нагруженных задачах.

  2. Перейти на новый синтаксис аннотаций без кавычек.

  3. Проверить t-строки в веб-шаблонах и DSL.

  4. Протестировать zstd для больших массивов данных.

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

Подробнее на python.org: What’s new in Python 3.14

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

Как построить отказоустойчивую инфраструктуру на базе Bare Metal: кейс компании SEOWORK

SEOWORK — платформа для мониторинга и аналитики поискового маркетинга. Компания развернула IT-инфраструктуру на выделенных серверах Selectel.

  • Основа инфраструктуры — выделенные серверы в дата-центрах уровня Tier III. Они связаны локальной сетью со скоростью до 10 Гбит/с и изолированы от интернета.

  • За производительность отвечают процессоры AMD EPYC™ 7452 (32 ядра), 512 ГБ RAM на сервер и быстрые SSD-диски корпоративного класса в RAID объемом до 20 ТБ.

  • Вся инфраструктура Selectel по умолчанию соответствует требованиям 152-ФЗ и защищена от DDoS-атак на уровнях L3-L4. Независимый трехмесячный пентест выстроенной системы, выполненный по заказу SEOWORK, подтвердил ее защищенность.

Подробнее о том, как компания развернула на Bare Metal производительную и отказоустойчивую инфраструктуру с SLA 99,8%, которая ежедневно обрабатывает более 600 ГБ данных, читайте в Академии Selectel.

Теги:
Всего голосов 4: ↑4 и ↓0+7
Комментарии0