Индексирование против индексации при вставке записей

Question

У меня есть несколько вопросов о том, было бы лучше не использовать индексацию.

ПРЕДПОСЫЛКА: Мои записи имеют атрибут timestamp, и записи будут вставлены в порядке их временных меток (то есть вставлены в хронологическом порядке).

ВОПРОСЫ:

1. Если я НЕ использовать индексирование это типично для базы данных для вставки записей в порядке, что они были введены?

2. Если ответ на # 1 - это да, когда я делаю запрос типа «SELECT .. WHERE timestamp> X», то база данных будет эффективна на нем, или ему придется проходить через каждую запись, поскольку она не является " t проиндексировано? Я бы предположил, что если бы не было индекса, база данных не «знала», что записи были вставлены в отсортированный порядок и поэтому не могли использовать отсортированное свойство базы данных.

Я предполагаю, что кластерный индекс будет лучше для этих типов записей & их вставки.

Пожалуйста, дайте мне знать, что вы, ребята, думаете.

Спасибо, JBU

Answer 1

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

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

Answer 2

это зависит от базы данных, которую вы используете, конечно!

в общем, если у вас есть много вставок, чтобы сделать, это, вероятно, лучше отключить индексы, делать вставки, а затем воссоздать индексы

используя метку времени в качестве кластерного индекса (то есть порядок которые хранятся в строках) будет иметь значение только в том случае, если ваши наиболее распространенные запросы находятся во временном порядке (в отличие от retrieve-this-row), и если нет повторяющихся временных меток

Answer 3

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

Любой SELECT из таблицы без индексов приведет к сканированию таблицы. Индексы - это то, как вы «рассказываете» базу данных о таких вещах, как «отметки времени в порядке возрастания».

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

Answer 4

В какой базе данных?

1)
Таблица без индексов называется кучей. Куча будет хранить записи в том порядке, в котором они были вставлены. Пока вы не вставляете из нескольких потоков, вы сможете предсказать порядок хранения базы данных в базе данных. Как указывали другие, это предполагает, что вы не делаете удаления, и в этом случае ваша СУБД может заполните пустые страницы новыми строками.

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

Answer 5

Я jbu, создатель сообщения.

Спасибо за быстрый вход для всех.

Для решения дальнейших вопросов:

Да у меня есть статические данные - я не буду удалять.

Я тестирую несколько разных баз данных: Sybase SQL Anywhere, Oracle Berkeley DB, H2, Firebird, SQLite и, возможно, несколько других.

Стивен Лоу: У моего стола будет миллион записей (он вырастет до 32 ГБ максимум). Если я отключу индексирование на некоторое время, а затем воссоздаю индекс, это не займет много времени - по крайней мере, несколько минут (я предполагаю, что это может занять гораздо больше времени)? Кроме того, я думаю, вы предполагаете, что произойдет разрыв непрерывного потока вставок. Я почти постоянно буду вставлять с помощью коммитов в пакетной вставке, поэтому я не думаю, что у моего процессора и диска когда-нибудь будет перерыв, чтобы переиндексировать.

Опять же, спасибо за вход ребята.

JBU

Answer 6

Это типично, но это не гарантирует какой-либо конкретной реализации, AFAIK. По этой причине было бы нецелесообразно зависеть от этого. Оптимизатор запросов также не зависит от него, поэтому он будет выполнять сканирование таблицы.

Сгруппированный указатель на метку времени в вашем случае действительно не имеет недостатков. Вы можете заполнить 100% ваших страниц данных, и вам все равно будет не хуже, чем куча. Однако запросы могут воспользоваться этим и будут находиться где угодно от незначительного (если вы возвращаетесь, например, 90% от таблицы) до смешного (если вы возвращаете, например, 1% от таблицы) быстрее ,

Answer 7

Я считаю, что в соответствии со стандартом sql вы никогда не можете быть уверены в порядке выбора строк в неустановленной колонке. Даже если вы тестируете данную базу данных и считаете ее в настоящее время действительной, это может быть не так при следующей ревизии базы данных. Мой опыт секунд Стивен Лоу. Если вы вставляете большое количество строк в таблицу, отключите (или удалите) строки перед вставкой. Воспроизведение индексов после вставки займет меньше времени, чем вставки с включенными индексами.

Алан

Answer 8

Вам необходимо создать индекс по столбцу временной метки, чтобы быть в состоянии найти свою метку. Просто сделай это (ТМ).

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

Answer 9

Кластеризованный индекс - это порядок, в котором записи хранятся на диске. Всегда будет один, независимо от того, укажите ли вы один или нет, так как на диске должен быть заказ.

Это нормально, если первичный ключ также является кластеризованным индексом, но это не обязательно.

Если вы делаете пакетные вставки, вы, вероятно, будете иметь вложенные записи с одинаковой меткой времени. Очевидно, это не может быть первичным ключом.

Чтобы сделать запрос типа «SELECT .. WHERE timestamp> X», индекс в поле «timestamp» улучшит производительность этого запроса, будь он кластеризован или нет.

Следует ли группировать индекс в поле «метка времени» и вам нужны другие индексы, будет зависеть от всех запросов, которые вам понадобятся для выполнения данных.