Базы данных *

Большинство enterprise-приложений работают с БД в том или ином виде. Чаще всего в качестве БД выступает реляционная DBMS, например, PostgreSQL или Oracle. Относительно часто для доступа к данным используют Hibernate. Ранее он предлагал только одну спецификацию — JPA (Java Persistence API), она же Jakarta. Но теперь Hibernate реализует ещё и Jakarta Data.

Jakarta Data — это новая спецификация под зонтиком проекта Jakarta EE (как и JPA), которая упрощает интеграцию данных в корпоративных Java-приложениях. Обе эти спецификации разрабатывает Eclipse Foundation, и в частности Gavin King, создатель Hibernate.

Большинство разработчиков привыкли работать с Hibernate именно через Spring Data JPA. Изначально, когда только обсуждали спецификацию Jakarta Data, Spring Data (не обязательно JPA) была одним из тех проектов, который, в перспективе, мог бы реализовать спецификацию Jakarta Data. Но этого не произошло, и, несмотря на то, что изначально команда Spring Data была вовлечена в процесс создания спецификации, они отказались от идеи реализовывать Jakarta Data, и та стала развиваться самостоятельно. Сегодня Jakarta Data применяют в Hibernate, Open Liberty и ряде более мелких решений. Как же так вышло?

Меня зовут Михаил Поливаха, я практикующий инженер и активный коммитер Spring Data. В этой статье я расскажу об особенностях Jakarta Data, как она появилась и чем отличается от конкурентных решений. Я также расскажу, что помешало команде Spring Data реализовать Jakarta Data, и что же нас ждёт дальше.

TDE бывает разным: от шифрования на уровне TAM до полного кодирования всего кластера и меток tablespace. Мы сравниваем Percona, Cybertec/EDB, Pangolin/Fujitsu и показываем, где теряется производительность и надёжность, а где появляется гибкость. Дополнительно замдиректора департамента разработки продуктов Василий Бернштейн и старший инженер по ИБ Владимир Абрамов расскажут о том, как в Postgres Pro Enterprise реализована ротация ключей без полного переписывания таблиц и почему выбран AES‑GCM.

ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.

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

На связи снова Александр Гришин, руководитель по развитию продуктов хранения данных Selectel. В этой статье я разберу доступные параметры конфигурации Kafka-кластеров в облачных базах данных: от настроек репликации и ретеншена до лимитов на продюсеров и потребителей. Мы посмотрим, как каждый параметр влияет на производительность и надежность, приведем практические рекомендации для разных сценариев — от высокочастотных событий до больших архивных потоков.

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

В службу технической поддержки нередко приходят вопросы, связанные с добавлением собственных элементов в модуль «Сети» nanoCAD GeoniCS. Наша статья раскроет возможности использования утилит при работе с базой данных (БД) этого модуля.

Привет, Хабр! Наверняка каждый разработчик или администратор сталкивался с ситуацией, когда для проверки гипотезы или нового функционала срочно нужна «чистая» база данных. Приходится либо искать свободный сервер, либо разворачивать всё локально, тратя время на установку и настройку. А если таких тестовых баз нужны десятки для команды или разных команд? У наших клиентов мы видели целый зоопарк из PostgreSQL разных версий и конфигураций, поддержка которых превращалась в головную боль. Именно эту проблему — создание «одноразовых» и легковесных баз по одному клику — мы и решили. Меня зовут Сергей Гонцов, я занимаюсь развитием СУБД, основанной на PostgreSQL, которая совсем недавно перешла «под крыло» Arenadata и называется теперь Arenadata Prosperity (ADP). В этой статье расскажу нашу историю, как мы готовили свой DBaaS-сервис.

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

Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.

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

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

Есть альтернативный вариант — доработать свой сайт и в разы снизить риски проблем с законом.

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

Привет, Хабр.

Сегодня разбираем COPY в PostgreSQL. Это рабочая лошадка для массовой загрузки и выгрузки данных.

41 ТБ/сутки по маршруту Oracle → Postgres Pro без остановки исходной системы — это не теория, а цифры последних тестов. Мы разложили миграцию на три этапа: быструю начальную загрузку, CDC из redo-логов и валидацию, и собрали их в ProGate. Как устроен конвейер, почему Go и где прячутся узкие места — расскажем в статье.

Представьте, что в основе вашего коммерческого продукта используется компонент с исходным кодом, который написан на смеси языка С и самописного ассемблера. Из-за слабой детерминированности поиск репродьюсеров сложен, а без репродьюсера мейнтейнер проекта заявляет: «Сделайте так, чтобы я про вас больше не слышал». Я расскажу, как мы построили процесс активной поддержки LuaJIT в СУБД Tarantool, сократили количество инцидентов в продакшене, сократили затраты на бэкпорт патчей из основного проекта и какую роль во всем этом сыграл фаззинг и его специфика.

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

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

Я рассмотрю специфику работы с проектом исходного кода на примере LuaJIT, расскажу, как устроено тестирование в нашем форке и какую роль там играет фаззинг. Расскажу о специфике фаззинга LuaJIT и о том, каких результатов мы в этом достигли за последние два года.

Привет! Меня зовут Антон Головенко и я backend-разработчик команды Search-Quality в Авито. Вот уже полтора года я ускоряю производительность поиска и повышаю его надежность, а также участвую в интеграции новых продуктов. В статье расскажу о том, как мы тестировали Redis под нагрузкой, с какими проблемами столкнулись, как их решали и какие выводы сделали. Заголовок звучит кликбейтно — но вы скоро поймёте, что он полностью оправдан.

В первой части мы разбирались, как Firebird забирает строку таблицы с диска. Во второй и третьей частях мы разбирались, что происходит с прочитанной строкой в процессе выполнения SELECT-запроса. Но остался неотвеченным такой вопрос: а как указать на строку таблицы, которую надо прочитать? Этим вопросом мы и займёмся.

Если вы когда‑либо занимались построением отчётов в Power BI, то наверняка сталкивались с просьбой «заменить пустые значения на ноль — чтобы было красиво». Кажется, мелочь. Но на самом деле это решение может незаметно убить производительность модели, превратить быстрый отчёт в тормозящий интерфейс, а оптимизатор — в беспомощного наблюдателя. В этой статье — разбор того, что происходит под капотом VertiPaq, как DAX на самом деле обрабатывает BLANK, и почему иногда лучше оставить пустое значение пустым.

ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.

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

В этой статье мы проведем сравнительный анализ самостоятельного развертывания баз данных и управляемых DBaaS-решений. Посмотрим, какая модель дает стратегическое преимущество. Подробности под катом!

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

Эта статья основана на нашем выступлении на конференции QCon San Francisco 2024, где мы рассмотрели эволюцию подходов к индексированию данных, их извлечению и ранжированию. Для платформ вроде Uber Eats, обрабатывающих сложные запросы на больших объёмах данных, оптимизация поиска — это серьёзный вызов, требующий продвинутых стратегий: индексирования, шардинга и параллельной обработки запросов.

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

Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц.

В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

Привет, Хабр!

Сегодня мы рассмотрим Resource Groups в MySQL — и перестанем жить на одной CPU.

Resource Groups — это контроль над CPU прямо из SQL. Вы создаёте логическую группу, говорите «эта группа может использовать только 2 CPU и работать на низком приоритете», и назначаете туда тяжелые, но второстепенные задачи. Всё. Дальше MySQL сам всё регулирует.