إطلاق المفترس - مستودعات البيانات المترجمة مسبقا

اليوم ، قام فريق Micronaut في Object Computing Inc (OCI) بتقديم Predator ، وهو مشروع جديد مفتوح المصدر يهدف إلى تحسين وقت التشغيل والأداء (من الذاكرة) بشكل كبير للوصول إلى البيانات لخدمات ميكروكريلس والتطبيقات دون خادم ، دون فقدان الإنتاجية مقارنة بأدوات مثل GORM و Spring Data.

تاريخ أدوات الوصول إلى البيانات

يمكننا تتبع تاريخ قالب مستودع البيانات منذ عام 2004 ، عندما تم طرح Ruby on Rails مع النظام الفرعي ActiveRecord ، وهو API الذي أحدث ثورة في فهمنا للوصول إلى البيانات من حيث إنتاجية المطورين.

في عام 2007 ، قدم فريق Grails لأول مرة واجهة برمجة تطبيقات تشبه ActiveRecord لـ JVM - GORM (جزء من Grails). اعتمد GORM على الطبيعة الديناميكية لـ Groovy لتطبيق طرق البحث أعلى Hibernate وقدم نفس مزايا الإنتاجية لمستخدمي JVM.

نظرًا لأن GORM يعتمد على لغة Groovy ، تم إنشاء مشروع Spring Data في عام 2011 ، والذي سمح لمطوري Java بتعريف أساليب البحث ، مثل findByTitle ، في الواجهة ، وتنفيذ منطق الاستعلامات تلقائيًا في وقت التشغيل.

كيف تعمل أدوات الوصول إلى البيانات

تستخدم جميع التطبيقات المذكورة نفس القالب ، وهو بناء نموذج من كيانات المشروع في وقت التشغيل يقوم بنمذجة العلاقات بين فئات الكيانات الخاصة بك. في بيانات الربيع ، يكون MappingContext ، وفي GORM يطلق عليه أيضًا MappingContext. يتم بناؤها عن طريق مسح الطبقات باستخدام التفكير. (التشابه في التسمية ليس عرضيًا هنا. في عام 2010 ، عملت مع فريق Spring Data لمحاولة إعادة إنشاء GORM لـ Java ، في مشروع تحول في النهاية إلى ما يسمى Spring Data اليوم)

ثم يتم استخدام هذا metamodel لتحويل تعبير بحث ، مثل bookRepository.findByTitle("The Stand") ، إلى نموذج استعلام مجردة في وقت التشغيل باستخدام مزيج من تحليل التعبير المنطقي والمنطق الإطاري. نحتاج إلى نموذج استعلام تجريدي لأن لهجة الهدف من الاستعلام مختلفة لكل قاعدة بيانات (SQL ، JPA-QL ، Cypher ، Bson ، إلخ)

دعم المستودع الدقيق

منذ إطلاق Micronaut منذ أكثر من عام بقليل ، كانت الميزة المفقودة الرئيسية التي سئلنا عنها هي "GORM for Java" أو Spring Data support. يعشق الكثير من المطورين الإنتاجية التي توفرها هذه الأدوات ، فضلاً عن سهولة تحديد الواجهات التي ينفذها الإطار. أود أن أقول أن معظم نجاح Grails و Spring Boot يمكن أن يعزى إلى GORM و Spring Data على التوالي.

لمستخدمي Micronaut الذين يستخدمون Groovy ، حصلنا على دعم GORM منذ اليوم الأول ، ولم يتبق لمستخدمي Java و Kotlin أي شيء ، لأنهم يحتاجون إلى تنفيذ مستودعات خاصة بهم.

سيكون من الممكن تقنيًا ، وبصراحة أسهل ، إضافة وحدة نمطية ل Micronaut من شأنها تهيئة بيانات الربيع. ومع ذلك ، باتباع هذا المسار ، سنوفر نظامًا فرعيًا مطبقًا باستخدام جميع الطرق التي حاول Micronaut تجنبها: الاستخدام الواسع النطاق للوكيل ، والتأمل ، واستهلاك الذاكرة العالي.

تقديم بريداتور!

