hyrise
1.0.0
Hyrise هو نظام قاعدة بيانات بحثي داخل الذاكرة تم تطويره بواسطة HPI منذ عام 2009 وتمت إعادة كتابته بالكامل في عام 2017. هدفنا هو توفير منصة نظيفة ومرنة للبحث في مجال إدارة البيانات داخل الذاكرة. تسمح هندسته لنا ولطلابنا وللباحثين الآخرين بإجراء تجارب حول مفاهيم جديدة لإدارة البيانات. لتمكين التجارب الواقعية، يتميز Hyrise بدعم SQL شامل ويقوم بإجراء تحسينات قوية لخطة الاستعلام. يمكن تنفيذ المعايير المعروفة، مثل TPC-H أو TPC-DS، بأمر واحد ودون أي تحضير.
يركز هذا الملف التمهيدي على الجوانب الفنية للمستودع. لمزيد من المعلومات الأساسية حول بحثنا وللحصول على قائمة المنشورات، يرجى زيارة صفحة مشروع Hyrise.
لا يزال بإمكانك العثور على الإصدار السابق (المؤرشف) من Hyrise على Github.
عند الرجوع إلى هذا الإصدار من Hyrise، يرجى استخدام إدخال bibtex التالي:
@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 لنظام التشغيل Linux (ويفضل أن يكون الإصدار الأحدث من Ubuntu) وتم تحسينه للتشغيل على أجهزة الخادم. نحن ندعم نظام التشغيل Mac لتسهيل التطوير المحلي لـ Hyrise، لكننا لا نوصي به لقياس الأداء.
نحن ندعم عددًا من المعايير خارج الصندوق. وهذا يجعل من السهل إنشاء أرقام الأداء دون الحاجة إلى إعداد إنشاء البيانات وتحميل ملفات CSV والعثور على مشغل الاستعلام. يمكنك تشغيلها باستخدام الثنائيات ./hyriseBenchmark* .
لاحظ أنه يتم إنشاء خطط الاستعلام في خط أنابيب CI الخاص بنا مع احتمال وجود عدة مراحل بالتوازي وقد يتم تنفيذ عمليات تشغيل CI مختلفة على أجهزة مختلفة. لا ينبغي اعتبار أوقات التشغيل المبلغ عنها كأرقام أداء مرجعية ثابتة.
| المعيار | ملحوظات |
|---|---|
| TPC-DS | خطط الاستعلام |
| TPC-H | خطط الاستعلام |
| الانضمام إلى النظام | خطط الاستعلام |
| مخطط النجمة | خطط الاستعلام |
| JCC-H | قم باستدعاء ثنائي hyriseBenchmarkTPCH باستخدام العلامة -j. |
| TPC-C | في التطوير، لم يتم إجراء التحسين المناسب حتى الآن |
قم بإلقاء نظرة على إرشادات المساهمين لدينا .
يمكنك العثور على تعريفات لمعظم المصطلحات والاختصارات المستخدمة في الكود في المسرد. إذا لم تتمكن من العثور على ما تبحث عنه، فلا تتردد في فتح مشكلة.
يعد الدليل خطوة بخطوة نقطة انطلاق جيدة للتعرف على Hyrise.
يمكنك تثبيت التبعيات بنفسك أو استخدام البرنامج النصي install_dependencies.sh ( موصى به ) الذي يقوم بتثبيت جميع التبعيات والوحدات الفرعية المدرجة فيه. تم اختبار البرنامج النصي للتثبيت ضمن نظامي التشغيل macOS Monterey (12.4) وUbuntu 22.04.
راجع التبعيات للحصول على قائمة تفصيلية بالتبعيات التي يمكنك استخدامها مع brew install أو apt-get install ، اعتمادًا على نظامك الأساسي. كمترجمين، نستخدم بشكل عام الإصدارات الحديثة من clang وgcc (Linux فقط). يرجى التأكد من أن مترجم النظام يشير إلى أحدث إصدار أو يستخدم cmake (انظر أدناه) وفقًا لذلك. قد تعمل الإصدارات الأقدم، ولكن لم يتم اختبارها أو دعمها.
يمكنك بناء Hyrise باستخدام Nix. للقيام بذلك، قم أولاً بتثبيت Nix على نظام التشغيل الحالي لديك. بعد ذلك، قم بتشغيل الأمر التالي في جذر المستودع:
nix-shell resources/nix --pure سيؤدي هذا إلى نقلك إلى الصدفة مع تثبيت جميع التبعيات. يمكنك الآن بناء Hyrise كالمعتاد. يرجى ملاحظة أنه يوصى باستخدام العلامة --pure لأنها تتجنب استخدام التبعيات من النظام المحلي.
لمزيد من المعلومات حول Nix، راجع حزم Nix.
إذا كنت ترغب في إنشاء بيئة تطوير قائمة على Docker باستخدام CLion، فتوجه إلى برنامجنا التعليمي المخصص.
بخلاف ذلك، يمكنك تشغيل كل تبعيات Hyrise في صورة Docker
docker build -t hyrise .
يمكنك بدء الحاوية عبر
docker run -it hyrise
داخل الحاوية، يمكنك بعد ذلك الخروج من Hyrise وتشغيل ./install_dependencies.sh لتنزيل الوحدات الفرعية المطلوبة.
يوصى بشدة بإجراء إنشاءات خارج المصدر، أي إنشاء دليل منفصل للإنشاء. الأسماء الموصى بها لهذا الدليل هي cmake-build-{debug,release} ، اعتمادًا على نوع البنية. ضمن هذا الدليل، قم باستدعاء cmake .. لتكوين البنية. افتراضيًا، نستخدم إشارات مترجم صارمة للغاية (تتجاوز -Wextra ، بما في ذلك -Werror ). إذا كنت تستخدم إحدى البيئات المدعومة رسميًا، فلا ينبغي أن يمثل ذلك مشكلة. إذا كنت تريد ببساطة اختبار Hyrise على نظام مختلف وواجهت مشكلات، فيمكنك الاتصال cmake -DHYRISE_RELAXED_BUILD=On .. ، مما سيؤدي إلى تعطيل عمليات التحقق الصارمة هذه. الاستدعاءات اللاحقة إلى CMake، على سبيل المثال، عندما لا تكون إضافة الملفات إلى البنية ضرورية، فإن ملفات Makefiles التي تم إنشاؤها ستهتم بذلك.
سيتم تعيين CMake افتراضيًا على المترجم الافتراضي لنظامك. لاستخدام واحد مختلف، اتصل بـ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ .. في دليل بناء نظيف. راجع التبعيات لإصدارات المترجم المدعومة.
بدءًا من cmake 3.16، يمكنك استخدام -DCMAKE_UNITY_BUILD=On لتنفيذ عمليات بناء الوحدة. بالنسبة إلى (إعادة) الإنشاء الكامل أو عند الحاجة إلى إعادة إنشاء ملفات متعددة، تكون هذه عادةً أسرع، حيث يتم تقليل التكلفة النسبية لبدء عملية التحويل البرمجي وتحميل الرؤوس الأكثر شيوعًا. ومع ذلك، هذا منطقي فقط لبنيات التصحيح. راجع منشور مدونتنا حول تقليل وقت التجميع للحصول على التفاصيل.
للتطوير، قد ترغب في استخدام ccache، مما يقلل الوقت اللازم لإعادة الترجمة بشكل كبير. خاصة عند تبديل الفروع، يمكن أن يؤدي ذلك إلى تقليل وقت إعادة الترجمة من عدة دقائق إلى دقيقة واحدة أو أقل. على الجانب السلبي، رأينا حالات فشل عشوائية في البناء على خادم CI الخاص بنا، ولهذا السبب لم نعد نوصي باستخدام ccache ولكننا نكتفي بإدراجه كخيار. لاستخدام ccache، أضف -DCMAKE_CXX_COMPILER_LAUNCHER=ccache إلى مكالمة cmake الخاصة بك. ستحتاج إلى ضبط بعض إعدادات ccache إما في متغيرات البيئة لديك أو في تكوين ccache الخاص بك حتى تتمكن ccache من التعامل مع الرؤوس المترجمة مسبقًا. على خادم CI الخاص بنا، نجح هذا الأمر بالنسبة لنا: CCACHE_SLOPPINESS=file_macro,pch_defines,time_macros CCACHE_DEPEND=1 .
ما عليك سوى الاتصال بـ make -j* ، حيث تشير * إلى عدد الخيوط المطلوب استخدامها.
عادةً ما يتم إنشاء ثنائيات التصحيح. لتكوين دليل بناء لبناء إصدار تأكد من أنه فارغ واستدعاء CMake مثل cmake -DCMAKE_BUILD_TYPE=Release
./scripts/lint.sh (يتم استخدام cpplint الخاص بـ Google لرمز قاعدة البيانات. بالإضافة إلى ذلك، نستخدم flake8 لفحص البرامج النصية لـ Python ضمن /scripts.)
./scripts/format.sh (يُستخدم تنسيق clang لرمز قاعدة البيانات. ونستخدم اللون الأسود لتنسيق نصوص Python ضمن /scripts.)
يؤدي استدعاء make hyriseTest من دليل البناء إلى إنشاء جميع الاختبارات المتاحة. يمكن تنفيذ الملف الثنائي باستخدام ./<YourBuildDirectory>/hyriseTest . يمكن تحديد مجموعات فرعية من جميع الاختبارات المتاحة عبر --gtest_filter= .
سيقوم ./scripts/coverage.sh بطباعة ملخص إلى سطر الأوامر وإنشاء تقارير html مفصلة على ./coverage/index.html
يتطلب clang على نظامي التشغيل MacOS وLinux.
cmake -DENABLE_ADDR_UB_LEAK_SANITIZATION=ON سوف يقوم بإنشاء ملفات Makefiles باستخدام خيارات AddressSanitizer وLeakSanitizer وسلوك غير محدد. قم بتجميعها وتشغيلها كالمعتاد - إذا تم اكتشاف أي مشكلات، فستتم طباعتها على وحدة التحكم. سيفشل عند أول خطأ تم اكتشافه وسيقوم بطباعة ملخص. لتحويل العناوين إلى مواقع كود مصدر فعلية، تأكد من تثبيت llvm-symbolizer (المضمن في حزمة llvm) ومتوفر في $PATH . لتحديد موقع مخصص للرمز، قم بتعيين $ASAN_SYMBOLIZER_PATH على مسار الملف القابل للتنفيذ. يبدو أن هذا يعمل خارج الصندوق على نظام التشغيل macOS - إذا لم يكن الأمر كذلك، فتأكد من تثبيت llvm. يمكن تنفيذ الملف الثنائي باستخدام LSAN_OPTIONS=suppressions=asan-ignore.txt ./<YourBuildDirectory>/hyriseTest .
cmake -DENABLE_THREAD_SANITIZATION=ON سوف يعمل على النحو الوارد أعلاه ولكن مع ThreadSanitizer. بعض المطهرات متنافية، ولهذا السبب نستخدم تكوينين لهذا الغرض.
عند محاولة تحسين الوقت الذي تقضيه في بناء المشروع، غالبًا ما يكون من المفيد أن تكون لديك فكرة عن مقدار الوقت الذي تقضيه في بناء المشروع. scripts/compile_time.sh يساعد في ذلك. احصل على تعليمات الاستخدام عن طريق تشغيله بدون أية وسائط.
جهة الاتصال: الاسم الأول@hpi.de
