Производительность с последовательно увеличивающимся первичным ключом

Question

Требуется руководство по выбору поставщика базы данных для определенной комбинации клавиш.

Единственным ключевым полем будет предварительно выделенное уникальное последовательно увеличивающееся число. В течение каждого дня между 50 и 100 тысяч предметов будут добавлены, обрабатывается (обновляется), а затем сохраняется в течение недели или около того, после чего обычно удаляются записи с наименьшим номером. Номер записи не будут сильно колебаться изо дня в день, но могут упасть в выходные дни. Числа, вероятно, вернутся к 1 после 100M или около того.

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

Answer 1

поиск, добавление и удаление индекса остаются постоянными

Вы можете убедиться, что он остается постоянным, перестраивая индексы при каждой вставке (просто постоянно очень медленно - вообще не снижая производительность :)), или близко к постоянному, выполняя обслуживание индекса каждый час / день и т. Д.

что производительность может упасть при непрерывном движении диапазона значений ключа?

Пока у вас есть индекс, это должна быть производительность logN - например, количество строк в 1,000,000 будет примерно вдвое меньше, чем у 1000 строк (при поиске индексированного значения). (1 000 000 000 000 снова будет вдвое меньше этой скорости).

Так что нет, вам не нужно беспокоиться о производительности.

Числа, вероятно, вернутся к 1 после 100M или около того.

Хорошо, если хотите. Как правило, на самом деле не нужно - просто используйте большой int.

Как всегда с производительностью: проверьте, что вы хотите сделать. Создайте скрипт, который вставит 10 000 000 строк, и посмотрите, что произойдет.

Суть в том, что если вы собираетесь обернуть идентификаторы в 100M записей, самое худшее, что вы можете сделать, это на самом деле выделить их все. Это также будет отражать состояние фрагментированного индекса (где, скажем, у вас есть только 100К записей, но они распределены в пространстве 10М), но вы будете выполнять обслуживание индекса / базы данных, верно?