Базы данных *

Когда в проекте используются Spring Data, Hibernate, jOOQ или Slick, доступ к реляционной БД на JVM чаще всего заканчивается JDBC.

Разберём архитектуру JDBC: где заканчивается API и начинается драйвер, как Java находит реализацию, какую роль играют DataSource, Connection и пул соединений, а также какие ресурсы удерживаются на каждом этапе.

Материал для тех, кому важно понимать не только вызов executeQuery(), но и поведение системы под нагрузкой.

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

Не будем объяснять базу, но все знают, что магнитные головки HDD, прицепленные с одного конца "коромысла", приводятся в движение магнитной катушкой "Voice Coil" зажатой между двух неодимомых магнитов с другой стороны (а в современных дисках есть ещё и точный "доворот" пьезоэлементами на конце, недалеко от самих головок). Когда HDD надо переместить БМГ (Блок Магнитных Головок) на другую далёкую дорожку, он подаёт на Voice Coil резкий импульс тока, чтобы сорвать массивную металлическую конструкцию с места в нужном направлении, а потом ещё один обратный импульс тока для резкого торможения. Если посмотрите на фото БМГ, то поймёте как велика Voice Coil во всей этой конструкции и что ускорения и торможения происходят с довольно большими перегрузками. Это как если бы автомобиль весом 1.5 тонны разгонялся до 100 км/ч за 0.05...0.1 сек, а тормозил со скорости 100 км/ч на дистанции 1 метр и человек массов 80 кг потяжелел бы до 4 тонн. Если головки нужно перемещать в диапазоне до 50 дорожек, то Voice Coil не работает, достаточно пошевелить кончиком с головками с помощью пьезо-актуатора, который умеет гнуть металлический конец "коромысла" на 1...5 микрометров. И прыгать за 8 миллисекунд нужно не между тысячами дорожек, а по всей поверхности блина от края до края.

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

Меня зовут Илья Новиков, я технический директор компании «Исходный код».

Ранее карточки артистов создавались автоматически на основе заявок на выступления. Поначалу это казалось вполне приемлемым: артист подает заявку, система создает карточку, администраторы могут с ней работать.

На практике мы получили кучу дубликатов. В некоторых записях был один и тот же адрес электронной почты. В некоторых — один и тот же номер телефона. Некоторые были связаны и тем, и другим, но не всегда напрямую.

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

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

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

Что такое электронная таблица, объяснять не надо. Все знают Excel, и многие хоть раз им пользовались. История создания электронных таблиц тоже, на первый взгляд, незамысловатая и сравнительно недолгая: как только появились первые ПК, сразу началась разработка ПО для выведения на экран их монитора интерактивной таблицы, которая сильно облегчила бы работу бухгалтеров и менеджеров. IT-инженеры уложились в 15 лет, с конца 60-х до середины 80-х, чтобы создать электронную таблицу от начала и до конца – от разработки самого принципа ее программирования до появления первых электронных таблиц (от VisiCalc до Excel) на экране ПК, сильно порадовав тем самым белых воротничков (и не только их). Дальше шло лишь усовершенствование электронных таблиц.

С чего вдруг IT-инженеры и изобретатели озаботились бухгалтерскими проблемами, тоже понятно. Люди старшего поколения помнят, что можно было делать на первых ПК 70-х и 80-х годов, еще до эпохи интернета. Если оставить в стороне возможность самостоятельно заняться программированием и обмениваться файлами с такими же энтузиастами, что сейчас часто ставят в заслугу первым ПК (для этого все-таки надо было в душе быть айтишником), то на этих ПК можно было играть в интерактивные игры (правда, на игровых приставках к телевизору это обходилось дешевле) и можно было использовать ПК как пишущую машинку, при пользовании которой не надо было замазывать белилами ошибки и ждать, когда те высохнут, чтобы напечатать поверх правильную букву. Сказать, что это сильно порадовало писателей и редакторов бумажных СМИ значит ничего не сказать, это была настоящая революция в писательском и издательском деле, сравнимая разве что с изобретением печатного станка Гутенбергом в XV веке. А когда к этому добавились еще электронные таблицы для сведения дебета с кредетом в интерактивном режиме, это была еще одна революция в бухгалтерии того же масштаба, если не большего.

Привет, Хабр! Меня зовут Роман Ананьев из команды DBA в Авито. В этой статье я расскажу о поиске альтернативы для многошардовых инсталляций MongoDB. Основная цель исследования — найти базу данных с поддержкой автошардирования, которая упростит эксплуатацию и лучше утилизирует ресурсы.

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

