2017-10-20 31 views
0

Les exigences:algorithme pour diviser les structures de données on pouvait s'y attendre, peu importe l'ordre qu'il est construit

J'ajoute une fonctionnalité à un programme qui construit l'indice Solr de. Le système est multi-thread, de sorte que les entrées de recherche seront créées dans un ordre aléatoire à chaque fois. L'index Solr doit également être divisé en plusieurs fichiers, car si un utilisateur essaie de télécharger un gros fichier, le serveur peut manquer de mémoire.

Le problème:

Afin de maintenir le système fiable et rendre les choses plus faciles dans l'ensemble, les fichiers d'index Solr résultant doivent être les mêmes, peu importe quel ordre ils sont traités dans les indices doivent être équilibrés. à travers les fichiers (ou assez proche de l'équilibre), et ont un nombre maximum d'entrées. Si les fichiers dépassent le nombre maximal d'entrées, ils doivent être divisés. Ces fichiers seront également mis à jour entre les exécutions, de sorte que les entrées seront ajoutées, supprimées et modifiées.

ce qui est nécessaire:

Je suis à la recherche d'un algorithme qui peut être adopté pour ces exigences. Je pense que j'ai besoin d'une sorte de B-tree, mais je ne connais aucune variante de B-tree qui corresponde à cet ensemble particulier d'exigences.

Existe-t-il un algorithme ou une structure de données pouvant répondre à ces besoins?

+0

Que signifie "Les fichiers d'index Solr doivent être identiques"? Voulez-vous dire que quel que soit l'ordre dans lequel ils sont traités, les fichiers doivent être identiques? Ou que le contenu du fichier, une fois lu et traité, doit créer le même résultat? –

+0

Les fichiers d'index Lucene par défaut sont ajoutés uniquement, donc si vous ajoutez des éléments dans un ordre différent, vous obtiendrez des fichiers différents (le docid interne sera également différent). Vous pouvez créer votre propre codec pour sérialiser et désérialiser le contenu vous-même. Pourriez-vous développer sur _why_ vous avez ces exigences? Est-ce que vous construisez vous-même l'index Lucene en dehors de Solr, et comment le construisez-vous? Pouvez-vous créer une structure sur disque et en mémoire, puis sérialiser cette structure en séquence à Lucene? Avoir un arbre binaire dans chaque thread fonctionnerait dans ce cas, puis fusionner cela sur le disque. – MatsLindh

+0

Par "Les fichiers d'index Solr doivent être les mêmes", je veux dire que les fichiers eux-mêmes doivent être identiques. Ces exigences doivent prouver la fiabilité et l'intégrité du programme. Je ne sais pas comment les indices Solr sont créés parce que nous ne sommes pas très loin dans la planification. Cependant, je peux dire que ces fichiers vont être au format JSON. Nous pouvons créer des structures sur disque et en mémoire comme bon nous semble, aussi longtemps que les fichiers résultants sont cohérents. – user489481

Répondre

0

Utilisez un UUID basé sur le contenu. Pour fractionner le fichier, envoyez chaque élément dans un compartiment en fonction de la plage dans laquelle se trouve l'UUID. Quel que soit l'ordre dans lequel vous recevez les éléments, vous pouvez les envoyer de manière fiable à des compartiments de tailles relativement égales. sort le même.

Voir https://wiki.apache.org/solr/UniqueKey pour des conseils plus détaillés, et https://wiki.apache.org/solr/LargeIndexes pour d'autres conseils utiles.