Методы получения высокой производительности систем
Привет, меня зовут Ася Исакова, и я организационный психолог. Я уже 10 лет работаю с разными командами, и за это время видела сотни горящих, выгорающих и сгоревших на работе людей. В этой статье я расскажу, как управлять своим вниманием так, чтобы хватало сил на важные дела и оставалось на себя.
Разбираемся с управлением вниманием на примере огурцов, снежков и медведей
Пакет runtime/trace содержит мощный инструмент для понимания программ Go и устранения неполадок. Функциональность внутри позволяет создавать трассировку исполнения каждой горутины за определенный период времени. С помощью go tool trace command (или превосходного инструмента gotraceui с открытым исходным кодом) можно визуализировать и исследовать данные в этих трассировках.
Магия трассировки заключается в том, что она может легко выявить такие вещи в программе, которые трудно увидеть другими способами. Например, узкое место параллелизма, когда множество горутин блокируют один и тот же канал, может быть довольно трудно увидеть в профиле процессора, потому что нет исполнения для сэмпла. Но в трассировке отсутствие исполнения будет видно с удивительной четкостью, а трассировка стека заблокированных горутин быстро укажет на виновника.
Корпорация Nvidia продолжает развивать направление производства чипов для ИИ-отрасли. Сейчас руководитель американской компании заявил о выпуске самого мощного ИИ-чипа в мире. Кроме того, готовы и некоторые модульные системы, базирующиеся на основе GPU B200, так называется новинка. Подробности о ней — под катом.
Меня зовут Егор Литвиненко. Я старший разработчик Yandex Observability Platform. Летом 2023 года я рассказывал на Saint Highload в Санкт-Петербурге про наш путь внедрения YDB CDC для обновления данных в сервисах, чтобы решить проблему инвалидации кешей.
В этой статье будет вся история внедрения с теорией, вопросами, ответами, ошибками, о которых я говорил на выступлении. Но кроме того, в конце есть обновления: что произошло и изменилось за это время. Мы рассмотрим весь процесс от появления задачи до результата:
• Какие подходы к доставке изменений мы использовали.
• Почему выбрали переход на CDC и в чём были сложности в работе с изменениями до этого.
• Чем YDB CDC отличается от других решений, как настроить правильно, и на какие грабли мы наступили в процессе.
• Какую модель данных выбрать, чтобы решить проблемы с конкурентными изменениями.
• Как поддерживать решение после внедрения.
Меня зовут Михаил Гелемеев, я лидер команды сопровождения Platform V Pangolin в СберТехе.
Platform V Pangolin — реляционная система управления базами данных. Она основана на свободно распространяемой версии PostgreSQL и содержит ряд доработок, обеспечивающих соответствие повышенным требованиям к безопасности данных, доступности, надежности, а также удобству эксплуатации. Наш продукт помогает получить функциональные возможности реляционной СУБД, включая построение кластеров высокой доступности, резервирование данных, снятие и восстановление резервных копий.
В январе мы выпустили новую версию — Platform V Pangolin 6.1. В ней появились обновления для работы с большим объёмом данных. Если вкратце — работать с секциями стало проще и быстрее: дешевле доступ к данным в секционированных таблицах, и для них можно гибко создавать уникальные глобальные индексы. Теперь можно предотвратить высокое потребление CPU и RAM пользовательской сессией, это улучшает доступность сервиса. Мы также добавили инструмент диагностики текущей активности для детального понимания процессов сессии, так работа СУБД становится более прозрачной.
В статье подробнее расскажу о каждой из доработок. Их можно условно разделить на две части: для пользователей и для администраторов/инфраструктуры.
Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.
Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).
Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.
Судя по обилию статей «Кто такой архитектор в ИТ?» — нет общего понимания, чем он занимается, должен ли он вырасти из программиста или его можно сделать из системного аналитика. На самом деле ключевым качеством, которое сразу выделяет его среди остальных в ИТ, является способность смотреть на задачу с разных точек зрения. В статье приводится простой практический архитектурный кейс для очень известной системы, и выводы будут однозначные.
Извлечение подстроки. Казалось бы, что тут может быть сложного? В любом современном языке программирования это можно сделать через функцию substring или через slicing. За время работы C# разработчиком я повидал разный код, в том числе разные способы извлечения подстроки. В этой статье мы рассмотрим самые распространённые из них, сделаем замеры производительности и проанализируем результаты.
О компании Cerebras на Хабре писали несколько раз, чаще всего с упоминанием того, что она создала самый большой в мире процессор. И сейчас та же ситуация — она повторила свой рекорд, разработав гигант с 900 тыс. вычислительных ядер. Конечно, это чип не для обычных пользователей, а для работы в отрасли искусственного интеллекта. Что это за процессор и на что он способен? Подробности — под катом.
Всем доброго времени суток. Некоторое время назад мною была написана статья, где я детально описал процесс разработки демо игрового вебсокет сервера. На этот раз, я хотел бы поделиться более усовершенствованным и оптимизированным материалом на Kotlin и реактивном стеке.
В прошлой статье я показал, как условие с парой однотипных неравенств, плохо поддающееся индексации с помощью btree, можно переделать на эффективно gist-индексируемое в PostgreSQL условие относительно диапазонных типов, а наш сервис анализа планов запросов explain.tensor.ru подскажет, как именно это сделать.
Но что делать, если неравенств у нас не два, а целых четыре, да еще и с разными типами участвующих полей? Например, для целей бизнеса это может быть задачей вроде "найди мне все продажи за декабрь на сумму 10-20K", что на SQL будет выглядеть примерно так:
dt >= '2023-12-01'::date AND dt <= '2023-12-31'::date AND
sum >= 10000::numeric AND sum <= 20000::numeric
Я работаю в компании STM Labs, где мы строим большие высоконагруженные системы класса Big Data. Эта статья написана по мотивам моего выступления на конференции Saint Highload 2023. Хочу рассказать вам увлекательную историю про то, как мы искали лучшее решение по синхронизации аналитического и оперативного хранилищ в реальном времени. Нам важно было сделать это без потерь, потому что на кону стояли сотни и более терабайт данных.
Сразу обозначу, чего в этой статье не будет:
• Я не буду подробно говорить о типах СУБД и их различиях.
• Я не буду делать обзор аналитических СУБД. Тут каждый выбирает сам.
• Я не буду подробно останавливаться на архитектуре, отказоустойчивости и масштабировании СУБД MongoDB.
• Я не буду делать обзор отличий OLAP и OLTP.
• Я не буду делать обзор и сравнение реализаций CDC в различных СУБД.
Вероятно, вы уже слышали о соревновании под названием "The One Billion Row Challenge" (1brc), если же нет, то предлагаю ознакомиться с репозиторием 1brc Гуннара Морлинга.
Моё участие в проекте было мотивировано присутствием в нём двух моих коллег, которые достигли лидирующих позиций.
PHP не известен своими выдающимися скоростными показателями. Тем не менее, учитывая, что я работаю над профайлером PHP, я решил исследовать его производительность на примере этого вызова.
Я уже не раз писал, что условия с несколькими неравенствами (<, <=, >=, >) обычно плохо подходят для индексирования "классическим" btree, вызывают "тормоза", и необходимо придумывать различные нетривиальные подходы в PostgreSQL, чтобы добиться хорошей производительности подобного запроса.
В этой статье мы не только рассмотрим способы решения подобных задач "в общем виде", но и покажем, как нам удалось автоматизировать их решение в рамках функционала рекомендаций индексов нашего сервиса анализа планов explain.tensor.ru и его новых возможностях.
