В этом посте мы расскажем о примере дедлока в TPC-C для PostgreSQL, причиной которого является исключительно переход на виртуальные потоки Java 21 - и никаких проблем обедающих философов.

Любой более или менее серьезный продакшен, работающий с базой данных, подразумевает процесс миграции - обновление структуры базы данных от одной версии до другой (обычно более новой) [источник].

Миграции в БД можно делать вручную или использовать для этого специальные утилиты (фреймворки). В данной статье речь идет об утилите goose. Это инструмент миграции схемы, который обеспечивает управление миграциями схемы в проекте. Начиная с версии v3.16.0 goose поддерживает YDB - распределенную open-source СУБД. В данной статье мы будем разбирать кейс применения миграций конкретно в YDB.

Документация YDB разрабатывается на GitHub рядом с основной кодовой базой YDB и автоматически публикуется на сайт посредством CI/CD. Быть в курсе что в ней появляется можно с помощью функции «Watch» на GitHub или периодически просматривая вывод команды git log , но эти способы сложно назвать удобными. В этом дайджесте мы рассмотрим основные недавно опубликованные изменения в документации YDB.

Существуют различные способы снижения стоимости выполнения SQL-запросов в современных СУБД. Наиболее распространенными подходами являются использование подготовленных запросы и кэширование. Оба метода доступны в YDB.

Кэширование запросов позволяет скомпилировать запрос один раз (проанализировать его, построить оптимальный план запроса, в т.ч. JIT-скомпилировать в машинный код), а затем повторно выполнить его с разными значениями параметров. Это позволяет сократить общее время выполнения запроса на величину времени компиляции запроса. Кроме того, кэширование запросов значительно сокращает объем вычислительных ресурсов, необходимых для выполнения повторяющихся пользовательских запросов, поскольку они компилируются только при первом запросе (и инвалидации кеша). Ниже мы объясняем, почему в самых общих случаях необходима Prepare, какие трудности возникают с этим в случае распределенной СУБД и как кэшировать запросы без Prepare.

В нашем предыдущем посте о производительности YDB, посвященном Yahoo! Cloud Serving Benchmark (YCSB), мы упоминали, что готовим к публикации результаты других бенчмарков. Мы придерживаемся плана и сегодня рады представить вашему вниманию наши первые результаты бенчмарка TPC-C*, который является индустриальным стандартом оценки производительности онлайн транзакций (OLTP). Согласно этим результатам есть сценарии, в которых YDB немного превосходит CockroachDB, другую хорошо известную распределенную SQL СУБД.

Статьи про YDB публиковались на Хабре ещё до выхода в open source, а отдельным блогом мы обзавелись всего несколько недель назад. В связи с этим проведём небольшую ретроспективу — что пишут про YDB в других хабах.

Восемь разработчиков YDB собрались, чтобы поделиться тем, что они сделали для последнего релиза YDB v23.1. Рассмотренные новые возможности можно разделить на две категории: функциональные улучшения и улучшения производительности.

YQL — это SQL‑диалект, специфичный для базы данных YDB. YQL требует заранее объявлять имена и типы параметров запроса. Это обеспечивает высокую производительность и корректное поведение. В синтаксисе YQL параметры необходимо перечислять явно с помощью инструкции DECLARE. И этот нюанс YDB может быть неожиданным для пользователей традиционных баз данных. В статье раскрывается вспомогательный механизм, позволяющий писать привычные простые SQL‑запросы при работе с YDB.

Привет! Меня зовут Евгений Иванов, я разработчик YDB. Мне очень нравится заниматься задачами, связанными с производительностью: бенчить, анализировать, оптимизировать. И в YDB мы придаем очень большое значения тому, чтобы быть эффективными. В этом посте я хочу представить Вашему вниманию перевод нашей свежей статьи "YCSB performance series: YDB, CockroachDB, and YugabyteDB".

Реализовать распределённую систему управления базами данных (СУБД), высокопроизводительную, масштабируемую и консистентную, — настоящий вызов. В YDB успешно с ним справились, и наши пользователи могут это подтвердить. Мы ещё не делились показателями нашей производительности на широкую аудиторию, но понимаем их значимость. Поэтому сегодня мы расскажем о результатах нашего исследования производительности.

YDB — это распределённая реляционная СУБД. Производительность распределённых транзакций в TPC-C и других сложных бенчмарках во многом зависит от реализации хранения данных по ключу. В этом посте посте мы сравним результаты тестов YCSB для YDB и двух других известных распределённых SQL-баз данных — CockroachDB и YugabyteDB. Спойлер: YDB превзойдёт конкурентов по многим нагрузкам YCSB.

 Меня зовут Алексей Мясников, я тимлид на проекте YDB в Яндекс Облаке. А ещё — старший ментор на курсе «Go-разработчик» в Яндекс Практикуме и кандидат технических наук. В коммерческой разработке более 15 лет, стек — C++, Java, Go, TypeScript, а пробовал около 20 языков программирования, в том числе в продакшн. 

Эта статья про Go и микросервисную архитектуру написана на основе вебинара для Практикума.

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