प्रीडेटर लॉन्च करें - Precompiled Data Repositories

आज, ऑब्जेक्ट कम्प्यूटिंग इंक (OCI) में माइक्रोनॉट टीम ने प्रीडेटर को पेश किया, एक नया ओपन सोर्स प्रोजेक्ट जिसका लक्ष्य उत्पादकता को खोए बिना माइक्रोसॉर्क्स और सर्वर रहित अनुप्रयोगों के लिए डेटा एक्सेस के रनटाइम और प्रदर्शन (मेमोरी से) में काफी सुधार करना है। GORM और स्प्रिंग डेटा जैसे टूल की तुलना में।

डेटा एक्सेस टूल का इतिहास

हम 2004 के बाद से डेटा रिपॉजिटरी टेम्पलेट के इतिहास को ट्रैक कर सकते हैं, जब रूबी ऑन रेल्स ActiveRecord सबसिस्टम, एक एपीआई जो डेवलपर उत्पादकता के मामले में डेटा एक्सेस की हमारी समझ में क्रांतिकारी बदलाव के साथ सामने आया था।

2007 में, ग्रेल्स टीम ने पहली बार JVM - GORM (ग्रेल्स का हिस्सा) के लिए एक ActiveRecord जैसी API पेश की। GORM, ग्रोवी की गतिशील प्रकृति पर निर्भर करता है जो हाइबरनेट के शीर्ष पर खोज विधियों को लागू करता है और JVM उपयोगकर्ताओं को समान उत्पादकता लाभ प्रदान करता है।

चूंकि जीओआरएम ग्रूवी भाषा पर निर्भर करता है, स्प्रिंग डेटा प्रोजेक्ट 2011 में बनाया गया था, जिसने जावा डेवलपर्स को इंटरफ़ेस में findByTitle जैसे खोज तरीकों को परिभाषित करने की अनुमति दी और स्वचालित रूप से रन टाइम पर क्वेरी लॉजिक को लागू किया।

डेटा एक्सेस टूल कैसे काम करते हैं

सभी उल्लिखित कार्यान्वयन एक ही टेम्पलेट का उपयोग करते हैं, जो कि रन एंट्री के समय प्रोजेक्ट संस्थाओं के एक मेटामॉडल का निर्माण करना है जो आपके इकाई वर्गों के बीच संबंधों को मॉडल करता है। स्प्रिंग डेटा में यह एक मैपिंगकोटेक्स्ट है, और जीओआरएम में इसे मैपिंगकोटेक्स्ट भी कहा जाता है। वे प्रतिबिंब का उपयोग करके स्कैनिंग कक्षाओं द्वारा निर्मित होते हैं। (नामकरण में समानता यहां आकस्मिक नहीं है। 2010 में, मैंने स्प्रिंग डेटा टीम के साथ मिलकर जावा के लिए GORM को फिर से बनाने की कोशिश की, एक परियोजना पर जो अंततः आज स्प्रिंग डेटा कहलाती है)

इस मेटामोडेल का उपयोग तब खोज अभिव्यक्ति को बदलने के लिए किया जाता है, जैसे कि bookRepository.findByTitle("The Stand") , नियमित अभिव्यक्ति पार्सिंग और फ्रेमवर्क लॉजिक के संयोजन का उपयोग करके रनटाइम पर एक अमूर्त क्वेरी मॉडल में। हमें एक सार क्वेरी मॉडल की आवश्यकता है क्योंकि क्वेरी की लक्ष्य बोली प्रत्येक डेटाबेस (SQL, JPA-QL, Cypher, Bson, आदि) के लिए अलग है।

माइक्रोनॉट रिपोजिटरी सपोर्ट

