Live and recent posts from across the Fediverse tagged #индексы, aggregated by home.social.
Миллионы товаров и миллисекунды: как устроен специализированный движок каталога
Что происходит, если строить каталог на миллионах товаров не вокруг PostgreSQL и Elasticsearch, а вокруг mmap, собственных индексов и zero-allocation JSON? Разбираю архитектуру, компромиссы и реальные результаты на работающем агрегаторе: около 50 000 RPS и миллисекундные ответы.
https://habr.com/ru/articles/1081282/
#Go #mmap #базы_данных #индексы #производительность #высоконагруженные_системы #JSON
PostgreSQL в проде: блокировки, bloat и ночные пересчёты. Три инцидента и как их чинили
В прошлой статье я рассказывал, как мы перевозили терабайт банковской базы с Oracle на PostgreSQL без даунтайма. Там был раздел про производительность, и в комментариях несколько человек спросили примерно одно и то же: «а что конкретно вы дебажили и как?». Это продолжение. Три инцидента из двух разных проектов — банковской системы после миграции и enterprise-платформы на Java/Spring, где PostgreSQL жил под Hibernate. Разные домены, разные команды, но сюжет один: запрос, который вчера работал, сегодня не работает, а EXPLAIN показывает, что всё хорошо. Если вы пришли в PostgreSQL из Oracle или из мира, где база — это «то, куда ORM пишет», три четверти статьи будут про вещи, о существовании которых вы не подозревали. Я тоже не подозревал. Дисклеймер: проекты под NDA, названия, объёмы и часть деталей изменены. Порядок величин и сами инциденты — настоящие.
https://habr.com/ru/articles/1079692/
#PostgreSQL #базы_данных #СУБД #блокировки #deadlock #MVCC #bloat #транзакции #индексы #производительность
Индекс как алфавитный указатель: как база ищет и почему иногда не находит
В первой статье я объяснял кэш через холодильник. Продолжу тем же способом. Сейчас будет про индексы, а потом про то, почему индекс есть, а база его игнорирует. Статья для тех, кто индексы ставил, но EXPLAIN читал по диагонали.
https://habr.com/ru/articles/1075958/
#postgresql #индексы #explain_analyze #btree #составной_индекс #план_запроса #seq_scan #index_scan #оптимизация_запросов #sql
Как я сделал mmap-базу для 4 миллионов товаров и 700 тысяч посадочных страниц
Сделал mmap-базу для 4 млн товаров и получил ~35k RPS. Поиск оказался настолько быстрым, что bottleneck пришлось искать уже после базы. В итоге оптимизировал JSON, получил ~1.8× прироста HTTP workload — и упёрся в w.Write.
https://habr.com/ru/articles/1073724/
#Go #mmap #JSON #SilentJSON #Makodb #производительность #highload #индексы #sharding #СУБД
Вслед за Эдвардом Сьоре, или как я писал свою реализацию on disk B+Tree-индекса на Rust
Вслед за Эдвардом Сьоре, или как я писал свою реализацию on disk B+Tree-индекса на Rust. В этой статье попытаюсь осветить нюансы написание своего игрушечного индекса.
https://habr.com/ru/articles/1067032/
#rust #индексы #базы_данных #базы_данных_деревья #sql #структуры_данных
Индексируем диапазоны с помощью битовых масок, чтобы k8s не ломал индекс
Привет, это Антон Пионтковский из команды Monium Metrics, и вместе с коллегами мы создаём observability‑платформу для сбора, хранения и анализа телеметрии Yandex Monium. Мы храним миллиарды метрик и обрабатываем 50 гигабайт логов в секунду, а внутри Яндекса с Monium работают 16 тысяч сотрудников. Чтобы справиться с объёмом метаданных метрик Kubernetes, мы научились фильтровать их по времени. Сначала наивно с помощью линейного сканирования, и потому только для небольшого круга пользователей. Но результат нам так понравился, что мы захотели включить фильтр для всех. Поскольку первоначальный подход нельзя было скейлить, мы использовали специальный — range encoded bit sliced — индекс, и получили ускорение в 6–20 раз , а в удачных случаях — до двух порядков . Расскажу, как мы дошли до такой жизни, как устроен этот индекс, и что потребовалось сделать, чтобы всё в продакшн‑среде работало быстро.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/1055120/
#roaring_bitmap #структуры_данных #индексы #observability #yandex_monium
Django ORM ломается не там, где вы смотрели: шесть ошибок
Django ORM умеет долго скрывать проблемы: лишние запросы, гонки при save() , затянувшиеся транзакции и выборки, которые незаметно съедают память. В статье разберём шесть типичных ошибок, которые редко проявляются на тестовых данных, зато быстро становятся заметны под нагрузкой.
https://habr.com/ru/companies/otus/articles/1062496/
#Django_ORM #QuerySet #оптимизация_запросов #PostgreSQL #транзакции #индексы #N+1 #блокировки #массовые_операции #производительность
Ускорение в 200 раз — не предел
Всем привет, меня зовут Сергей Татарцев. Я эксперт-разработчик розничной АБС в банке Уралсиб. В финтехе уже много лет, в Уралсибе несколько месяцев и моя ключевая задача здесь – оптимизация в СУБД Oracle. Мне нравится эта тема, она дает развитие инженерному творчеству и очень похожа на спорт, где от подхода к подходу видишь, что взял бОльший вес штанги или планку выше предыдущей. Мое погружение в работу проходило постепенно, не было задач из серии «бросаемся на амбразуру». Процесс онбординга шёл плавно, в том числе и на тестовых задачах. В этой статье я хочу поделиться одним из таких тестовых заданий. Где мне удалось ускорить один простой запрос в 250 раз, а подход к решению задачи взят к применению на похожих кейсах .
https://habr.com/ru/companies/uralsib/articles/1057916/
#оптимизация #оптимизация_производительности #алгоритмы #plsql_oracle_database_базы_данных #plsql #математика #ускорение_запросов #базы_данных #индексы #кластеризация
PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря
Вы храните в PostgreSQL пользователей, заказы и платежи — а потом проект обрастает Redis для очереди, отдельным поисковиком и самодельными блокировками через таблицу locks. Иногда это оправдано. Но часто типовые бэкенд-задачи закрываются прямо в базе: атомарно, транзакционно, с индексами и без лишней сетевой болтовни. Привет, Хабр! Меня зовут Тимур Исламгулов. Я преподаватель МФТИ и ведущий вебинаров по PostgreSQL. За годы работы я насмотрелся, как разработчики поднимают лишнюю инфраструктуру там, где хватило бы самой базы, — об этом и поговорим. Показать рабочий SQL →
https://habr.com/ru/companies/netologyru/articles/1051792/
#postgresql #бэкенд #оконные_функции #sql #оптимизация_запросов #полнотекстовый_поиск #индексы #очередь_задач #базы_данных #skip_locked
ObjectId против UUID: как выбор _id в MongoDB влияет на API, индексы и миграции
_id в MongoDB кажется мелочью, пока не попадает в API, события и миграции. Разбираем, когда оставить стандартный ObjectId , когда нужен UUID , почему его лучше хранить как BSON Binary subtype 4 и зачем иногда разделять внутренний и публичный идентификатор.
https://habr.com/ru/articles/1046712/
#MongoDB #ObjectId #UUID #BSON #индексы #архитектура #API #базы_данных #идентификаторы
REDB: индексы, или почему на любую схему — это быстро
В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects , values , structures , как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache . Если не читали — начните с неё, без понимания схемы дальше тяжело. В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк». Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла : Code-first схемы ( SyncSchemeAsync<T> ), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL. Цифры, на которые опираемся, — с реального прода: TSUM, логистическая система, обслуживает движение грузовиков и заказов через РЦ.
https://habr.com/ru/articles/1045208/
#redb #dotnet #postgresql #mssql #индексы #производительность #c# #c#net
VARCHAR(N) в PostgreSQL: ограничение, а не экономия памяти
varchar(255) выглядит как аккуратное ограничение и часто воспринимается как способ сэкономить место. Но в PostgreSQL это не так: база хранит фактическую строку, а не заранее выделяет память под весь лимит. Разбираемся, что на самом деле делает VARCHAR(N) , чем он отличается от text , когда ограничение полезно, а когда просто превращается в число, которое притворяется архитектурой.
https://habr.com/ru/articles/1044476/
#PostgreSQL #SQL #VARCHAR #TEXT #базы_данных #производительность #индексы #backend
5 ошибок при миграции с PostgreSQL на ClickHouse: как не убить производительность индексами
В этой статье разбираем пять конкретных ошибок при миграции индексов, которые мы совершали сами на реальных проектах. Почему B‑tree не работает в колоночной СУБД? Как правильно спроектировать ORDER BY и PRIMARY KEY ? Когда использовать bloom_filter , а когда — материализованные представления?
https://habr.com/ru/companies/otus/articles/1031258/
#ClickHouse #PostgreSQL #индексы #миграция_баз_данных #производительность_БД #MergeTree #архитектура_данных
Ваш PostgreSQL болеет молча. Десяток запросов, чтобы это увидеть
Пятница, вечер. Один эндпоинт начал отвечать восемь секунд вместо двухсот миллисекунд, а в Grafana всё зелёное. PostgreSQL редко падает громко — он неделями копит мёртвые строки, лишние индексы и зависшие транзакции, пока не станет совсем плохо. В статье — пять SQL-запросов из моего queries.sql, которыми я реально пользуюсь: bloat и dead tuples, топ тяжёлых запросов по pg_stat_statements, неиспользуемые индексы, висящие транзакции и блокировки. Работают на голом PostgreSQL 13+
https://habr.com/ru/articles/1041480/
#postgresql #производительность #ide #sql #индексы #vacuum #bloat #транзакции #тяжелые_запросы
Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать
Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.
https://habr.com/ru/companies/otus/articles/1029706/
#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов
Почему PostgreSQL не использует ваш индекс
Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.
BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload
Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.
https://habr.com/ru/companies/otus/articles/1008372/
#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN
Типичный сервис: чиним одно, «ломаем» другое и решаем две проблемы сразу
Привет, Хабр! В этой статье мы расскажем о заочной борьбе с разработчиками объектного хранилища Hitachi Content Platform. Сначала мы столкнулись с критическим заполнением файловых систем индексов, а в процессе лечения обнаружили вторую, гораздо более глубокую проблему — одна из нод кластера фактически выпала из схемы хранения данных, оставаясь при этом «зелёной» в консоли. Материал будет полезен инженерам, работающим с HCP и другими объектными СХД, а также всем, кто любит истории о нетривиальных расследованиях в недрах корпоративного ПО.
https://habr.com/ru/companies/jetinfosystems/articles/1010708/
SQL за одну статью: от «SELECT *» до оконных функций и сложных JOIN-ов
Кажется, что в ИТ всё меняется каждые пару лет. Фреймворки рождаются и умирают, архитектурные подходы сменяют друг друга, но SQL стабильно остается на месте. Он спокойно пережил хайп вокруг NoSQL, эпоху Big Data и повсеместное внедрение нейросетей. Сегодня SQL давно перестал быть узким «языком админов». Это универсальный стандарт общения с данными, который жизненно необходим бэкендерам, аналитикам, QA-инженерам и даже продакт-менеджерам. В этой статье мы пропустим скучную академическую теорию и разберем только то, что реально нужно в работе. Мы пройдем путь от анатомии таблиц и базовых джоинов до оконных функций. А в конце заглянем под капот базы данных и разберем логический порядок выполнения запроса — секретный ингредиент, который навсегда избавит вас от вопроса: «Почему эта строчка не работает?!».
https://habr.com/ru/articles/1001796/
#sql #базы_данных #postgresql #join #select #оконные_функции #индексы #бэкенд #аналитика_данных #для_начинающих
[Перевод] Мы научили ИИ писать настоящий код для Postgres (и выложили в open source)
Когда ИИ за секунды генерирует «нормальную» схему Postgres, соблазн принять её как есть слишком велик. Проблема в том, что в этих схемах часто прячутся тихие минные поля: неудачные типы данных, странная индексация, путаница с идентификаторами, ловушки с временем и миграциями — всё то, что не ломает сборку сегодня, но превращается в боль через полгода в продакшене. В статье разберем, почему универсальные LLM регулярно промахиваются по нюансам именно Postgres, и как авторы пытаются закрыть эту дыру через pg-aiguide: набор «навыков» с лучшими практиками, версионный семантический поиск по официальной документации и интеграцию с код-агентами через MCP/плагин.
https://habr.com/ru/companies/otus/articles/993542/
#Postgres #миграции #индексы #типы_данных #LLMагенты #best_practices #postgresql
Как один индекс на created_at сократил время ответа API с 12 секунд до 40 мс
«Страница заказов грузится вечность», — такой тикет прилетел в понедельник утром. На проде 800 тысяч записей, а типичный запрос с фильтрацией и сортировкой заставлял менеджеров ждать по 12 секунд. В этой статье разберем, почему стандартный индекс по одному полю не сработал, как EXPLAIN ANALYZE помог найти «бутылочное горлышко» и почему порядок полей в составном индексе имеет решающее значение
https://habr.com/ru/articles/990398/
#PostgreSQL #Django #оптимизация_SQL #индексы #составной_индекс #EXPLAIN_ANALYZE #производительность_БД #backendразработка
[Перевод] Зачем мне тут DuckDB?
Оконные функции в SQL выглядят безобидно ровно до того момента, пока не попадают на реальные объёмы данных. В этой статье разбирается конкретный аналитический запрос в PostgreSQL: от формулировки задачи и использования lead() до детального анализа плана выполнения с EXPLAIN ANALYZE . Без абстракций и «магии оптимизатора» — только факты, цифры, сортировки на диск, буферы и выводы, которые полезно уметь делать любому аналитику, работающему с большими таблицами.
https://habr.com/ru/companies/otus/articles/989440/
#PostgreSQL #оконные_функции #сортировка_на_диск #индексы #оптимизация_SQL #work_mem #буферы
PostgreSQL и 1С: как построить систему поиска «тихих убийц» производительности
Стандартный мониторинг часто пропускает «тихих убийц» — запросы, которые по отдельности кажутся нормальными, но в сумме создают аномальную нагрузку на СУБД. В итоге система живет в хрупкой идиллии до первого аврала. В статье — описание универсального способа контроля качества кода и нагрузки на базу без выделенного DBA. Пошагово разберем поиск неоптимальных запросов с помощью pgBadger на живом кейсе.
https://habr.com/ru/articles/986306/
#PostgreSQL #1C #pgBadger #оптимизация #производительность #SQL #индексы #explain_analyze #sequential_scan #администрирование_бд
Как Reserve реализует on-chain индексы: разбор Index DTF
Идея Reserve простая: взять токены, упаковать их в один ERC-20 и получить on-chain индекс, который можно минтить, сжигать и ребалансировать без кастодианов и ручного управления. Но за простотой спрятана бизнес-логика: от расчёта доли пользователя в индексе до механизма ребалансировки. В статье я разбираю Index DTF в Reserve Protocol: архитектура смарт-контрактов, процессы mint и redeem индекса, механизм ребалансировки через голландские аукционы, управление индексом и риски протокола. Если интересно, как на практике реализован «децентрализованный ETF», то мой разбор про это.
https://habr.com/ru/articles/985326/
#Reserve #индексы #децентрализованный_ETF #Decentralized_Token_Folio #Index_DTF #портфель_токенов #диверсификация_портфеля #ребалансировка_портфеля
Black-White Array: новая структура данных с O(log N) аллокаций
Black-White Array (BWA) — это упорядоченная структура данных с амортизированным временем операций вставки/поиска/удаления и используемых участков памяти . Преимущества: • Амортизированное время вставки/удаления/поиска сравнимое с реализацией BTree от Google ; • Низкое количество аллокаций памяти при операциях вставки - меньше давления на сборщик мусора, ниже фрагментация памяти; • Массивы под капотом: данные лежат рядом, что улучшает кэшируемость процессором и скорость обхода/доступа к данным; • Позволяет хранить элементы с одинаковыми ключами - не нужно использовать дополнительные структуры для группировки таких элементов; • Низкий оверхед на хранение служебной информации - экономия памяти по сравнению с другими структурами данных; • Удобен для вставки батчами; • Простая сериализация и десериализация; Подробности
https://habr.com/ru/articles/984184/
#алгоритмы #структуры_данных #computer_science #множество #orderedset #производительность #optimization #allocation #индексы #оптимизация
[Перевод] Как ускорить MongoDB в Java: profiling, explain(), индексация и антипаттерны
Команда Spring АйО подготовила материал о том, почему «быстрый запрос в MongoDB» — это не магия, а дисциплина: индексы, форма запроса, проекции, explain(), профайлер и наблюдаемость в Java/Spring Boot. Разбираем, как отличать IXSCAN от COLLSCAN, где чаще всего прячутся антипаттерны (skip-пагинация, тяжёлые $regex/$nin, findAll), и как выстроить измеримый цикл оптимизаций от Atlas/Compass до Micrometer.
https://habr.com/ru/companies/spring_aio/articles/979440/
#MongoDB #производительность #индексы #explain #IXSCAN #COLLSCAN #SpringBoot #SpringData #профайлинг #мониторинг
Нейросеть против PostgreSQL: системные ошибки AI в прогнозировании производительности под нагрузкой
Использование нейросетей для оптимизации баз данных кажется перспективным направлением, но реальная эффективность таких систем требует тщательной проверки. В данном исследовании проанализирована способность нейросетевой модели точно прогнозировать производительность СУБД PostgreSQL в условиях экстремальной параллельной нагрузки. Результаты демонстрируют систематические ошибки AI, связанные с неспособностью учесть динамические аспекты работы СУБД. ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub kznalp/PG_EXPECTO: Комплекс статистического анализа производительности СУБД PostgreSQL pg-expecto/pg_expecto: Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
https://habr.com/ru/articles/969082/
#postgresql #postgresql_performance #искусственный_интеллект #нейросети #прогнозирование #анализ_производительности #индексы #высокая_нагрузка #статистический_анализ #deepseek
Записки оптимизатора 1С (ч.14.2). Пересчет индексов на SSD–дисках. Делаем или игнорируем?
В предыдущей статье обсуждали регламентное обслуживание с акцентом на пересчет статистик. Операция крайне полезная, необходимая и чем интенсивнее меняются данные в базе, тем важнее актуальные статистики. Сегодня поговорим про еще одну регламентную операцию – пересчет индексов. Как всегда с акцентом на высоконагруженные системы 1С. "Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?" Разберем подробно все нюансы.
https://habr.com/ru/companies/softpoint/articles/961356/
#SSD #пересчет_индексов #дефрагментация_индексов #производительность #perfexpert #очереди_к_диску #разбиение_страниц #обслуживание_баз_данных #1с #индексы
[Перевод] Эвристика: OR в SQL — это дорого
Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR , а второй — хитрую комбинацию AND . Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.
https://habr.com/ru/companies/postgrespro/articles/953506/
#оптимизация_запросов #планировщик_запросов #индексы #базы_данных #postgresql #postgres #postgresql_17 #postgresql_18
[Перевод] Как мы освободили 20 ГБ в PostgreSQL без удаления данных
Команда Python for Devs подготовила перевод статьи о том, как можно освободить десятки гигабайт места в PostgreSQL без удаления данных и индексов. TL;DR: удаляем неиспользуемые индексы, чистим bloat, пересобираем таблицы и используем частичные индексы, чтобы хранить только то, что реально нужно.
https://habr.com/ru/articles/944704/
#PostgreSQL #индексы #bloat #оптимизация #vaccum #частичные_индексы
#федичитальня #postgresql #postgresql15
Сортировка по индексу.
#Btree #индексы можно и для сортировки за O(n) использовать без буферизации всех строк где-либо. Но с неопределёнными значениями и порядком сортировки есть нюанс - положение их в индексе задаётся при создании и, если запрашиваемое положение отличается, то индекс не может быть использован.
Вообще странно, что не воткнули костыль для простейших случаев, если nulls не там, просто читаем индекс с другого конца, до тех пор, пока не наткнёмся на не #null, после чего начнём читать индекс так, как изначально и планировалось, до тех пор, пока не на кнёмся на null, который послужит нам эдаким EOF. Сложность чтения бы сохранилась линейной, всего пару переменных и ифников для стейт-контрола добавить. Не думаю, что это был бы значимый оверхед.
Обнаружил что #индексы не могут использоваться в случае если в запросе к полю применяется функция. Но и для этого есть обходной путь — можно индекс строить по этой же функции, а не по самому столбцу. При добавлении строки — правильно, будет вычисляться эта функция и результат запишется в индекс. Но при поиске, оно, скорее всего будет перепроверяться (re-check cond в explain). Ну, хоть не всю таблицу сканировать, конечно, но может это вычисление как-то можно избежать.