Базы данных *

Способность открытых LLM шутить, причем по-доброму, могла бы расширить применение ИИ во многих сферах – образовании, терапии, обслуживании клиентов. Так что мы с коллегами из Лаборатории естественного языка НИУ ВШЭ задались этим вопросом и попытались разработать собственную методологию курирования (фильтрации и аннотирования) наборов данных для генерации доброго юмора на малых LM. По всем научным канонам мы ее описали и оценили в этом препринте. А здесь я постараюсь рассказать о ней чуть короче и менее научно.

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?

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

В арсенале Postgres Pro есть мощное, но порой недооцененное оружие — декларативное секционирование. Оно только звучит сложно, а на деле позволяет элегантно «нарезать» гигантские таблицы, превращая их из неповоротливых монстров в управляемые и быстрые структуры. Делимся нетайными знаниями, которые помогут оптимизировать запросы и упростить жизнь. 

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

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

Почти в каждой системе встречается требование «не удалять данные окончательно».

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

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

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

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

Согласны? Узнали? Тогда поехали!

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

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

ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?

В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.

Эффективная работа с хранилищем невозможна без участия бизнес- и системных аналитиков, которые проектируют структуры данных, очищают и объединяют информацию, адаптируя решения под меняющиеся задачи. С ростом объёмов данных и требований к скорости анализа даже опытные команды сталкиваются с вызовами. Рутинные операции — проектирование схем, поиск таблиц, проверка качества данных — требуют не только технических навыков, но и глубокого понимания бизнес-контекста. Большую часть времени занимает написание и оптимизация SQL-запросов, что становится «узким местом» в условиях динамично меняющихся требований.

Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL. 

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

Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor. Почему однократная настройка числа приводит к неожиданным page split, bloat и мучительному откату запросов? Давайте разбираться.

Для анализа и обработки больших объёмов данных применяются специальные системы — OLAP (Online Analytical Processing). Мы разберём основные принципы их работы, преимущества и примеры использования.

Определение OLAP-систем

OLAP-системы — это инструменты для анализа данных, которые позволяют быстро и эффективно находить ответы на сложные вопросы. 

Они находят применение в разных сферах, таких как финансы, производство, розничная торговля и другие.

Пример использования OLAP-технологии

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

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

Меня зовут Владимир Ревякин, я старший инженер-программист компании «МойОфис», и вместе с QA-инженером Анной Рукавицыной мы подготовили этот материал, чтобы поделиться опытом реализации функции шаринга данных через графовую базу ArangoDB в рамках разработки платформы «Документы Онлайн». Если коротко — это продукт для совместной работы и хранения документов в рамках единой мультипродуктовой экосистемы.

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

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

А началось всё просто: пока все вокруг спорят как настраивать железо и тюнить операционные системы дабы выжать лишних TPS, мы решили проверить как отреагирует движок PostgreSQL если загрузить в него действительно большой объём данных. Например, давайте сделаем базу размером один петабайт и посмотрим как он это переживёт.

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

Как я поднял базу знаний за 15 минут — без бюджета и опыта

Почему я выбрал именно BookStack

Мы в команде давно искали удобный инструмент для хранения технической документации и инструкций. Пробовали всё подряд — от Wiki.js до Confluence. Но то санкции, то интерфейс перегружен, то кастомизация страдает. В какой-то момент я наткнулся на BookStack — лёгкую, симпатичную open-source платформу на Laravel. Решил попробовать. В итоге — развернул, настроил, и теперь она у нас в проде.

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

Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.

На Reddit я наткнулся на статью про обработку создания 100 тысяч коротких URL в секунду¹. [Прим. пер.: автор статьи по ссылке создал три варианта системы; третий, наилучший, по его мнению, вариант при помощи кластера-координатора делит нагрузку на несколько ECS-воркеров, использует DynamoDB TransactWrite для пакетных условных вставок, а для устойчивости применяет кэш Redis.]

Какой же это запутанный оверинжиниренный бардак!

Не поймите меня неправильно: я люблю оверинжиниринг, но только в обучающих хобби-проектах. Как сказали многие комментаторы на Reddit, в образовательных учреждениях редко преподают распределённые системы и архитектуру ПО. Когда новички попадают в нашу отрасль, из-за подобных постов, написанных авторитетными на вид техлидами, они могут подумать, что оверинжиниринг — это единственный способ работы. Однако часто решение может быть гораздо проще.

Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.

Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.

В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).

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

Далее представлен перевод статьи “5 things to look for in a database monitoring tool”, который подготовил специалист «Автомакон» специально для русскоязычной аудитории. Исходная публикация посвящена ключевым критериям подбора оптимального инструмента для мониторинга баз данных крупными организациями, столкнувшимися с необходимостью обработки больших объёмов данных и увеличения сложности информационных систем.