Table consultable - Que feriez-vous?

Question

J'essaye de déterminer comment concevoir au mieux une installation de stockage pour la recherche rapide du texte.

• Il y aura un format de fichier différent pour chaque client
• Ces fichiers sont XML et les noms de champs et les attributs ne sont pas standard, et ne suivent pas un schéma
• Le client a la possibilité de choisir certains champs peuvent être recherchés

• Il peut y avoir 100 000 enregistrements par fichier, par client.

  Je suis en train de traiter ces fichiers et de générer une table basée sur les colonnes spécifiées par la configuration du client.

  Quel type de schéma de base de données choisiriez-vous, qu'il s'agisse de fichiers SQL, de fichiers plats ou de toute autre technologie?

  Il va y avoir beaucoup de lignes à chercher, et je ne sais pas quel est le meilleur moyen d'y parvenir.

Créer une table appelée SearchColumns

Id 
CustomerId 
DisplayValue 

Créer une table appelée "SearchRecords"

Id 
SearchColumnId 
SearchText 

Avec ce scénario, la table SearchRecords va devenir très grand, très rapide, et parce que SearchText va être varchar (200), les requêtes LIKE vont être incroyablement lent.

J'ai également pris en compte la recherche de texte intégral dans la table SearchRecords, mais lors d'un test sur un exemple de table, je n'obtiens pas de résultats comme je l'aurais souhaité. J'ai aussi considéré des bases de données séparées par client Cela aidera à la taille de la table à court terme, mais après des mois ou des années, la taille et la vitesse de la table vont être plus lentes. Que feriez-vous pour créer une table de recherche rapide, qui pourrait potentiellement contenir des millions d'enregistrements?

Edit: Les informations concernant les données que je suis le stockage:

Je tire des valeurs telles que FullName, adresse et numéros de compte à partir du fichier xml. Ces champs sont assez petits et n'atteindraient probablement jamais plus de 200 caractères.

Answer 1

Je ne suis pas sûr de comprendre la question. Avez-vous un schéma de stockage d'enregistrements sélectionné et avez-vous besoin de savoir quel est le meilleur moyen d'y ajouter des éléments ou avez-vous besoin du schéma de stockage? Envisagez-vous d'analyser le code XML dans des colonnes qui sont nText, ou simplement de charger le fichier XML, les balises et tout, dans des colonnes nText?

D'une manière générale, optez pour une table étroite et profonde sur une table large et peu profonde si vous recherchez la performance. Les tables étroites nécessitent généralement moins d'index pour accélérer la recherche sur les colonnes les plus courantes, et ces indices permettent au moteur de fractionner la recherche en fragments pouvant être parallélisés. La plupart des moteurs sont également assez intelligents pour donner la priorité aux conditions de filtre «bon marché» plutôt que «coûteuses»; la clause LIKE, si présente, sera presque certainement exécutée en dernier dans une clause WHERE composée, donc si vous pouvez fournir d'autres informations pour restreindre la recherche, en particulier sur les colonnes indexées, vous pouvez accélérer les performances générales de votre requête.

Vous pouvez considérer (je ne peux pas croire que je vais le recommander) un schéma clé-question-réponse pour les données de l'élément principal (entre les balises d'ouverture et de fermeture de chaque élément). Dans tous les cas où une partie de la définition de schéma est standardisée, une table définie de façon statique classique sera plus facile à utiliser sur pratiquement tous les comptes, mais si vous ne connaissez même pas la structure de vos données autre que XML une telle approche nécessitera une sorte de mappage entre les métadonnées d'un fichier particulier et une table de champs génériques, et dans ce cas, key-question-answer combinera les deux pour de meilleures performances de requête. Quelles que soient les informations dont vous disposez qui identifient de manière unique un enregistrement particulier (et/ou des données sur lesquelles vous devez chercher très rapidement pour rétrécir les ensembles de résultats à peu de frais), la clé est votre clé. répondre. Cela prendra en charge une norme de dénomination de données très flexible. Comme les données sont XML et que les données pertinentes peuvent être stockées en tant qu'attributs d'un élément (partie de la balise d'ouverture), vous pouvez avoir besoin de tables similaires mais plus simples pour les données d'attribut de recherche de vos balises ou normaliser les données attributaires dans la table principale. basé sur un mashup bien connu. Avoir ces lignes très étroites, ligne par colonne, vous permet également de déplacer très facilement des colonnes non-recherchées dans une table "archive"; vous devez probablement conserver les données au cas où vous souhaiteriez lancer une recherche sur une colonne, mais si vous ne faites pas de recherche sur une colonne, vous pouvez la sortir de la table sur laquelle vous effectuez la lourde tâche, ce qui réduire considérablement les temps de requête.

Si vous recherchez des valeurs approximatives d'un champ CLOB, vous n'allez tout simplement pas battre une requête LIKE. Oui, il sera lent sur de très grandes valeurs de texte; la seule façon d'aider à cela est de scinder ce texte d'une manière qui ne causera pas de fausses non-correspondances (où LIKE ne trouvera pas de correspondance à travers les frontières de séparation), et je ne pense pas que vous trouverez un universel méthode de faire cela; vous devez savoir quelque chose sur ce que vous stockez, comme c'est dans les paragraphes et un match ne traversera jamais les limites de paragraphe de toute façon. En fin de compte, je pense que vous constaterez que, quelle que soit la taille des données, la plupart des RDBMS SQL fonctionnent plutôt bien sur n'importe quel schéma intelligent lorsqu'il dispose de suffisamment de puissance de traitement. La recherche sur un index est de nature logarithmique par opposition à linéaire, et donc un bon schéma d'indexation aidera le moteur à réduire considérablement l'espace de recherche.