hyrise
1.0.0
Hyrise est un système de base de données de recherche en mémoire développé par HPI depuis 2009 et entièrement réécrit en 2017. Notre objectif est de fournir une plate-forme propre et flexible pour la recherche dans le domaine de la gestion des données en mémoire. Son architecture nous permet, à nous, à nos étudiants et à d'autres chercheurs, de mener des expérimentations autour de nouveaux concepts de gestion de données. Pour permettre des expériences réalistes, Hyrise propose une prise en charge complète de SQL et effectue de puissantes optimisations de plan de requête. Des benchmarks bien connus, tels que TPC-H ou TPC-DS, peuvent être exécutés avec une seule commande et sans aucune préparation.
Ce fichier Lisez-moi se concentre sur les aspects techniques du référentiel. Pour plus d’informations sur nos recherches et pour une liste de publications, veuillez visiter la page du projet Hyrise.
Vous pouvez toujours retrouver la version précédente (archivée) d'Hyrise sur Github.
Lorsque vous faites référence à cette version d'Hyrise, veuillez utiliser l'entrée bibtex suivante :
@inproceedings { DBLP:conf/edbt/DreselerK0KUP19 ,
author = { Markus Dreseler and
Jan Kossmann and
Martin Boissier and
Stefan Klauck and
Matthias Uflacker and
Hasso Plattner } ,
editor = { Melanie Herschel and
Helena Galhardas and
Berthold Reinwald and
Irini Fundulaki and
Carsten Binnig and
Zoi Kaoudi } ,
title = { Hyrise Re-engineered: An Extensible Database System for Research in
Relational In-Memory Data Management } ,
booktitle = { Advances in Database Technology - 22nd International Conference on
Extending Database Technology, {EDBT} 2019, Lisbon, Portugal, March
26-29, 2019 } ,
pages = { 313--324 } ,
publisher = { OpenProceedings.org } ,
year = { 2019 } ,
url = { https://doi.org/10.5441/002/edbt.2019.28 } ,
doi = { 10.5441/002/edbt.2019.28 } ,
timestamp = { Mon, 18 Mar 2019 16:09:00 +0100 } ,
biburl = { https://dblp.org/rec/conf/edbt/DreselerK0KUP19.bib } ,
bibsource = { dblp computer science bibliography, https://dblp.org }
}Hyrise est développé pour Linux (de préférence la version la plus récente d'Ubuntu) et optimisé pour fonctionner sur du matériel serveur. Nous prenons en charge Mac pour faciliter le développement local d'Hyrise, mais ne le recommandons pas pour l'analyse comparative.
Nous prenons en charge un certain nombre de benchmarks prêts à l'emploi. Cela facilite la génération de chiffres de performances sans avoir à configurer la génération de données, à charger des CSV et à trouver un exécuteur de requêtes. Vous pouvez les exécuter à l'aide des binaires ./hyriseBenchmark* .
Notez que les plans de requête sont générés dans notre pipeline CI avec éventuellement de nombreuses étapes en parallèle et que différentes exécutions CI peuvent être exécutées sur différentes machines. Les durées d'exécution indiquées ne doivent pas être considérées comme des chiffres de performances de référence solides.
| Référence | Remarques |
|---|---|
| TPC-DS | Plans de requête |
| TPC-H | Plans de requête |
| Rejoindre la commande | Plans de requête |
| Schéma en étoile | Plans de requête |
| JCC-H | Appelez le binaire hyriseBenchmarkTPCH avec l'indicateur -j. |
| TPC-C | En développement, aucune optimisation appropriée n'a encore été effectuée |
Jetez un œil à nos directives pour les contributeurs .
Vous pouvez trouver les définitions de la plupart des termes et abréviations utilisés dans le code dans le glossaire. Si vous ne trouvez pas quelque chose que vous recherchez, n'hésitez pas à ouvrir un ticket.
Le guide étape par étape est un bon point de départ pour découvrir Hyrise.
Vous pouvez installer les dépendances vous-même ou utiliser le script install_dependencies.sh ( recommandé ) qui installe toutes les dépendances et sous-modules répertoriés. Le script d'installation a été testé sous macOS Monterey (12.4) et Ubuntu 22.04.
Voir dépendances pour une liste détaillée des dépendances à utiliser avec brew install ou apt-get install , en fonction de votre plateforme. En tant que compilateurs, nous utilisons généralement des versions récentes de clang et gcc (Linux uniquement). Veuillez vous assurer que le compilateur système pointe vers la version la plus récente ou utilisez cmake (voir ci-dessous) en conséquence. Les anciennes versions peuvent fonctionner, mais ne sont ni testées ni prises en charge.
Vous pouvez construire Hyrise en utilisant Nix. Pour ce faire, installez d’abord Nix sur votre système d’exploitation actuel. Ensuite, exécutez la commande suivante à la racine du référentiel :
nix-shell resources/nix --pure Cela vous déposera dans un shell avec toutes les dépendances installées. Vous pouvez désormais construire Hyrise comme d'habitude. Veuillez noter que l'utilisation de l'indicateur --pure est recommandée car elle évite d'utiliser des dépendances du système local.
Pour plus d’informations sur Nix, consultez Packages Nix.
Si vous souhaitez créer un environnement de développement basé sur Docker à l'aide de CLion, rendez-vous sur notre tutoriel dédié.
Sinon, pour intégrer toutes les dépendances d'Hyrise dans une image Docker, exécutez
docker build -t hyrise .
Vous pouvez démarrer le conteneur via
docker run -it hyrise
À l'intérieur du conteneur, vous pouvez ensuite extraire Hyrise et exécuter ./install_dependencies.sh pour télécharger les sous-modules requis.
Il est fortement recommandé d'effectuer des builds hors source, c'est-à-dire de créer un répertoire séparé pour le build. Les noms conseillés pour ce répertoire seraient cmake-build-{debug,release} , selon le type de build. Dans ce répertoire, appelez cmake .. pour configurer la build. Par défaut, nous utilisons des indicateurs de compilateur très stricts (au-delà de -Wextra , y compris -Werror ). Si vous utilisez l’un des environnements officiellement pris en charge, cela ne devrait pas poser de problème. Si vous souhaitez simplement tester Hyrise sur un autre système et rencontrer des problèmes, vous pouvez appeler cmake -DHYRISE_RELAXED_BUILD=On .. , ce qui désactivera ces vérifications strictes. Les appels ultérieurs à CMake, par exemple, lorsque l'ajout de fichiers à la construction ne sera pas nécessaire, les Makefiles générés s'en chargeront.
CMake utilisera par défaut le compilateur par défaut de votre système. Pour en utiliser un autre, appelez cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. dans un répertoire de construction propre. Voir les dépendances pour les versions du compilateur prises en charge.
À partir de cmake 3.16, vous pouvez utiliser -DCMAKE_UNITY_BUILD=On pour effectuer des builds unitaires. Pour une (re)construction complète ou lorsque plusieurs fichiers doivent être reconstruits, celles-ci sont généralement plus rapides, car le coût relatif de démarrage d'un processus de compilateur et de chargement des en-têtes les plus courants est réduit. Cependant, cela n’a de sens que pour les versions de débogage. Consultez notre article de blog sur la réduction du temps de compilation pour plus de détails.
Pour le développement, vous souhaiterez peut-être utiliser ccache, ce qui réduit considérablement le temps nécessaire aux recompilations. Surtout lors du changement de branche, cela peut réduire le temps de recompilation de plusieurs minutes à une ou moins. En revanche, nous avons constaté des échecs de build aléatoires sur notre serveur CI, c'est pourquoi nous ne recommandons plus ccache mais le listons simplement comme une option. Pour utiliser ccache, ajoutez -DCMAKE_CXX_COMPILER_LAUNCHER=ccache à votre appel cmake. Vous devrez ajuster certains paramètres de ccache soit dans vos variables d'environnement, soit dans votre configuration de ccache afin que ccache puisse gérer les en-têtes précompilés. Sur notre serveur CI, cela a fonctionné pour nous : CCACHE_SLOPPINESS=file_macro,pch_defines,time_macros CCACHE_DEPEND=1 .
Appelez simplement make -j* , où * indique le nombre de threads à utiliser.
Habituellement, des binaires de débogage sont créés. Pour configurer un répertoire de build pour une version release, assurez-vous qu'il est vide et appelez CMake comme cmake -DCMAKE_BUILD_TYPE=Release
./scripts/lint.sh (le cpplint de Google est utilisé pour le code de la base de données. De plus, nous utilisons flake8 pour le linting des scripts Python sous /scripts.)
./scripts/format.sh (le format clang est utilisé pour le code de la base de données. Nous utilisons le noir pour formater les scripts Python sous /scripts.)
L'appel make hyriseTest depuis le répertoire build crée tous les tests disponibles. Le binaire peut être exécuté avec ./<YourBuildDirectory>/hyriseTest . Des sous-ensembles de tous les tests disponibles peuvent être sélectionnés via --gtest_filter= .
./scripts/coverage.sh imprimera un résumé sur la ligne de commande et créera des rapports HTML détaillés sur ./coverage/index.html
Nécessite un clang sur macOS et Linux.
cmake -DENABLE_ADDR_UB_LEAK_SANITIZATION=ON générera des Makefiles avec les options AddressSanitizer, LeakSanitizer et Undefined Behavior. Compilez-les et exécutez-les normalement : si des problèmes sont détectés, ils seront imprimés sur la console. Il échouera à la première erreur détectée et imprimera un résumé. Pour convertir les adresses en emplacements de code source réels, assurez-vous que llvm-symbolizer est installé (inclus dans le package llvm) et est disponible dans $PATH . Pour spécifier un emplacement personnalisé pour le symboliseur, définissez $ASAN_SYMBOLIZER_PATH sur le chemin de l'exécutable. Cela semble fonctionner immédiatement sur macOS - sinon, assurez-vous que llvm est installé. Le binaire peut être exécuté avec LSAN_OPTIONS=suppressions=asan-ignore.txt ./<YourBuildDirectory>/hyriseTest .
cmake -DENABLE_THREAD_SANITIZATION=ON fonctionnera comme ci-dessus mais avec ThreadSanitizer. Certains désinfectants s’excluent mutuellement, c’est pourquoi nous utilisons deux configurations pour cela.
Lorsqu’on essaie d’optimiser le temps passé à construire le projet, il est souvent utile d’avoir une idée du temps passé et de l’endroit où il est consacré. scripts/compile_time.sh aide à cela. Obtenez des instructions d'utilisation en l'exécutant sans aucun argument.
Contact : pré[email protected]