يستخدم Predator ، وهو اختصار لمستودعات البيانات Precomputed ، واجهة برمجة تطبيقات Micronaut لتجميعها قبل التنفيذ (AoT ، مقدمًا) لنقل نموذج تعريف للكيانات وتحويل تعبيرات البحث (مثل findByTitle ) إلى SQL أو JPA-QL المناسب إلى برنامج التحويل البرمجي المناسب . نتيجة لذلك ، ينفّذ الاستعلام طبقة وقت تشغيل رقيقة جدًا للبرنامج دون انعكاس ، ويبقى له فقط تشغيل الاستعلام وإرجاع النتائج.

كانت النتيجة ساحقة ... تم تقليل البداية الباردة بدرجة كبيرة ، حيث حصلنا على انخفاض في استهلاك الذاكرة بشكل مثير للدهشة وتحسين كبير في الأداء.

نفتح اليوم الكود المصدري لـ Predator بموجب ترخيص Apache 2 ، وسوف يأتي مع تطبيقين أوليين (المزيد من الميزات المخططة للمستقبل) لـ JPA (بناءً على Hibernate) و SQL مع JDBC.

إن تطبيق JDBC يسعدني أكثر ، لأنه مستقل تمامًا عن الانعكاس ، لا يستخدم الوكلاء والتحميل الديناميكي للفئة لمستوى وصولك إلى البيانات ، مما يؤدي إلى تحسين الأداء. طبقة وقت التشغيل خفيفة للغاية حتى أن كود مستودع التخزين المكافئ المكتوب بخط اليد لن يتم تنفيذه بشكل أسرع.

الأداء المفترس

نظرًا لأن Predator لا يحتاج إلى تنفيذ أي تحويلات للاستعلام في وقت التشغيل ، فإن كسب الأداء مهم. في عالم استخدام الحوسبة السحابية ، حيث تدفع مقابل الوقت الذي يتم فيه تشغيل التطبيق الخاص بك أو لتنفيذ وظيفة واحدة ، غالبًا ما يغفل المطورون عن أداء آليات الوصول إلى البيانات الخاصة بهم.

يلخص الجدول التالي اختلافات الأداء التي يمكن توقعها لتعبير بحث بسيط ، مثل findByTitle ، مقارنة بالتطبيقات الأخرى. تم إجراء جميع الاختبارات باستخدام مقعد اختبار على Xeon iMac Pro ذي 8 نواة تحت نفس الظروف ، الاختبارات مفتوحة ويمكن العثور عليها في المستودع :

نعم ، لقد قرأت ذلك بشكل صحيح. مع Predator JDBC ، يمكنك توقع زيادة في الأداء تقريبًا 4X مقارنة بـ GORM و 2.5 X على بيانات Spring.

وحتى إذا كنت تستخدم Predator JPA ، يمكنك الاعتماد على أكثر من 2 تحسينات في الأداء مقارنة بـ GORM وزيادة تصل إلى 40 ٪ مقارنةً بـ Spring Data JPA.

انظر إلى الفرق في حجم مكدس التنفيذ عند استخدام Predator مقارنة بالبدائل:

المفترس:

المفترس JPA:

بيانات الربيع:

GORM:

يستخدم Predator JDBC 15 إطارًا فقط حتى يتم تنفيذ طلبك ، بينما يستخدم Predator JPA 30 (أساسًا بسبب Hibernate) ، مقارنةً بـ50+ إطارات مكدس في Spring Data أو GORM. وكل ذلك بفضل آليات Micronaut AOP التي لا تستخدم التفكير.

مكدس أقصر أيضاً تبسيط تصحيح التطبيق. تتمثل إحدى مزايا القيام بمعظم العمل أثناء التحويل البرمجي في أنه يمكن اكتشاف الأخطاء قبل بدء تشغيل التطبيق ، مما يحسن بشكل كبير من تجربة المطور. نحصل على أخطاء تجميع فورًا بدلاً من أخطاء وقت التشغيل للأخطاء الأكثر شيوعًا.

ترجمة الشيكات الوقت

تعتمد معظم تطبيقات قالب المستودع فقط على تنفيذ جميع العمليات في وقت التشغيل. هذا يعني أنه إذا أخطأ المطور في تعريف واجهة المستودع ، فلن تكون الأخطاء مرئية حتى يتم تشغيل التطبيق فعليًا.

