Как я сделал PR на 14К строк в проект YDB будучи студентом

В этой статье я хотел бы рассказать о задаче, решение которой легло в основу моей дипломной работы. На момент ноября 2023 года я был студентом Физтеха ‑– учился на базовой кафедре Яндекса, программа обучения которой реализуется совместно с ШАДом. Задача заключалась в переводе парсера языка запросов YQL (диалект SQL для YDB и YTsaurus) с ANTLR3 на ANTLR4. Мой наставник в ШАД и руководитель команды разработки клиентских библиотек YDB в Яндексе к. т. н. Алексей Мясников @asmyasnikov отметил еёе как особо сложную. Но меня это не отпугнуло:, тема работы из всех тем, предложенных в ШАД, эта показалась самой интересной и близкой мне.

https://habr.com/ru/companies/yandex/articles/873464/

Шины данных для очень больших инсталляций, или Почему большим компаниям сложно с опенсорсом

Как технический менеджер в Яндексе я отвечаю за эксплуатацию больших кластеров, через которые мы передаём данные, — для этого мы используем YDB Topics, собственный аналог Apache Kafka, о котором я уже рассказывал . Но если посмотреть не только на нас, но и на примеры других крупных систем, то становится понятно, почему энтерпрайзу сложно брать готовые опенсорс‑решения. Стоит лишь представить, что бывает, если команда с большими масштабами начинает использовать Apache Kafka. В этой статье я покажу собирательный образ такой крупной системы из нашего опыта общения с большими распределёнными командами, и мы увидим разницу в TCO Apache Kafka и YDB Topics на конкретных цифрах.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/850758/

Стоит ли бояться serializable-транзакций больше, чем труднонаходимых багов?

В базах данных транзакции обладают свойствами ACID , где «I» означает изоляцию транзакций при одновременном (concurrent) выполнении. Наличие (serializable) изоляции гарантирует, что результат транзакций, выполненных параллельно, будет таким же, как если бы они были выполнены в некотором последовательном порядке. Сериализация выполнения транзакций не бесплатна с точки зрения производительности. Многие СУБД поддерживают более слабые уровни изоляции, оставляя за разработчиком выбор подходящего. В монолитных СУБД более слабый уровень изоляции часто используется по умолчанию. Так, в PostgreSQL и MySQL это «read committed». В распределённых СУБД чаще по умолчанию более строгие уровни: «repeatable read» в YugabyteDB и TiDB , «serializable» в CockroachDB и YDB . Слабые уровни изоляции могут быть причиной очень труднонаходимых багов. Причём эти баги могут вызвать уязвимости в безопасности. Из-за подобных багов уже были украдены миллионы долларов, в частности с биткоин-бирж. Мы расскажем о подобных случаях более детально в следующих разделах.

https://habr.com/ru/companies/ydb/articles/825768/

[Перевод] Что нового в документации YDB во втором квартале 2024 года

Документация YDB продолжает развиваться, отвечая на растущие потребности своей разнообразной аудитории. Наша цель остаётся прежней — улучшение ясности, доступности и глубины предоставляемой информации. В этом квартале мы ввели значительные обновления и новые разделы.

https://habr.com/ru/companies/ydb/articles/825416/

Как мы повышали производительность очереди сообщений

Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics . Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности. Меня зовут Зевайкин Александр . Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB , в частности, функциональности YDB Topic.

https://habr.com/ru/companies/oleg-bunin/articles/824826/

Концентрат хардкор-инфры в стаканах для нетворкинга: чем запомнился infra.conf 2024

4 июня состоялась infra.conf 2024 — конференция про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. На мероприятии мы попросили поделиться своими инфраструктурными историями инженеров не только Яндекса, но и Ozon.Tech, T1, MTS Web Services, Т‑Банка, SberDevices, Альфа‑банка, «Лаборатории Касперского», Selectel, Postgres Pro, СберМаркета и Авито. В результате, по отзывам участников, «хардкор‑концентрат железа и DevOps зашкаливал и летал прямо в воздухе». В этой статье мы собрали самые интересные моменты по тем докладам, которые вызвали наибольшую реакцию и восторг от полезности в кулуарах и чатах, — чтобы вам было проще сориентироваться, что стоит пересмотреть.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/821859/

userver 2.0 — большой релиз фреймворка для IO-bound программ

С момента прошлого релиза фреймворка userver для С++ прошло чуть больше полугода. За это время мы многое сделали: сильно оптимизировали работу фреймворка и обогнали основных конкурентов в бенчмарках высокопроизводительных фреймворков; значительно упростили конфигурирование; обзавелись install , докер-образами, Yandex Cloud-образом и DEB-пакетами; обросли новой функциональностью, включая серверные мидлвари для HTTP, и YDB-драйвером; перешли на новую ежемесячную схему релизов и упростили версионирование. Добро пожаловать под кат за подробностями

https://habr.com/ru/companies/yandex/articles/813115/

