До postgresql версии 13, если я не ошибаюсь, индексы были в полтора, а то и два раза больше. У нас на проекте версия 9, если не ошибаюсь, там индексы добавляют к памяти иногда по 5 гигов. Нормально ли это? Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.
Работаю с базами данных давно. Начинал с
Oracle9i.
Большая часть индексов базируются на B+Tree. Хотя в последнее время в эпоху
RocksDb/Cassandra/Tarantool
появились более интересные стурктуры такие как LSM-tree. Они по скорости записи более эффективны.
Про то что индексы должны быть размером в мегабайты - я впервые слышу. Возможно это фраза
вырвана из контекста. Там обсуждалось что-то другое. Поэтому приведите цитату на документацию.
Желательно от производителя БД.
В Оракле есть положительный эффект от периодической перестройки индекса (alter index rebuild).
Этот эффект временный и обычно связан с фактором кластеризации. Его очень любят новички и
часто сам вопрос является троллингом Oracle-профессионалов. Но это было лет 20 назад. Щас
в эпоху облак всем стало пофиг.
Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?
Не знаю откуда ты такие вот факты черпаешь. Конечно лучше всю базу данных положить в память.
Но база обычно многократно превышает память и мы довольствуемся страничным кешем (page cache)
или buffer pool в других системах. И все они работают по принципу LRU (хранения наиболее горячих
блоков диска). А будет ли это таблица или индекс или еще какойто подвид объекта - это как повезет.
Во всех DBMS есть мониторинг этого страничного кеша. Вот посмотри что у тебя там лежит в час
наибольшей нагрузки. Это и будет самый правильный ответ на твой вопрос. И главное - практически
подтвержденный.
Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице. В каких случаях и почему так бывает?
Приводи ссылки где ты читал потому-что в твоем пересказе получается мистика. Индекс обязан хранить
копии индексируемых столбцов. Иначе-бы поиск вообще не работал.
Если ты строишь
композитный индекс по 3 полям то он и будет физически хранить 3 копии этих полей
и ROWID (физический указатель на позицию в таблице для строки). И при определенных условиях
оптимизатор может выдавать данные не из таблицы а прямо из индекса если в SELECT запросе
достаточно данных в индексе. Этим часто пользуются для оптимизации.
Есть альтернативные DBMS наподобие
Amazon DynamoDB где индексов нет но есть полная реплика
таблицы которая по другому кластеризована. Динамо считает это индексом хотя с точки зрения
классической DBMS это просто маркетинговый обман.
UPD: R+Tree