एक साल पहले एक छोटे से अंतरिक्ष यात्री को लॉन्च करने के बाद से, हमारे बारे में जो मुख्य अनुपलब्ध विशेषता थी, वह थी "GORM for Java" या स्प्रिंग डेटा सपोर्ट। इतने सारे डेवलपर्स उत्पादकता के साथ प्यार में हैं जो ये उपकरण प्रदान करते हैं, साथ ही साथ उन इंटरफेस को परिभाषित करने में आसानी होती है जो फ्रेमवर्क लागू करता है। मैं कहूंगा कि ग्रेल्स और स्प्रिंग बूट की अधिकांश सफलता का श्रेय क्रमशः GORM और स्प्रिंग डेटा को दिया जा सकता है।

ग्रूवी का उपयोग करने वाले माइक्रोनॉट उपयोगकर्ताओं के लिए, हमारे पास पहले दिन से जीओआरएम समर्थन था, और जावा और कोटलिन उपयोगकर्ताओं को कुछ भी नहीं बचा था, क्योंकि उन्हें अपने दम पर रिपॉजिटरी लागू करने की आवश्यकता थी।

यह तकनीकी रूप से संभव होगा, और स्पष्ट रूप से आसान होगा, बस माइक्रोफ़ोन के लिए एक मॉड्यूल जोड़ना होगा जो स्प्रिंग डेटा को कॉन्फ़िगर करेगा। हालांकि, इस रास्ते के बाद, हम एक सबसिस्टम प्रदान करेंगे जो उन सभी तरीकों का उपयोग करके लागू किया जाएगा, जो कि माइक्रोप्रनट ने बचने की कोशिश की: समीपता, प्रतिबिंब और उच्च स्मृति खपत का व्यापक उपयोग।

पेश है शिकारी!

प्रीडेटर, प्रीकम्प्यूटेड डेटा रिपॉजिटरी के लिए छोटा, निष्पादन से पहले संकलित करने के लिए माइक्रोएप्यूट एपीआई का उपयोग करता है (एओटी, आगे का समय) संस्थाओं के मेटा-मॉडल को स्थानांतरित करने और खोज अभिव्यक्तियों (जैसे findByTitle ) को उपयुक्त एसक्यूएल या जेपीए-क्यूएल में अपने संकलक में बदलने के लिए। । परिणामस्वरूप, क्वेरी प्रतिबिंब के बिना एक बहुत पतली प्रोग्राम रनटाइम परत को निष्पादित करती है, और यह केवल क्वेरी को चलाने और परिणामों को वापस करने के लिए बनी रहती है।

परिणाम भारी है ... ठंड की शुरुआत काफी कम हो गई है, हमें आश्चर्यजनक रूप से कम मेमोरी खपत और प्रदर्शन में तेज सुधार मिला है।

आज हम Apache 2 लाइसेंस के तहत शिकारी के लिए स्रोत कोड खोलते हैं, यह JPA (Hibernate के आधार पर) और JDBC के साथ SQL के लिए दो प्रारंभिक कार्यान्वयन (भविष्य के लिए योजना बनाई गई अधिक सुविधाएँ) के साथ आएगा।

JDBC कार्यान्वयन मुझे सबसे अधिक प्रसन्न करता है, क्योंकि यह प्रतिबिंब से पूरी तरह से स्वतंत्र है, अपने डेटा स्तर तक पहुँचने के लिए प्रॉक्सी और डायनेमिक क्लास लोडिंग का उपयोग नहीं करता है, जिससे बेहतर प्रदर्शन होता है। रनटाइम लेयर इतनी हल्की है कि हाथ से लिखा गया समान रिपॉजिटरी कोड भी तेजी से निष्पादित नहीं करेगा।

प्रदर्शन शिकारी

चूंकि शिकारी को रन समय में किसी भी क्वेरी परिवर्तनों को निष्पादित करने की आवश्यकता नहीं है, इसलिए प्रदर्शन लाभ महत्वपूर्ण है। क्लाउड कंप्यूटिंग उपयोग की दुनिया में, जहां आप उस समय की राशि का भुगतान करते हैं जो आपका एप्लिकेशन चलाता है या किसी एकल फ़ंक्शन के निष्पादन के लिए, डेवलपर्स अक्सर अपने डेटा एक्सेस तंत्र के प्रदर्शन की दृष्टि खो देते हैं।

