Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы.

Предыдущие циклы были посвящены изоляции и многоверсионности, журналированию и блокировкам.

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

Материал перекликается с нашим учебным курсом QPT «Оптимизация запросов», но ограничивается только подробностями внутреннего устройства и не затрагивает оптимизацию как таковую. Кроме того, я ориентируюсь на еще не вышедшую версию PostgreSQL 14. А курс мы тоже скоро обновим (правда, на версию 13; приходится бежать со всех ног, чтобы только оставаться на месте).

Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3. 

Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.

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

Сегодня уже ни для кого не секрет, что каждое отправляемое нами сообщение из любой точки мира может быть успешно перехвачено, проанализировано и отфильтровано компаниями, корпорациями и государственными спец службами. Каждый наблюдатель в такой ролевой модели преследует выполнение своих, точно заданных задач. Но когда таковые наблюдатели объединяются в одного, сию же минуту рождается, как новая звезда в космическом пространстве, глобальный наблюдатель, противодействий которому будет недостаточно со стороны классических анонимных сетей, будь то Tor, I2P или Mixminion.

О радужных перспективах квантовых вычислений говорят уже не один десяток лет — этим принципиально иным с технической точки зрения компьютерам прочат судьбу «следующей большой технологии», которая ускорит, улучшит и выведет на принципиально новый уровень многие сферы человеческой жизни. Долгое время все подобные утверждения неизменно сопровождались оговорками: «когда появятся коммерческие квантовые компьютеры» и «когда удастся продемонстрировать квантовое превосходство». Недавно банк CITI опубликовал обширный отчёт о состоянии рынка квантовых вычислений. Cудя по его содержанию, оговорки вот-вот можно будет отбросить, а квантовые компьютеры станут технологией, которая определит технологический облик 2020-х годов. Глядя на отчет CITI, разбираемся, как устроены современные квантовые компьютеры и какие сферы жизни они изменят. 

Эта заметка о том, зачем нам нужен пакет coroutine для Go и как он будет выглядеть. Но прежде всего, что такое корутины?

Сегодня каждый программист знаком с вызовами функций (подпрограмм): F вызывает G, которая останавливает F и запускает G. G выполняет свою работу, потенциально вызывая и ожидая другие функции, и в конце концов возвращается. Когда G возвращается, G уже нет, а F продолжает работать. В этой схеме одновременно выполняется только одна функция, а ее вызывающие ожидают, поднимаясь вверх по стеку вызовов.

В отличие от подпрограмм, корутины выполняются конкурентно на разных стеках, но все равно верно, что одновременно выполняется только одна функция, а ее вызывающая сторона ждет. F запускает G, но G не выполняется немедленно. Вместо этого F должен явно возобновить (resume) выполнение G, который затем начинает выполняться. В любой момент G может развернуться и вернуться (yield) назад к F. Это приостановит G и продолжит F операцию возобновления. В конце концов F снова вызывает resume, который приостанавливает F и продолжает G после выхода. И так далее, туда-сюда, пока G не вернется, что приведет к очистке G и продолжению F с последней операции возобновления, с некоторым сигналом для F, что G закончена и F больше не должна пытаться возобновить G. В этом паттерне одновременно выполняется только одна корутина, а ее вызывающая сторона ждет на другом стеке. Они выполняются по очереди в четко определенном, скоординированном порядке.

Это несколько абстрактно. Давайте посмотрим на реальные программы.

Привет, Хабр. Меня зовут Рустам. Я работаю в Ozon: админю Kubernetes и пишу на Go.

У нас очень много сервисов на Go — их количество исчисляется тысячами. Запускаются они внутри кластеров Kubernetes. А я плотно работаю с Kubernetes и заметил, что при запуске кода внутри Kubernetes для резолва одного адреса делается до десяти DNS-запросов. Это, конечно, влияет на производительность.

Я решил разобраться, как Go делает DNS-запросы. В результате мне удалось уменьшить их количество в наших проектах до одного-двух. Как у меня это получилось и можно ли использовать мой опыт в вашем проекте, я расскажу в статье.

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

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

Под катом вы узнаете как установить оптимальные значение connection и request timeout, стоит ли повторять запрос при ошибке или лучше избегать этого.

В конце статьи есть небольшая шпаргалка и куча полезных ссылок. Приятного чтения.

Привет! Меня зовут Станислав, я фронтенд-разработчик компании Тинькофф. Занимаюсь разработкой веб-приложений и написал десятки тысяч строк кода, массу велосипедов и костылей, пока не познакомился с разработкой, основанной на модели предметной области, или Domain-Driven Design.

