В какой степени эффективное индексирование может преодолеть проблемы производительности с ОЧЕНЬ большими таблицами?

Question

Итак, мне кажется, что запрос к таблице с 10-тысячными записями и запрос к таблице с 10-миллионными записями почти одинаково быстр, если они оба извлекают примерно одинаковое количество записей и эффективно используют простые индексы (автоинкремент, индексируемое поле типа идентификатора записи).

Мой вопрос, будет ли это распространяться на таблицу с почти 4 миллиардами записей, если она правильно проиндексирована и база данных настроена таким образом, что запросы всегдаэффективно использовать эти индексы?

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

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

Answer 1

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

Если вы можете поместить свои «горячие» (т. Е. Часто посещаемые индексные страницы) в память, то доступ, как правило, будет быстрым.

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

Мифы и истина о секционировании базы данных SQL Server

Секционированные таблицы и индексы Oracle

Очень важно, чтобы ваши индексы были как можно более узкими.

Дебаты Кимберли Триппа о кластеризованном индексе продолжаются ... (SQL Server)

Answer 2

Доступ к данным через поиск по уникальному индексу замедлится, так как таблица становится очень большой, но ненамного. Индекс хранится в виде структуры B-дерева в Postgres (а не в двоичном дереве, которое имеет только двух дочерних элементов на узел), поэтому таблица строк 10 КБ может иметь 2 уровня, тогда как таблица строк 10 Б может иметь 4 уровня (в зависимости от ширины таблицы). строки). Так как таблица становится смехотворно большой, она может перейти на 5 уровней или выше, но это означает, что только одна дополнительная страница прочитана, поэтому, вероятно, не заметна.

Когда вы вставляете новые строки, вы не можете контролировать, где они вставляются в физический макет таблицы, поэтому я предполагаю, что вы имеете в виду «конец таблицы» с точки зрения использования максимального индексируемого значения. Я знаю, что в этом случае у Oracle есть некоторые оптимизации относительно разбиения блоков листьев, но я не знаю о Postgres.

Answer 3

Вот хорошее прочтение о больших таблицах и влиянии на них индексации, включая затраты / выгоды, как вы просили:

http://www.dba -oracle.com / t_indexing_power.htm

Answer 4

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