Code source pour la soumission d'articles à l'ICDE 2023 : « Indexation des données presque triées »
Le référentiel contient le code source des implémentations B+tree et SWARE. Dans la version actuelle du code, les deux implémentations sont génériques, mais les fichiers d'application qui testent ces structures de données d'index ne prennent en charge que le type de données entier. De plus, les fichiers d'application utilisent la même valeur pour la clé et la valeur de chaque entrée. Les futures extensions du code prendront en charge des types de données plus volumineux.
Les deux structures de données nécessitent une allocation de pool de mémoire tampon lors de l'exécution du code, qui peut être étendue jusqu'à la quantité requise si nécessaire pour s'exécuter entièrement en mémoire. L'allocation du pool de mémoire tampon est donnée en termes de nombre de blocs, chaque bloc faisant 4 Ko. Par exemple, si vous utilisez une allocation de 1 M de blocs, vous allouez 1 M*4 Ko = 4 Go de mémoire pour la structure de données arborescente.
L'arbre SA B+ nécessite également le nombre d'entrées que son tampon en mémoire peut contenir lors de l'exécution du programme, ainsi que le facteur de remplissage à maintenir lors du chargement en masse. Chaque entrée est une paire clé-valeur.
Utilisez le générateur de données de tri de ce dépôt : https://github.com/BU-DiSC/bods pour générer des clés d'ingestion (vous pouvez spécifier la taille de la charge utile = 0 pour générer uniquement des clés). Comme mentionné ci-dessus, les fichiers d'application utilisent la même valeur pour la clé et la valeur de chaque entrée (paire K, V). Notez le chemin d'accès à la charge de travail générée.
./ test_base_index < ingestion_workload_path > < output_file_name > < buffer_pool_allocation > < K > < L > < #. queries >
Par exemple, vous utiliseriez :
./ test_base_index createdata_1000000 - elems_100000 - K_100000 - L_1seed1632764083 . dat sample . txt 1000000 100000 100000 200000
Ici, nous ingérons une charge de travail de 1 million d'entrées/clés avec K=L=100 000. Nous utilisons un cache de pool de tampons pour 1 million de blocs et exécutons des requêtes de 200 000 points. Les latences de sortie pour les requêtes d'ingestion et de points sont écrites dans « sample.txt ».
./ test_satree < ingestion_workload_path > < output_file_name > < buffer_pool_allocation > < K > < L > < #. entries > < swareBuffer allocation > < fill factor % > < #. queries >
Par exemple, vous utiliseriez :
/ test_satree createdata_1000000 - elems_10 - K_10 - L_1seed1632764083 . dat swaresample . txt 1000000 10 10 1000000 10000 95 200000
Ici, nous ingérons une charge de travail de 1 million d'entrées/clés avec K=L=100 000 (10 % du total des entrées). Nous utilisons un cache de pool de tampons pour 1 million de blocs et exécutons des requêtes de 200 000 points. Les latences de sortie pour les requêtes d'ingestion et de point sont écrites dans « swaresample.txt ». Le tampon en mémoire contiendra 10 000 entrées (1 % de 1 M) et nous maintenons un facteur de remplissage de 95 %.