Это текст не про то, что MongoDB плохая, она — прекрасный стандарт рынка, в топ-5 движков БД. Я расскажу про то, что происходит, когда у стандартной технологии заканчивается запас прочности на нужном масштабе, и про то, как мы в Авито перебрали множество NoSQL и NewSQL кандидатов, чтобы найти одного подходящего.

В статье я разберу результаты технического исследования, проведённого командой DBA. Мы сравнили производительность, утилизацию ресурсов и архитектурные грабли Cassandra 5, FoundationDB и других БД. Также объясню, почему погоня за низкой latency в случае с FDB обернулась трёхкратным перерасходом дискового пространства.

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Утечка данных почти никогда не выглядит как взлом — чаще это тихий SELECT без LIMIT от роли, у которой и так есть доступ. Заметить такое штатными средствами PostgreSQL почти невозможно: аудита как отдельной подсистемы там нет, а есть лишь разрозненные логи, из которых расследование превращается в quest с grep. В этой статье — как с помощью pg_proaudit и pgpro-otel-collector превратить эту головную боль в один запрос на LogsQL.

Ряд аналитиков середины 2010-х отмечали, что язык SQL — один из самых важных и нужных для программистов. Ведь он распространен максимально широко: им пользуется бизнес, государственные учреждения, вузы, финансовые структуры и так далее. В нашей статье — о том, как этот язык появился и какие патенты на него были получены.

Полгода назад я начал писать in-memory базу с векторным поиском на Go: RESP-протокол, HNSW-индекс, WAL, многопоточность. Рассказываю, что из этого вышло: как я мерил производительность и на каких граблях стоял, что реально ускоряет векторный поиск, а что нет. Все цифры воспроизводимы, код открыт.

Redis долго был понятным выбором: BSD-лицензия, можно использовать почти где угодно. После смены лицензии в 2024 году всё стало сложнее: RSAL, SSPL, AGPLv3, Valkey, форки и вопросы к юристам.

В статье рассматриваю этот вопрос со стороны обычных продуктовых команд, а не облачных провайдеров. Если Redis у вас внутри как кеш, очередь или для сессий, что реально меняется, где начинаются риски и что сегодня разумнее выбрать - Redis 8, Valkey или другой Redis-compatible вариант.

Тест на List.AsQueryable() зелёный, а на проде всплывают LINQ-трансляция, null, collation, unique index и два воркера, забравшие один платёж. Разбираю, где in-memory тесты помогают, а где начинают врать.

Краткая история внешней памяти и пять функций листа бумаги

Не претендуя на гениальность задался простым, на первый взгляд, вопросом: "На моем столе в 2026г всегда лежит лист черновика и пара карандашей?" Ответ оказался не таким коротким, как ожидал. Приглашаю к прочтению!

8 июля у PostgreSQL юбилей — ей исполняется 30 лет. В 1996 году Марк Фурнье из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres. До этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли .

В день рожденья PostgreSQL мы публикуем перевод статьи, которая послужила основой СУБД. Кстати, у неё тоже юбилей — 40 лет с момента выхода.

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.

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

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

Сначала задача звучала просто: складывать PDF, CVE и статьи по кибербезопасности в одну базу, затем давать LLM-агенту подходящие фрагменты через HTTP API. На доске это помещалось в одну цепочку: загрузка, извлечение текста, разбиение на части, построение векторов, поиск.

Рабочий прототип появился быстро. Настоящая работа началась потом.

В статье рассматриваются особенности использования ограничений целостности с проверкой, которую можно отложить до фиксации транзакции, а также использование системных триггеров для проверки ограничений целостности. Триггеры создаются для любых внешних ключей - и с немедленной и отложенной проверкой, а для уникальных ключей - только для ограничений с отложенной проверкой. Для уникальных откладываемых ключей создаются уникальные индексы, которые допускают неуникальные значения. В таблице могут находиться строки, нарушающие ограничение уникальности, при том, что статус ограничения целостности в системном каталоге "проверено" (validated).

Задача широко знакома в узких кругах: наш каталог товаров встречается с каталогом контрагента — по сути одни и те же позиции, но названы по-разному. Надо найти совпадения и предоставить коллегам список подходящих наших артикулов для каждой их позиции.

В разобранном ниже случае это картриджи: 22 тысячи записей у контрагента против сотен тысяч наших номенклатур. Для такой задачи матерый программист берёт Elasticsearch, алгоритмы нечёткого поиска и тратит много времени, иногда в меру матерясь. Здесь подбор ведется с помощью токенизации, запросами в стиле no-code и без ИИ.

На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь CPU, за который вы заплатили, либо одного сервера перестаёт хватать — по объёму, по пропускной способности или просто потому, что сервер может выйти из строя, и данные на нём будут потеряны.

Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах: