hyrise
1.0.0
Hyrise ist ein Forschungs-In-Memory-Datenbanksystem, das seit 2009 vom HPI entwickelt und 2017 komplett neu geschrieben wurde. Unser Ziel ist es, eine saubere und flexible Plattform für die Forschung im Bereich In-Memory-Datenmanagement bereitzustellen. Seine Architektur ermöglicht es uns, unseren Studierenden und anderen Forschern, Experimente rund um neue Datenmanagementkonzepte durchzuführen. Um realistische Experimente zu ermöglichen, bietet Hyrise umfassende SQL-Unterstützung und führt leistungsstarke Abfrageplanoptimierungen durch. Bekannte Benchmarks wie TPC-H oder TPC-DS können mit einem einzigen Befehl und ohne Vorbereitung ausgeführt werden.
Diese Readme-Datei konzentriert sich auf die technischen Aspekte des Repositorys. Weitere Hintergrundinformationen zu unserer Forschung und eine Liste der Veröffentlichungen finden Sie auf der Hyrise-Projektseite.
Die (archivierte) Vorgängerversion von Hyrise finden Sie weiterhin auf Github.
Wenn Sie auf diese Version von Hyrise verweisen, verwenden Sie bitte den folgenden Bibtex-Eintrag:
@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 ist für Linux (vorzugsweise die aktuellste Ubuntu-Version) entwickelt und für die Ausführung auf Server-Hardware optimiert. Wir unterstützen Mac, um die lokale Entwicklung von Hyrise zu erleichtern, empfehlen es jedoch nicht für Benchmarking.
Wir unterstützen eine Reihe standardmäßiger Benchmarks. Dies macht es einfach, Leistungszahlen zu generieren, ohne die Datengenerierung einrichten, CSVs laden und einen Abfrage-Runner suchen zu müssen. Sie können sie mit den ./hyriseBenchmark* ausführen.
Beachten Sie, dass die Abfragepläne in unserer CI-Pipeline möglicherweise mit vielen parallelen Phasen generiert werden und verschiedene CI-Läufe möglicherweise auf verschiedenen Computern ausgeführt werden. Die gemeldeten Laufzeiten sind nicht als solide Benchmark-Leistungszahlen zu verstehen.
| Benchmark | Notizen |
|---|---|
| TPC-DS | Abfragepläne |
| TPC-H | Abfragepläne |
| Der Bestellung beitreten | Abfragepläne |
| Sternenschema | Abfragepläne |
| JCC-H | Rufen Sie die hyriseBenchmarkTPCH-Binärdatei mit dem Flag -j auf. |
| TPC-C | In der Entwicklung wurde noch keine richtige Optimierung durchgeführt |
Schauen Sie sich unsere Richtlinien für Mitwirkende an .
Definitionen der meisten im Code verwendeten Begriffe und Abkürzungen finden Sie im Glossar. Wenn Sie etwas, das Sie suchen, nicht finden können, können Sie gerne ein Problem eröffnen.
Die Schritt-für-Schritt-Anleitung ist ein guter Ausgangspunkt, um Hyrise kennenzulernen.
Sie können die Abhängigkeiten selbst installieren oder das Skript install_dependencies.sh ( empfohlen ) verwenden, das alle darin aufgeführten Abhängigkeiten und Submodule installiert. Das Installationsskript wurde unter macOS Monterey (12.4) und Ubuntu 22.04 getestet.
Unter Abhängigkeiten finden Sie eine detaillierte Liste der Abhängigkeiten, die je nach Plattform mit brew install oder apt-get install verwendet werden können. Als Compiler verwenden wir im Allgemeinen aktuelle Versionen von clang und gcc (nur Linux). Bitte stellen Sie sicher, dass der System-Compiler auf die aktuellste Version zeigt oder verwenden Sie cmake (siehe unten) entsprechend. Ältere Versionen funktionieren möglicherweise, werden jedoch weder getestet noch unterstützt.
Sie können Hyrise mit Nix erstellen. Installieren Sie dazu zunächst Nix auf Ihrem aktuellen Betriebssystem. Führen Sie anschließend den folgenden Befehl im Stammverzeichnis des Repositorys aus:
nix-shell resources/nix --pure Dadurch gelangen Sie in eine Shell, in der alle Abhängigkeiten installiert sind. Sie können Hyrise jetzt wie gewohnt bauen. Bitte beachten Sie, dass die Verwendung des Flags --pure empfohlen wird, da dadurch Abhängigkeiten vom lokalen System vermieden werden.
Weitere Informationen zu Nix finden Sie unter Nix-Pakete.
Wenn Sie mit CLion eine Docker-basierte Entwicklungsumgebung erstellen möchten, lesen Sie unser spezielles Tutorial.
Andernfalls führen Sie Folgendes aus, um alle Abhängigkeiten von Hyrise in ein Docker-Image zu übertragen
docker build -t hyrise .
Sie können den Container über starten
docker run -it hyrise
Im Container können Sie dann Hyrise auschecken und ./install_dependencies.sh ausführen, um die erforderlichen Submodule herunterzuladen.
Es wird dringend empfohlen, Out-of-Source-Builds durchzuführen, also ein separates Verzeichnis für den Build zu erstellen. Empfehlenswerte Namen für dieses Verzeichnis wären je nach Build-Typ cmake-build-{debug,release} . Rufen Sie in diesem Verzeichnis cmake .. auf, um den Build zu konfigurieren. Standardmäßig verwenden wir sehr strenge Compiler-Flags (über -Wextra hinaus, einschließlich -Werror ). Wenn Sie eine der offiziell unterstützten Umgebungen verwenden, sollte dies kein Problem darstellen. Wenn Sie Hyrise einfach auf einem anderen System testen möchten und auf Probleme stoßen, können Sie cmake -DHYRISE_RELAXED_BUILD=On .. aufrufen, wodurch diese strengen Prüfungen deaktiviert werden. Nachfolgende Aufrufe von CMake, z. B. wenn dem Build Dateien hinzugefügt werden, sind nicht erforderlich, die generierten Makefiles kümmern sich darum.
CMake verwendet standardmäßig den Standard-Compiler Ihres Systems. Um ein anderes zu verwenden, rufen Sie cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. in einem sauberen Build-Verzeichnis auf. Siehe Abhängigkeiten für unterstützte Compilerversionen.
Ab cmake 3.16 können Sie -DCMAKE_UNITY_BUILD=On verwenden, um Unity-Builds durchzuführen. Bei einem kompletten (Neu-)Build oder wenn mehrere Dateien neu erstellt werden müssen, sind diese in der Regel schneller, da die relativen Kosten für das Starten eines Compiler-Prozesses und das Laden der gängigsten Header reduziert werden. Dies ist jedoch nur für Debug-Builds sinnvoll. Weitere Informationen finden Sie in unserem Blogbeitrag zur Reduzierung der Kompilierungszeit.
Für die Entwicklung möchten Sie möglicherweise Ccache verwenden, was die für Neukompilierungen erforderliche Zeit erheblich verkürzt. Insbesondere beim Wechseln von Zweigen kann dies die Zeit für die Neukompilierung von mehreren Minuten auf eine oder weniger reduzieren. Der Nachteil ist, dass wir auf unserem CI-Server zufällige Build-Fehler festgestellt haben, weshalb wir ccache nicht mehr empfehlen, sondern lediglich als Option auflisten. Um ccache zu verwenden, fügen Sie -DCMAKE_CXX_COMPILER_LAUNCHER=ccache zu Ihrem cmake-Aufruf hinzu. Sie müssen einige Ccache-Einstellungen entweder in Ihren Umgebungsvariablen oder in Ihrer Ccache-Konfiguration anpassen, damit Ccache die vorkompilierten Header verarbeiten kann. Auf unserem CI-Server hat das bei uns funktioniert: CCACHE_SLOPPINESS=file_macro,pch_defines,time_macros CCACHE_DEPEND=1 .
Rufen Sie einfach make -j* auf, wobei * die Anzahl der zu verwendenden Threads angibt.
Normalerweise werden Debug-Binärdateien erstellt. Um ein Build-Verzeichnis für einen Release-Build zu konfigurieren, stellen Sie sicher, dass es leer ist, und rufen Sie CMake wie cmake -DCMAKE_BUILD_TYPE=Release
./scripts/lint.sh (Googles cpplint wird für den Datenbankcode verwendet. Darüber hinaus verwenden wir flake8 zum Linting der Python-Skripte unter /scripts.)
./scripts/format.sh (Clang-Format wird für den Datenbankcode verwendet. Wir verwenden Schwarz für die Formatierung der Python-Skripte unter /scripts.)
Durch den Aufruf make hyriseTest aus dem Build-Verzeichnis werden alle verfügbaren Tests erstellt. Die Binärdatei kann mit ./<YourBuildDirectory>/hyriseTest ausgeführt werden. Teilmengen aller verfügbaren Tests können über --gtest_filter= ausgewählt werden.
./scripts/coverage.sh gibt eine Zusammenfassung in der Befehlszeile aus und erstellt detaillierte HTML-Berichte unter ./coverage/index.html
Erfordert Clang auf macOS und Linux.
cmake -DENABLE_ADDR_UB_LEAK_SANITIZATION=ON generiert Makefiles mit den Optionen AddressSanitizer, LeakSanitizer und Undefiniertes Verhalten. Kompilieren Sie sie wie gewohnt und führen Sie sie aus. Wenn Probleme erkannt werden, werden diese auf der Konsole ausgegeben. Beim ersten erkannten Fehler schlägt der Vorgang fehl und es wird eine Zusammenfassung gedruckt. Um Adressen in tatsächliche Quellcode-Speicherorte umzuwandeln, stellen Sie sicher, dass llvm-symbolizer installiert ist (im llvm-Paket enthalten) und in $PATH verfügbar ist. Um einen benutzerdefinierten Speicherort für den Symbolisierer anzugeben, legen Sie $ASAN_SYMBOLIZER_PATH auf den Pfad der ausführbaren Datei fest. Dies scheint unter macOS sofort zu funktionieren. Wenn nicht, stellen Sie sicher, dass llvm installiert ist. Die Binärdatei kann mit LSAN_OPTIONS=suppressions=asan-ignore.txt ./<YourBuildDirectory>/hyriseTest ausgeführt werden.
cmake -DENABLE_THREAD_SANITIZATION=ON funktioniert wie oben, jedoch mit dem ThreadSanitizer. Einige Desinfektionsmittel schließen sich gegenseitig aus, weshalb wir hierfür zwei Konfigurationen verwenden.
Wenn Sie versuchen, den Zeitaufwand für die Erstellung des Projekts zu optimieren, ist es oft hilfreich, eine Vorstellung davon zu haben, wie viel Zeit wo verbracht wird. scripts/compile_time.sh hilft dabei. Erhalten Sie Nutzungsanweisungen, indem Sie es ohne Argumente ausführen.
Kontakt: [email protected]
