Базы данных *

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

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

Сегодня мы рассмотрим, как заставить PostgreSQL самостоятельно крутить K-Means для сегментации клиентов, не вытаскивая данные наружу. Пройдемся по циклу: нормализуем фичи в materialized view, напишем функцию PL/PythonU, которая дергает scikit-learn, сохраняем cluster_id обратно в таблицу и закрываем гештальт отчётом «доход по кластеру» чистым SQL.

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

Уже давно стали обыденными внедрения решений на платформе 1С:Предприятие на тысячу одновременных пользователей. Есть внедрения и более масштабные. И масштаб внедрений растёт. Поэтому мы решили убедиться, что платформа выдержит нагрузку нашего самого востребованного на крупных внедрениях решения 1C:ERP на 30 000 одновременно работающих пользователях.

Почему именно 30 000 пользователей, как мы измеряли производительность и как добились желаемой производительности — под катом.

В прошлом году мы сделали встроенную поддержку отказоустойчивости в Postgres Pro Enterprise — BiHA. Наше решение позволяет разворачивать отказоустойчивый кластер Postgres, в котором в случае сбоя пишущего узла новый пишущий узел (лидер) будет выбран автоматически.

В новой версии BiHA появилась возможность зарегистрировать пользовательские функции, которые будут вызваны при возникновении таких событий в кластере, как смена лидера, добавление/удаление ноды и других. Этот механизм мы назвали пользовательские колбэки. Разработчик программного обеспечения Postgres Professional Наталия Кокунина расскажет, как реализованы колбэки, и обсудит особенности их использования.

Недавно мы выпустили статью «Всё про Qdrant. Обзор векторной базы данных», в которой подробно познакомились с данным сервисом. Сегодня мы рассмотрим векторную БД с практической стороны. В статье будет описана инструкция по разработке no‑code RAG‑приложения на основе n8n с использованием Qdrant и OpenAI.

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

Большая часть времени планировщика запросов в СУБД тратится на поиск оптимального способа соединения таблиц. В PostgreSQL используется два алгоритма: алгоритм динамического программирования, также называемый DPsize, и генетический — GEQO. В других СУБД реализовано еще множество других алгоритмов. DPhyp — алгоритм соединения на основе гиперграфов — уже используется такими СУБД как MySQL и YDB. Я задался вопросом: можно ли реализовать его в PostgreSQL? Оказывается, можно. Так и зародилось расширение pg_dphyp для PostgreSQL, реализующее альтернативный алгоритм соединения таблиц. В статье я не описываю подробно сам алгоритм, привожу только концептуальное описание его идеи, а рассказываю вот о чем:

-- Какие решения пришлось принять, чтобы добавить алгоритм DPhyp в существующую кодовую базу без изменения ядра;
-- Как GPLv2 помог найти эффективный алгоритм обхода соседей;
-- Как проиндексировали неиндексируемое гиперрёбра;
-- Планирование какого запроса смогли ускорить в 600 раз;
-- Какой изъян в работе существующего планировщика был найден.

Но главный сюжетный поворот — в конце...

Всем привет!

Экспериментировал с оптимизацией SQL запросов в ChatGPT и Claude. В какой-то момент понял, что это превращается в одно и то же: Напиши промт → вставь SQL → подожди → поправь → повтори

Apache Flink 2.0 — первый мажорный релиз после 1.0 (2016), закрывающий многолетний цикл эволюции архитектуры и устраняющий накопленные болевые точки масштабирования потоковых платформ: усложняющуюся конфигурацию, ограниченность локального состояния, разрыв между batch и streaming, устаревшие API и операционную стоимость при росте AI/real‑time сценариев. В команде BitDive мы уже используем Flink 2.0 для низколатентной обработки потоковых метрик и трассировок (агрегация, выделение аномалий) — это позволило ускорить recovery и снизить стоимость вычислений по сравнению с линией 1.20.x.

Если вы работаете с базами данных, то вам определенно стоит иметь понимание о производительности кластера СУБД. Для этого можно использовать базовые метрики. А можно — метрики от DBaaS в сочетании с Grafana. Они позволяют строить кастомные графики, которые могут быть полезны в той или иной ситуации.

Привет! Меня зовут Рамиль Адильбеков, я DevOps-инженер в Selectel. В этой статье покажу, как можно настроить базовый стек Prometheus/Grafana, подключить метрики от кластера облачных баз данных и загрузить дашборд.

В этой статье мы посмотрим, как можно реализовать полную compile‑time валидацию SQL‑запросов на основе схемы базы данных, встраиваемой прямо в код. Без магии, без рантайма, без сторонних тулов. Только стандартный C++ и ваша структура БД. Валидация таблиц, столбцов, типов аргументов и их количества — всё на compile‑time.

Представьте, если бы компилятор сам указывал «такой таблицы нет», «несуществующий столбец», «несовместимые типы» — до запуска программы. Такой подход полностью устраняет «сюрпризы» во время исполнения и исключает класс ошибок, связанных с генерацией SQL во время работы программы. Ваша программа даже не соберётся.

Если вы настраивали отказоустойчивый кластер Postgres, то сталкивались с необходимостью перенаправления пользовательского трафика на пишущий узел после аварии на основном узле и переключения на резервный. Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения.

Разработчик программного обеспечения Postgres Professional Тофиг Алиев расскажет, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберет тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрит примеры использования и ответит на вопросы.

В новой версии YDB теперь доступны две версии векторного поиска — точный и приближённый. Приближённый поиск может работать с миллиардами векторов, если использовать векторный индекс. Такая технология есть у небольшого количества технологических компаний в мире.

Новый релиз СУБД Яндекса делает векторный поиск доступным для всех. Статья под катом написана по мотивам моего доклада на конференции HighLoad++, с которым я выступил 23 июня в Питере. В ней я расскажу про векторный поиск, индекс, RAG и о том, как эти технологии применяются в Алисе.

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

Меня зовут Артем Москальков, я — ведущий инженер данных в Магнит OMNI. В статье я расскажу о том, как мы оптимизировали производительность кластера в ClickHouse.

Частые мелкие вставки данных через Kafka Sink-коннектор серьёзно замедляли работу ClickHouse из-за огромного числа отдельных запросов. Путём настройки параметров потребителя Kafka и включения объединения партиций удалось сгруппировать записи в крупные блоки, что резко снизило нагрузку на базу и многократно увеличило её пропускную способность.

Это продолжение цикла, рассказывающего о практике развёртывания производственного кластера Cassandra. В первой части мы начали продвигаться вот по такому плану:

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

Продолжим?

Привет, Хабр! На связи снова Антон Дятлов, инженер по защите информации в Selectel. Буквально несколько дней назад мы с вами рассмотрели установку и безопасную настройку pgcrypto и изучили его основные возможности. Пришло время перейти к практическому применению этих знаний.

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

Вы когда-нибудь задумывались, что делает Power BI таким быстрым и мощным с точки зрения производительности? Настолько мощным, что он выполняет сложные вычисления над миллионами строк за мгновение.

В этой статье мы подробно рассмотрим, что находится «под капотом» Power BI: как данные хранятся, сжимаются, запрашиваются и, наконец, возвращаются в отчёт. После прочтения, надеюсь, у вас появится лучшее понимание того, что происходит в фоновом режиме, и вы сможете оценить важность создания оптимальной модели данных для достижения максимальной производительности с использованием движка Power BI.

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

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

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!