निम्न तालिका उन प्रदर्शन अंतरों को findByTitle , findByTitle अन्य कार्यान्वयन की तुलना में एक सरल खोज अभिव्यक्ति के लिए अपेक्षित किया जा सकता है, जैसे findByTitle । सभी परीक्षण 8-कोर Xeon iMac प्रो पर एक ही स्थिति के तहत एक परीक्षण बेंच का उपयोग करके किए गए थे, परीक्षण खुले हैं और भंडार में पाए जा सकते हैं:

जी हां, आपने सही पढ़ा। शिकारी JDBC के साथ, आप GORM पर लगभग 4X प्रदर्शन वृद्धि और स्प्रिंग डेटा पर 2.5X की अपेक्षा कर सकते हैं।

और यहां तक ​​कि अगर आप प्रिडेटर जेपीए का उपयोग करते हैं, तो आप GORM की तुलना में 2X से अधिक प्रदर्शन सुधार और स्प्रिंग डेटा JPA की तुलना में 40% तक की वृद्धि पर भरोसा कर सकते हैं।

विकल्पों की तुलना में प्रीडेटर का उपयोग करते समय निष्पादन स्टैक के आकार में अंतर को देखें:

प्रीडेटर:

शिकारी JPA:

स्प्रिंग डेटा:

GORM:

जब तक आपका अनुरोध निष्पादित नहीं हो जाता है, तब तक शिकारी JDBC केवल 15 फ्रेम का उपयोग करता है, जबकि Predator JPA 30 का उपयोग करता है (मुख्यतः हाइबरनेट के कारण), स्प्रिंग डेटा या GORM में 50+ स्टैक फ़्रेम की तुलना में। और सभी अंतरिक्ष यात्री एओपी तंत्र के लिए धन्यवाद जो प्रतिबिंब का उपयोग नहीं करते हैं।

छोटे स्टैकर्स भी आवेदन डिबगिंग को सरल बनाते हैं। संकलन के दौरान अधिकांश काम करने के फायदों में से एक यह है कि अनुप्रयोगों के लॉन्च से पहले त्रुटियों का पता लगाया जा सकता है, जो कि डेवलपर के अनुभव में काफी सुधार करता है। हम सबसे सामान्य त्रुटियों के लिए रनटाइम त्रुटियों के बजाय संकलन त्रुटियों को तुरंत प्राप्त करते हैं।

संकलन समय जाँचता है

रिपॉजिटरी टेम्प्लेट के अधिकांश कार्यान्वयन रनटाइम पर सभी कार्यों को पूरा करने पर निर्भर करते हैं। इसका मतलब यह है कि अगर डेवलपर रिपॉजिटरी के इंटरफेस को परिभाषित करने में गलती करता है, तो जब तक आवेदन वास्तव में लॉन्च नहीं किया जाता है, तब तक त्रुटियां दिखाई नहीं देंगी।

यह हमें टाइपिंग जाँच के लिए जावा के कुछ लाभों के बारे में बताता है और हमारे पास खराब डेटा अनुभव है। प्रीडेटर के साथ ऐसा नहीं है। निम्नलिखित उदाहरण पर विचार करें:

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

यहाँ BookRepository हमने Book नामक एक ऑब्जेक्ट के लिए अनुरोध किया है, जिसमें एक title संपत्ति है। दुर्भाग्यवश, इस घोषणा में एक त्रुटि है: हमने findByTile नाम की जगह findByTile नाम दिया। इस कोड को चलाने के बजाय, प्रिडेटर आपके कोड को एक सूचनात्मक त्रुटि संदेश के साथ संकलित करने की अनुमति नहीं देगा:

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

प्रिडेटर के कई पहलुओं को संकलित समय पर जांचा जाता है, जब संभव हो, यह सुनिश्चित करने के लिए कि एक रनटाइम त्रुटि एक गलत रिपोजिशन घोषणा के कारण नहीं है।

शिकारी JDBC और GraalVM सबस्ट्रेट

