Indexation ou pas d'indexation lors de l'insertion d'enregistrements

Question

Je me demande si l'indexation est préférable ou non. CONTEXTE: Mes enregistrements ont un attribut d'horodatage, et les enregistrements seront insérés dans l'ordre de leurs horodatages (c'est-à-dire insérés chronologiquement).

QUESTIONS:

1. Si je n'utilise pas l'indexation est-il typique de la base de données pour insérer les enregistrements dans l'ordre qu'ils ont été insérés?

2. Si la réponse à # 1 est oui, quand je fais une requête de type "SELECT .. WHERE timestamp> X" la base de données sera efficace, ou devra-t-elle passer par tous les enregistrements puisqu'elle n'est pas t indexé? Je suppose que s'il n'y avait pas d'index, la base de données ne "connaîtrait" pas que les enregistrements étaient insérés dans un ordre trié et ne pourrait donc pas utiliser la propriété triée de la base de données.

Je suppose un index ordonné en clusters serait le mieux pour ces types d'enregistrements & leurs inserts.

S'il vous plaît laissez-moi savoir ce que vous en pensez les gars.

Merci, JBU

Answer 1

Dans mon expérience, oui, la base de données va insérer des choses dans l'ordre chronologique, surtout si vous ne supprimez jamais quoi que ce soit. Cependant, ce n'est pas garanti, et c'est une très mauvaise idée d'essayer de s'appuyer sur un comportement qui n'est pas garanti.

En outre, le planificateur de requêtes ne connaîtra pas ce fait. Par conséquent, toute requête effectuée sans index entraînera une analyse complète de la table. Que ce soit plus lent qu'une requête indexée dépendra beaucoup du type de données que vous avez, et quel pourcentage de celui-ci vient après le "X" dans votre requête.

Answer 2

cela dépend de la base de données que vous utilisez, bien sûr!

en général, si vous avez beaucoup d'inserts à faire, il est probablement préférable de désactiver les indices, faire les inserts, puis recréer les indices

en utilisant l'horodatage comme l'index ordonné en clusters (ie l'ordre que les lignes sont stockées) n'aura d'importance que si vos requêtes les plus courantes sont dans l'ordre chronologique (par opposition à retrieve-this-row) et s'il n'y a pas d'horodatage en double

Answer 3

S'il n'y a jamais de suppressions dans la table, vous peut supposer que la base de données ajoutera simplement de nouveaux blocs à la fin de la table. Cependant, il n'y a aucune garantie quant à savoir si ces blocs sur le disque sont contigus, ou même avancent correctement (c'est-à-dire que la table peut bien être fragmentée au fil du temps).

Tout SELECT à partir d'une table sans index entraînera un balayage de table. Les index sont la façon dont vous "dites" à la base de données à propos de choses comme "les horodatages sont dans l'ordre croissant".

Un index clusterisé est bon pour indiquer à la base de données que vous souhaitez conserver les lignes dans l'ordre de l'index dans la table. Toutefois, il est généralement (en fonction de votre implémentation) uniquement valable sur des données raisonnablement statiques, car c'est la seule façon dont la base de données s'assurera que les lignes de la table sont bien dans l'ordre, en reconstruisant la table.

Answer 4

Quelle base de données?

1)
Une table sans index est appelée tas. Un tas stockera les enregistrements dans l'ordre dans lequel ils ont été insérés. Tant que vous n'insérez pas à partir de plusieurs threads, vous serez en mesure de prédire l'ordre dans lequel la base de données stocke les enregistrements. Comme d'autres l'ont fait remarquer, cela présume que vous ne supprimez pas dans quel cas votre SGBD peut remplir les pages vides avec de nouvelles lignes.

2)
Sans index, le SGBD doit effectuer une analyse de table complète (qui s'exécute en temps linéaire par rapport au nombre d'enregistrements). Pour les enregistrements dans lesquels vous insérez les enregistrements avec des horodatages croissants, un index clusterisé serait bon. Tant que vous n'insérez pas d'anciens horodatages, le SGBD doit réorganiser physiquement les lignes en raison de l'index clusterisé.

Answer 5

Je suis jbu, le créateur de la publication.

Merci pour l'entrée rapide de tout le monde.

Pour répondre à d'autres questions:

Oui j'ai données statiques - Je ne supprimerons.

Je teste quelques bases de données différentes: Sybase SQL Anywhere, Oracle Berkeley DB, H2, Firebird, SQLite, et peut-être quelques autres.

À Steven Lowe: Ma table aura des millions d'enregistrements (elle atteindra 32 Go au maximum). Si je désactive l'indexation pendant un certain temps, puis recréer l'index, cela ne prendra-t-il pas beaucoup de temps - au moins quelques minutes (je suppose que cela pourrait prendre beaucoup plus de temps)? Aussi, je pense que vous supposez qu'il y aura une rupture dans le flux continu d'insertions. Je vais presque constamment insérer en utilisant des commits d'insertion de lots, donc je ne pense pas que mon CPU et mon disque auront vraiment une pause pour faire une réindexation.

Encore une fois, merci pour la contribution des gars.

JBU

Answer 6

Il est typique, mais il est pas garanti par une mise en œuvre spécifique, autant que je sache. Pour cette raison, il ne serait pas sage d'en dépendre. L'optimiseur de requête n'en dépend pas non plus, il effectuera donc une analyse de table.

Un index clusterisé sur l'horodatage dans votre cas n'a aucun inconvénient. Vous pourriez remplir 100% de vos pages de données, et vous ne seriez pas encore pire qu'un tas. Les requêtes, cependant, pourraient en profiter et seraient n'importe où de façon marginale (si vous revenez, par exemple, 90% de la table) à ridicule (si vous revenez, par exemple, 1% de la table) plus rapidement .

Answer 7

Je crois que selon la norme SQL, vous ne pouvez jamais être sûr de l'ordre de sélection des lignes dans une colonne non ordonnée. Même si vous testez une base de données donnée et la trouvez actuellement vraie, cela peut ne pas être le cas avec la prochaine révision de la base de données. Mon expérience est celle de Steven Lowe. Si vous insérez un grand nombre de lignes dans une table, désactivez (ou supprimez) les lignes avant l'insertion. Recréer les indices après l'insertion prendra moins de temps que les insertions avec les index.

Alan

Answer 8

Vous devez créer un index sur la colonne d'horodatage pour pouvoir rechercher mon horodatage. Juste le faire (TM).

Un index clusterisé ne vous aide que si vous effectuez une recherche par clé primaire. Vous pourriez faire de l'horodatage la clé primaire pour en profiter.

Answer 9

Un index clusterisé est l'ordre dans lequel les enregistrements existent sur le disque. Il y en aura toujours un, que vous spécifiiez ou non, car il doit y avoir un ordre sur le disque.

Il est normal que la clé primaire soit également l'index clusterisé, mais ce n'est pas forcément le cas.

Si vous effectuez des insertions par lots, il est probable que plusieurs enregistrements soient insérés avec le même horodatage. Évidemment, cela ne peut pas être une clé primaire. Pour faire une requête comme "SELECT .. WHERE timestamp> X", un index sur le champ 'timestamp' améliorera les performances de cette requête, qu'elle soit en cluster ou non.

Si l'index sur le champ 'horodatage' doit être mis en cluster et si vous aurez également besoin d'autres index dépendra de toutes les requêtes que vous devrez effectuer sur les données.