Привет! Меня зовут Паша Сушин. Уже больше десяти лет я занимаюсь в Яндексе развитием платформы YTsaurus — нашего внутреннего инструмента, который в марте 2023 года вышел в опенсорс и теперь доступен всем на GitHub по лицензии Apache 2.0. 

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

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

Всем привет! Меня зовут Сергей Яхницкий. Я пишу на Python уже больше шести лет, техлид в Яндекс Такси, Python-евангелист и член Python-комитета Яндекса (аналог Python Steering Council).

Человек я простой, звёзд с Гитхаба не хватал: до того, как я устроился в Такси, я мирно писал маленькие бэкенды на Python. А потом меня прорвало: кодогенерации, CI/CD, кучи тестов, монорепа и прочее. Вот тут-то моя питоничья душа и воспряла. Решил я всё автоматизировать, обновить всё, что движется, а что не движется — подвигать и обновить. Из этого вышел мой рассказ.

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

За последние три года размер данных Notion увеличился в 10 раз из‑за роста количества пользователей и объёмов контента, с которым они работают. Удвоение этого показателя происходило каждые 6–12 месяцев. Нам нужно было справиться со стремительным ростом размеров данных, соответствуя при этом постоянно растущим требованиям, которые выдвигали критически важные сценарии использования наших продуктов и аналитических систем. Особенно это справедливо в применении к новым функциям Notion AI. Для того чтобы решить эти задачи нам нужно было создать озеро данных Notion и обеспечить его масштабирование. Вот как мы это сделали.

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

Кэширование позволяет значительно сократить время загрузки и уменьшить нагрузку на сервер, сохраняя часто используемые данные в local storage. В данной статье мы рассмотрим один из способов кэширования в React‑приложениях — используя хуки.

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

Главная ошибка была в том, что ты в это вообще ввязался — в этом никаких сомнений.

Ещё когда я впервые взялся проходить курс по C++ несколько лет назад, меня учили, что, если я не предоставлю собственного конструктора, то компилятор сам подберёт ему замену — своего рода конструкторы, действующие по умолчанию. Я решил подробнее в этом разобраться, особенно меня волновали случаи, которые выглядят примерно так:

Вы когда-нибудь задумывались, что происходит за кулисами, когда мы запускаем или завершаем процесс? В этом уроке мы узнаем, как Linux генерирует PID для процессов.

Продолжаем тему блокировок на сервере СУБД. Сегодня «нелогичные» блокировки. Нелогичные в кавычках, потому что с точки зрения пользователя они выглядят как обычные логические (Записки оптимизатора 1С (часть 6). Логические блокировки MS SQL Server в 1С: Предприятие), но природа их совсем другая.

Многие, наверняка, сталкивались с мемом this is fine, или оригинальным комиксом. Так выглядит типичный день для многих дежурных сотрудников. Оперативные дежурные получают много оповещений, и работа со слишком большим количеством оповещений может привести к усталости от оповещений — чувству истощения, вызванному реагированием на оповещения, которые не имеют приоритета или четких действий. Убедиться в том, что оповещения действенны и точны, а не являются ложными срабатываниями, крайне важно, потому что если дежурные сотрудники постоянно получают ложные уведомления, они могут перестать обращать на них внимание и игнорировать даже важные сообщения. С этой целью в Cloudflare многочисленные команды проводят периодический анализ оповещений, каждая команда разрабатывает свои собственные панели мониторинга для отчетности.

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

Смотрим, как вездесущий PostgreSQL справляется с нестандартными для реляционной системы управления базами данных (СУБД) ролями: хранением и поиском временных рядов, пар «ключ — значение», эмбеддингов для больших языковых моделей и многомерных кубов. Отвечаем на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных — MongoDB, Redis, InfluxDB, Pinecone, ClickHouse, Apache Cassandra — или можно обойтись одним PostgreSQL?

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS по управлению данными и архитектуре ПО. В прошлой статье я рассказывал о миграции с Oracle на PostgreSQL, а сегодня разберу, как последний работает с нетипичными видами данных.

Последнее время достаточно популярна "async/await" концепция в Rust. Безусловно для подавляющего большинства задач это лучший вариант. Так как она ориентирована на то что система, которая обрабатывает сетевые запросы, например сталкивается с блокировкой ввода/вывода к базе данных. В результате лучшим решением будет использование "async/await", так как он позволяет использовать один поток для обработки множества запросов. Если функция "async" не может быть завершена например из-за ожидания ввода-вывода, она может отдать управление в точке ее вызова "await". И "executor" например "Tokio" может переключиться на другую задачу.

Для лиги лени: ежемесячное нытье про зарплаты и наличие кадров. Поток сознания от нейросети, мысли вслух, рукопись найденная в солидоле ванне. Рукопись написана на архаичном протоязыке, и потому некоторые термины и идиоматические выражения в тексте остались непереведенными. Это, как правило, те священные, исполненные тайной магической силы заклинания, которые до сих пор, без понимания утерянного смысла, передаются из уст в в уста.. Читать не надо, сразу ставь минус!

Когда-то я работал системным инженером в одном из крупнейших российских системных интеграторов. Там внедрял и сопровождал системы электронного документооборота. В 2010 году «Гринатом» искал специалиста с моим опытом, чтобы сопровождать свою отраслевую систему документооборота. Мне понравились условия и возможность развивать новые продукты фактически с нуля, и я согласился. С тех пор работаю там, и за 14 лет работы развитие не останавливается. Растёт мое подразделение, и внедряемые технологии, и компетенции. Мы постоянно привносим новые решения, и это не останавливающееся движение очень мотивирует.

Это шестнадцатая часть серии мега-учебника Flask, в которой я собираюсь добавить возможность полнотекстового поиска в Microblog.

Всем привет, меня зовут Пётр. В первой части этого цикла статей мы взглянули на некоторые базовые концепции ClickHouse. В этой же статье продолжим изучать тонкости работы с этой колоночной базой данных и подробно рассмотрим такой аспект как репликация. А ещё разберёмся с сервисами координации Zookeeper и ClickHouse Keeper.

Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? 

Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения. 

Задача была такова – реализовать массовое управления биржевыми ордерами, причём не только в рамках одной биржи, а в целом по всей планете. И чтобы оно точно отработало. 

В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

Это история о том, как я подался на получение загранпаспорта нового образца в консульство в Тбилиси, забыл кодовое слово для доступа к анкете на сайте zp.midpass.ru, перерыл весь код их фронтенда и вспомнил комбинаторику, чтобы восстановить это слово. А также готовый код для тех, кто попал в такую же беду и бот, который нажимает одну кнопку раз в день.

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

Некая недосказанность всегда присутствует на первых свиданиях. Жаль, что она в плоскости тех.задания.  Когда времени мало – проще танцевать от требований и ограничений, а не заниматься подтверждением  парадокса выбора. Поэтому будем сразу говорить об архитектуре. На собеседованиях только и разговоров, что об архитектуре и о дизайне. Там говорят о том, как чертовски здорово наблюдать за огромным монолитным легаси, как он тает в волнах.