एक और कारण है कि प्रीडेटर को खुश होना चाहिए कि यह देशी ग्रेवालम सबस्ट्रेट छवियों के साथ संगत बॉक्स से बाहर है और निर्माण के दौरान जटिल बाइटेकोड रूपांतरणों की आवश्यकता नहीं है, ग्रेवालम पर हाइबरनेट के विपरीत।

डेटा एक्सेस लेयर से परावर्तन और डायनेमिक प्रॉक्सी को पूरी तरह से समाप्त करके, प्रिडेटर उन अनुप्रयोगों के निर्माण को बहुत सरल करता है जो ग्रेवालम पर चलने वाले डेटा के साथ काम करते हैं।

प्रिडेटर JDBC नमूना एप्लिकेशन बिना किसी समस्या के सबस्ट्रेट पर चलता है और आपको एक बहुत छोटी मूल छवि बनाने की अनुमति देता है (25 एमबी कम!) थिन हाइनेट को बहुत पतले रनटाइम लेयर के कारण काम करने की आवश्यकता होती है।

हमने उसी परिणाम को देखा जब हमने माइक्रोन्यूट 1.2 के लिए बीन सत्यापन नियम को लागू किया। देशी छवि का आकार 10 एमबी तक कम हो गया, जैसे ही हमने हाइबरनेट वैलिडेटर पर निर्भरता को हटा दिया, और 2 एमबी द्वारा जार आकार।

यहाँ लाभ स्पष्ट है: संकलन के दौरान अधिक काम करने और अधिक कॉम्पैक्ट रनटाइम्स बनाने से, आपको एक छोटी देशी छवि और एक JAR फ़ाइल मिलती है, जो डॉकटर के माध्यम से तैनात करते समय माइक्रोसर्विस को तैनात करने के लिए छोटी और आसान होती है। जावा फ्रेमवर्क का भविष्य अधिक शक्तिशाली संकलक और छोटे, हल्के रनटाइम्स हैं।

भविष्यदाता और भविष्य

हम सिर्फ प्रीडेटर के साथ काम करना शुरू कर रहे हैं और उन अवसरों से बेहद खुश हैं जो इसे खोलते हैं।

प्रारंभ में, हम JPA और SQL के लिए समर्थन के साथ शुरू करते हैं, लेकिन भविष्य में आप MongoDB, Neo4J, प्रतिक्रियाशील SQL और अन्य डेटाबेस के लिए समर्थन की उम्मीद कर सकते हैं। सौभाग्य से, यह काम बहुत सरल है क्योंकि अधिकांश शिकारी वास्तव में GORM स्रोत कोड पर आधारित हैं, और हम Neo4J के लिए GORM तर्क और MongoDB के लिए GORM का उपयोग इन अपेक्षाओं को आपकी अपेक्षा से अधिक तेज़ी से जारी करने के लिए कर सकते हैं।

प्रीडेटर, माइक्रोएरूट कोर में विभिन्न बिल्डिंग ब्लॉक्स के संयोजन की परिणति है, जिससे इसे लागू करना संभव हो गया है, एओटी एपीआई से, जो कि स्वैगर प्रलेखन उत्पन्न करने के लिए भी उपयोग किया जाता है, अपेक्षाकृत नए बीन आत्मनिरीक्षण समर्थन के लिए, जो आपको प्रतिबिंब के बिना रनटाइम पर वस्तुओं का विश्लेषण करने की अनुमति देता है।

अंतरिक्ष यात्री अद्भुत चीजों के लिए बिल्डिंग ब्लॉक प्रदान करता है। प्रीडेटर ऐसी ही एक चीज़ है, और हम अभी अभी माइक्रोनायट 1.0 के कुछ होनहारों पर काम करना शुरू कर रहे हैं।

अद्यतन: चौंकाने वाली घोषणा के बाद, स्प्रिंग डेटा किलर का नाम बदलकर माइक्रोएरनेट डेटा रखा गया: https://micronaut-projects.imtqy.com/micronaut-data/1.0.x/guide/