DDD — это система знаний, приемов и методов, предназначенная для создания приложений высокой сложности. DDD обобщает лучшие практики коммерческой разработки программного обеспечения и постоянно совершенствуется, предоставляя разработчику надежную опору для принятия решений. Лучший способ узнать больше — это книга Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software.

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

Привет, Хабр! В начале апреля 2023 года на одном из хостов был обнаружен подозрительный файл mhddos_proxy_linux_arm64 (MD5: 9e39f69350ad6599420bbd66e2715fcb), загружаемый вместе с определенным Docker-контейнером. По открытым источникам стало понятно, что данный файл представляет из себя свободно распространяемый инструмент для осуществления распределённой атаки на отказ в обслуживании (DDoS), направленный против российской ИТ-инфраструктуры.

После запуска программа получает все необходимые настройки и автоматически
инициирует массированные сетевые подключения к целевым хостам на различных
уровнях TCP/IP для осуществления отказа в обслуживании.

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

Привет! Меня зовут Николай Тихонов, я работаю в команде Tinkoff eCommerce. Я начинал как фронтендер, а потом стал писать бэкенд и занялся CI/CD. А дальше — FullStack Ops и руководство процессами и собственной командой. Сегодня расскажу про FrontOps, blue-green и релизы без даунтайма. Эта статья — текстовая адаптация моего доклада для FrontendConf 2022. 

С минимальными знаниями Ops-технологий фронтендер может показывать каждому пользователю, что он сделал, и в одиночку реализовывать крутые продукты. А релизы с даунтаймом все еще существуют и не дают клиентам пользоваться продуктом ночью, поэтому в этой статье поговорим про практику blue-green.

Всем привет, меня зовут Авксентий, я backend-разработчик в inDriver. Думаю, каждый начинающий разработчик сталкивался с проблемой, как правильно выстроить архитектуру и структуру проекта. Ведь организация кода проекта — постоянно развивающаяся проблема, а следование стандартной структуре сохраняет чистоту кода и повышает производительность команды. 

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

Вечером пятницы 23 сентября, в самое «горячее» время для Додо Пиццы, развалилась платформа Dodo IS. Приём заказов превратился в тыкву, клиенты и пиццерии 4 часа испытывали проблемы. Это было наше самое крупное падение с 2018-го года как в техническом плане, так и по недополученной выручке.

Особенная боль — то, что мы упали в прайм-тайм. Наш бизнес устроен циклично и зависит от сезона: осенью заказов больше, чем летом, а по вечерам пятницы больше в несколько раз, чем в утром вторника. Обычно пик заказов приходится на вечер пятницы (с 16 до 20 по Москве). Это время — самое напряженное для системы и самое ценное для бизнеса.

У Dodo IS произошёл каскадный сбой и мы долго не могли реанимировать систему. В этой статье делимся постмортемом инцидента: разберём причины, опишем действия по устранению и расскажем о действиях, которые позволят избежать таких падений в будущем.

В эпоху быстрорастущих приложений важно иметь возможность контролировать состояние системы в любой момент времени. Одними из требований для достижения этого являются логи и метрики, которые помогают нам следить за многими параметрами, такими как количество запросов в секунду (RPS), потребление памяти, cache git и т.д. Однако, есть ещё один полезный инструмент - трейсинг. В этой статье мы ознакомимся со стандартом OpenTelemetry в языке Go и инструментом Jaeger

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

Сегодня есть множество IDE, поддерживающих работу с Go и позволяющих отлаживать приложения. На текущий момент для Go представлены два отладчика: GDB (но он не поддерживает многие фичи языка, например Go-рутины) и Delve. Многие IDE используют последний как дефолтный отладчик. И в этой статье я расскажу о возможностях Delve: о том, что умеет сам отладчик, а не что нам предоставляет IDE.

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

Чтобы поделиться кодом, нужно создать библиотеку и разместить её в самостоятельном репозитории. Но иногда возникает необходимость хранить библиотеку вместе с сервисом, который её использует, — это может быть полезно при разработке в open source, в процессе дробления монолита на микросервисы и при шеринге своим API. Среди Go-разработчиков существует мнение, что экспортируемые библиотеки стоит хранить в директории pkg.

Как оказалось, при экспорте библиотеки из сервиса может возникнуть множество нюансов. В этой статье мы разберём, как сделать внешнюю библиотеку максимально удобной как для сервиса, который её экспортирует, так и для импортёров.

В современной микросервисной разработке очень популярна чистая архитектура (она же луковая). Этот подход ясно отвечает на много архитектурных вопросов, а также хорошо подходит для сервисов с небольшой кодовой базой. Другая приятная особенность чистой архитектуры состоит в том, что она отлично сочетается с Domain Driven Development — они отлично дополняют друг друга.

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

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