#yandex #открытый_код #userver #github #c++ #c++17 #postgresql #postgres #redis #mongodb #mongo #synchronization #coroutine #coroutines #logs #dynamic_changes #python #python3 #yaml #json #sql #mysql #prometheus #prometheus_grafana #опенсорс_яндекса #ydb #kafka #осьминоги

database/sql: плохой, хороший, злой

Многие Golang-разработчики пробовали работать с БД в Go, и у каждого — свои боли. В этой статье разберём библиотеку database/sql как безотносительно конкретной СУБД, так и применительно к YDB . Рассмотрим трудности эксплуатации при использовании драйвера database/sql на проде. А также рассмотрим, что мы делали для решения проблем. Меня зовут Алексей Мясников , я — руководитель Application Team в команде разработки YDB. Я очень люблю git blame за то, что с его помощью можно проследить как развивалась инженерная мысль с течением времени и немножко побыть в шкуре разработчика той или иной классной штуки. В статье я расскажу как реализовать драйвер database/sql для распределённой базы данных, какие проблемы при этом придётся преодолеть и как менялся подход с выходом новых версий Go.

https://habr.com/ru/companies/oleg-bunin/articles/808097/

#go #sql #yql #ydb #базы_данных #database/sql #jdbc #odbc #sql_injection #preparedstatement

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

10 лет назад сотни серверов Яндекса работали на Apache Kafka®, но в этом продукте нам нравилось далеко не всё. Наши задачи требовали единой шины для передачи всех видов данных: от биллинговых до журналов приложений. Сегодня объёмы достигли уже десятков тысяч именованных наборов сообщений. При таком количестве данных в Apache Kafka® становилось сложно управлять правами доступа, организовывать распределённую работу нескольких команд и многое другое. Проблемы роста и отсутствие подходящего решения в открытом доступе привели к тому, что мы разработали своё решение YDB Topics и выложили его в опенсорс в составе платформы данных YDB . В этом посте расскажу о предпосылках создания продукта, нашей архитектуре передачи данных, возникающих задачах и возможностях, которые появились вместе с YDB Topics.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/810907/

[Перевод] Что нового в документации YDB за 1 квартал 2024 года

Первоначальная документация YDB, опубликованная в рамках open-source запуска в 2022 году , имела структуру, на которую в значительной степени повлиял закон Конвея . Создание проекта с открытым исходным кодом значительно повышает планку того, что ожидается от документации по технологии. В нашем случае для быстрого создания большого количества контента перед запуском потребовалась командная работа по принципу «разделяй и властвуй». На раннем этапе такое четкое владение каждым фрагментом было полезным. Однако, поскольку общий объем документации со временем продолжает расти, читателям становится всё труднее находить нужную им информацию. Чтобы решить эту проблему, мы перепроектируем структуру документации, чтобы она была ориентирована на пользователя. Таким образом, если вы являетесь командой, работающей с кластером YDB, каждый может иметь свою собственную любимую директорию в документации в соответствии со своей ролью в команде и не отвлекаться на контент, ориентированный на читателей с другой ролью. Эта реструктуризация ещё в процессе: появился новый раздел для DevOps-инженеров , а также дополнительные разделы для администраторов баз данных, разработчиков приложений, инженеров по безопасности, аналитиков и т.д. Перемещение контента может потребовать выработки новых привычек, но в долгосрочной перспективе такая структура должна упростить навигацию. Мы создаём перенаправление со старого URL на новый при перемещении любой страницы документации, чтобы свести неудобства к минимуму.

https://habr.com/ru/companies/ydb/articles/804775/

Обновление кешей сервисов в реальном времени с помощью YDB CDC на примере Yandex Monitoring

Меня зовут Егор Литвиненко. Я старший разработчик Yandex Observability Platform. Летом 2023 года я рассказывал на Saint Highload в Санкт-Петербурге про наш путь внедрения YDB CDC для обновления данных в сервисах, чтобы решить проблему инвалидации кэшей. В этой статье будет вся история внедрения с теорией, вопросами, ответами, ошибками, о которых я говорил на выступлении. Но кроме того, в конце есть обновления: что произошло и изменилось за это время. Мы рассмотрим весь процесс от появления задачи до результата: • какие подходы к доставке изменений мы использовали; • почему выбрали переход на CDC и в чем были сложности в работе с изменениями до этого; • чем YDB CDC отличается от других решений, как настроить правильно, и на какие грабли мы наступили в процессе; • какую модель данных выбрать, чтобы решить проблемы с конкурентными изменениями; • как поддерживать решение после внедрения.

https://habr.com/ru/companies/oleg-bunin/articles/801603/

[Перевод] Когда одного Postgres'a мало: сравнение производительности PostgreSQL и распределенных СУБД

Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера. Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C , который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP). Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.

https://habr.com/ru/companies/ydb/articles/801587/

Миграции в YDB с помощью «goose»

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

https://habr.com/ru/companies/ydb/articles/783254/