هذا يحرمنا من بعض فوائد Java للتحقق من النوع ولدينا تجربة بيانات سيئة. هذا ليس هو الحال مع بريداتور. النظر في المثال التالي:

 @JdbcRepository(dialect = Dialect.H2) public interface BookRepository extends CrudRepository<Book, Long> { Book findByTile(String t); } 

هنا BookRepository أعلنا طلبًا لكائن يسمى Book ، والذي له خاصية ملكية. لسوء الحظ ، يوجد خطأ في هذا الإعلان: لقد قمنا بتسمية طريقة findByTile بدلاً من findByTitle . بدلاً من تشغيل هذا الرمز ، لن تسمح Predator برمجتك للترجمة برسالة خطأ مفيدة:

 Error:(9, 10) java: Unable to implement Repository method: BookRepository.findByTile(String title). Cannot use [Equals] criterion on non-existent property path: tile 

يتم التحقق من العديد من جوانب Predator في وقت الترجمة ، عندما يكون ذلك ممكنًا ، للتأكد من أن خطأ وقت التشغيل لا ينتج عن إعلان مستودع غير صحيح.

المفترس JDBC و GraalVM الركيزة

سبب آخر يجب أن يكون Predator سعيدًا به هو أنه خارج الصندوق متوافق مع صور GraalVM Substrate الأصلية ولا يتطلب تحويلات معقدة لرمز الشفرة أثناء الإنشاء ، على عكس تلك الخاصة بـ Hibernate on GraalVM.

من خلال التخلص تمامًا من الانعكاس والوكلاء الديناميين من طبقة الوصول إلى البيانات ، تعمل Predator على تبسيط عملية إنشاء التطبيقات التي تعمل مع البيانات التي تعمل على GraalVM.

يعمل تطبيق نموذج Predator JDBC على الركيزة دون مشاكل ويسمح لك بإنشاء صورة أصلية أصغر بكثير (أقل من 25 ميجابايت!) يحتاج "الإسبات" إلى العمل ، بفضل طبقة وقت التشغيل الأرق بكثير.

لقد رأينا نفس النتيجة عندما قمنا بتطبيق تجميع قواعد التحقق من صحة Bean لـ Micronaut 1.2. انخفض حجم الصورة الأصلية بمقدار 10 ميغابايت ، بمجرد أن أزلنا التبعية على مدقق السبات ، وحجم JAR بمقدار 2 ميجابايت.

الميزة هنا واضحة: من خلال القيام بمزيد من العمل أثناء الترجمة وإنشاء المزيد من أوقات التشغيل المدمجة ، يمكنك الحصول على صورة أصلية أصغر وملف JAR ، مما يؤدي إلى نشر خدمات micros أصغر وأصغر عند النشر عبر Docker. مستقبل أطر عمل Java أكثر برامج تجميع قوية وأوقات تشغيل أصغر وأخف وزناً.

المفترس والمستقبل

لقد بدأنا للتو العمل مع Predator ونحن سعداء للغاية بالفرص التي يفتحها.

في البداية ، نبدأ بدعم JPA و SQL ، لكن في المستقبل يمكنك توقع دعم MongoDB و Neo4J و Reactive SQL وقواعد البيانات الأخرى. لحسن الحظ ، هذه المهمة أبسط كثيرًا لأن معظم Predator يعتمد فعليًا على الكود المصدري GORM ، ويمكننا إعادة استخدام منطق GORM لـ Neo4J و GORM لـ MongoDB لإصدار هذه التطبيقات بشكل أسرع مما تتوقع.

Predator هو تتويج للجمع بين العديد من لبنات البناء في Micronaut Core التي مكّنت من تنفيذها ، من واجهات برمجة التطبيقات AoT ، والتي تُستخدم أيضًا لإنشاء مستندات Swagger ، إلى دعم Bean Introspection الجديد نسبيًا ، والذي يسمح لك بتحليل الكائنات في وقت التشغيل دون انعكاس.

يوفر Micronaut لبنات بناء لأشياء مذهلة. Predator هو أحد هذه الأشياء ، وقد بدأنا للتو العمل على بعض الميزات الواعدة في Micronaut 1.0.

استكمال: بعد الإعلان المروع ، تمت إعادة تسمية قاتل Spring Data لبيانات Micronaut: https://micronaut-projects.imtqy.com/micronaut-data/1.0.x/guide/