Базы данных *

Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.

Недавно на Хабре вышла статья с громким заголовком «Бенчмарк lakehouse‑движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех». В своей статье авторы из Кверифай Лабс выбрали методику TPC‑DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

Что делать если шаткие предположения о логике работы легаси проектов используют как фундамент для новой логики?

Как обезопасить легаси проект от рисков, которые не может покрыть стандартное тестирование?

Как все это сделать быстро и дешево? И при чем тут, возможно, новый вид тестирования?

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

Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.

В комментариях к предыдущему посту "Система резервации на 600 заказов в секунду без буферизации и другой дичи" только ленивый не упомянул явные блокировки в Postgres, как способ борьбы с дедлоками.

Это не удивительно, так как select for update - очень популярный прием во всех СУБД, даже на Хабре есть статья на эту тему.

Привет, Хабр! Я Роман Севрук, менеджер по развитию решений СУБД в К2Тех. Мы своего рода детективы на технологическом рынке — выслеживаем и разбираем каждое новое решение в сегменте российских баз данных.

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

Привет, Хабр! Меня зовут Виктор Смирнов. В Yandex Infrastructure я c недавнего времени занимаюсь фронтендом YQL: транслятором и инструментами разработки.

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

Привет, Хабр! На связи Маргарита Сорочинская, технический писатель отдела архитектуры в Рунити. Хочу рассказать, как мы в компании подошли к описанию API в Swagger — и почему решили перенести туда всё, что раньше жило в Confluence. А еще поделюсь с вами стартерпаком для описания API в Swagger, пошаговой инструкцией и всеми ссылками, чтобы для вас этот путь был уже более простым.

В этой статье я сделал обзор основных векторных баз данных: Milvus, Qdrant, Weaviate, ChromaDB, pgvector, Redis, pgvectorscale, LanceDB, ClickHouse, Vespa, Marqo, ElasticSearch.

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

БигДата всегда звучит красиво — пока не нужно по ним искать и за нее платить.

Когда данные перестают влезать в индекс, а поиск тормозит — дело не в БД, а в архитектуре.Рассказываю, как мы перестроили систему на связке PostGIS + OpenSearch и добились отклика в десятки миллисекунд.

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

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

Меня зовут Сергей Соловьёв, я руководитель отдела методологии в компании BPMSoft. Мы являемся разработчиком одноименной CRM-системы на базе low-code платформы со встроенными ИИ-инструментами. По версии Фонда Сколково и аналитического центра TAdviser, а также консалтинговой компании «Технологии доверия» – лучшей на российском рынке в 2024 году. В этой статье я расскажу, как мы управляем данными в собственной CRM и как это повышает эффективность бизнес-процессов.

Как появляется хаос

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

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

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

База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.

Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.

Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрипты.

Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.

Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.

В сегодняшней, уже третьей по счету, публикации я продолжу делится результатами нагрузочных испытаний вычислительных технологий массивных параллельных вычислений (на Habr уже представлены мои материалы, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS). В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.

Базы данных превращаются в «открытую книгу», когда конфиденциальная информация из них становится доступна злоумышленникам или широкой публике из-за утечек. К сожалению, 2024-2025 годы принесли множество таких утечек – в самых разных отраслях. Согласно данным Роскомнадзора, только в России за 2024 год было зафиксировано 135 утечек баз данных, затронувших более 710 млн записей о россиянах. Лидерами по количеству утечек стали торговый сектор и государственные организации. В мире тенденция схожая: глобально число утечек и скомпрометированных записей бьёт рекорды. В этой статье будут разобраны недавние громкие кейсы утечек по секторам (энергетика, госсектор, e-commerce и др.), проанализируем технические причины: от открытых портов NoSQL и слитых резервных копий до уязвимых CI/CD-пайплайнов, а также практические рекомендации, как не допустить, чтобы ваша база данных стала общедоступной библиотекой. Мы в Security Vision также рассматриваем эти задачи как ключевые в разработке решений нового поколения, в том числе в области автоматизации защиты баз данных и безопасной разработки.

Как вы думаете, сколько человек документирует продукты в Postgres Professional? 50? 100? А вот и нет — всего десять. Рассказываем, как команде техписателей удается управлять сотнями файлов, почему их работа — это квест, и как они успевают контрибьютить в ванильный PostgreSQL.

Предстоящий релиз Valkey 9.0 несёт в себе значительные улучшения в отказоустойчивости больших кластеров, позволяя масштабироваться до 2000 узлов и достигать производительности свыше 1 миллиарда запросов в секунду, и всё это с гарантированно ограниченным временем восстановления. В этой статье мы рассмотрим, как работает система кластеризации Valkey, а также архитектурные усовершенствования и тщательное тестирование, которые сделали возможным такой уровень масштабирования.