MemcacheDB बनाम क्योटो टाइकून - एक्सप्रेस परीक्षण

हाल ही में, विशुद्ध रूप से संयोग से, एफएएल लैब्स के एक उत्पाद - क्योटो टाइकून , एक हल्के डेटा सर्वर ने मेरी आंख को पकड़ लिया। इस उत्पाद का आधार QDBM (क्विक डेटाबेस मैनेजर) है, जो एक महत्वपूर्ण-मूल्य डेटा वेयरहाउस है। इसने मुझे अचंभित कर दिया कि आप इस "टाइकून से क्योटो" के साथ ज्ञापन-जैसे प्रोटोकॉल के माध्यम से संवाद कर सकते हैं।

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

यहाँ मुझे क्या मिला है:



जिस सर्वर पर हमने परीक्षण किया वह ओपेरटन -2218, 2.6GHz, 8G OP, HDD 73G + 143G sas था ।

73-गीगाबाइट डिस्क पर आयातित डेटा के साथ एक फ़ाइल थी, और 143-गीगाबाइट डेटाबेस मेम्चेचेबडी और क्योटो टाइकून पर।

प्रारंभिक डेटा - 10226086 रिकॉर्ड, कुल मात्रा (कुंजी + मूल्य) 1.4G।



डेटा सर्वर कमांड द्वारा शुरू किए गए हैं:

$ ktserver -port 11114 -tout 10 -log /var /db_tests/kyoto/ktserver.log -ls -dmn -pid /var/db_tests/kyoto/ktserver.pid -plsv/usr/local/libexec/ktplugservmememso.so port = 11115 '/var/db_tests/kyoto/data.kch#opts=l#bnum=20000000#msiz=2g#dfunit=8'



$ मेमेकबेडब -p11117 -d -r -u sen -H / var / db_tests / mbb / db / -N -v -vvar /db_tests/mcdb/mcdb-tests.pid



परिणाम :

1. डेटा आयात:

- क्योटो टाइकून - 18 मिनट 52 सेकंड।

- मेमेचेबीडी - 32 मिनट 39 सेकंड

2. डेटा पढ़ना (लॉग से कुंजी की सूची के अनुसार, डेटा को संबंधित डेटाबेस से चुना गया था, सत्यापन के लिए चेकसमों पर विचार किया गया था):

- क्योटो टाइकून - 9 मिनट 46 सेकंड। (अपने कैश को रीसेट करने के लिए डेमॉन को फिर से शुरू किया, परिणाम 4 सेकंड से खराब हो गया)

- मेम्चेचेबीडी - 19 मिनट 35 सेकंड

3. "रेसिंग" (एक साथ दोनों डेटा आयात स्क्रिप्ट लॉन्च):

- क्योटो टाइकून - 1 घंटा।

- मेमेचेबीडीबी - 1 घंटा 38 मिनट।

जब जापानी समाप्त हो गया, तब तक मेम्चेचेबडी ने प्रविष्टियों की कुल संख्या का एक तिहाई अपलोड कर दिया था।

जाहिर है, सर्वर पर बढ़ा दैनिक भार सामान्य "दौड़" के इतने लंबे समय के लिए दोषी था। दुर्भाग्य से, मेरे पास पूरी तरह से साफ सर्वर नहीं था। लेकिन मैंने इसके अलावा अन्य परीक्षणों को फ्रीर घंटे और दो बार शुरू किया, ताकि प्रक्रिया पर कम से कम थोड़ा-थोड़ा प्रभाव समाप्त हो सके।



और कुछ और विशेषताएं :

1. डेटा फ़ाइल का आकार:

- क्योटो टाइकून - 2.15G (अगले दिन यह "सिकुड़ गया" डेटा हानि के बिना 1.87G, जाहिरा तौर पर खाली ब्लॉक जारी किया गया)।

- मेमेचेबीडीबी - 4.56 जी

2. व्याप्त RAM का आकार:

- क्योटो टाइकून - 2.45G। ईमानदारी से उधार लिया गया था कि उसे कितनी अनुमति दी गई थी, साथ ही कोड और व्यक्तिगत जरूरतों को भी।

- मेमेचेबीडीबी - 208Mb।



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

अलग-अलग मापदंडों के साथ क्योटो टाइकून के परीक्षण के परिणाम (मैं केवल वही दिखाऊंगा जो मैंने उपरोक्त कमांड में बदला है):

1. bnum = 5,000,000 (4 गुना कम, रिकॉर्ड की संख्या से 2 गुना कम) - 17 मिनट 28 सेकंड

2.bnum = 2,000,000 - 17 मिनट 45 सेकंड

3.bnum = 5,000,000 # msiz = 1g (कब्जा की गई RAM का आकार आधा) - 18 मिनट 23 सेकंड

4. bnum = 5,000,000 # msiz = 500 m (भी आधा) - 19 मिनट 15 सेकंड।

5. डेटा फ़ाइल के लिए मापदंडों के बिना (विकल्प, जब उपयोगकर्ता ट्यूनिंग को परेशान नहीं करता है, तो सर्वर मैनुअल से कमांड को कॉपी करके शुरू होता है):

- डेटा आयात - 22 मिनट। 4 सेकंड

- डेटा पढ़ना - 11 मिनट 47 सेकंड

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

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



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



विवरण के बारे में मुझे जो कुछ विशेष रूप से पसंद था वह था "मजबूती में सुधार: डेटाबेस फ़ाइल भीषण स्थिति में भी भ्रष्ट नहीं है" - डेवलपर्स को यह निराधार कहने की संभावना नहीं है, शायद कोई ऐसा व्यक्ति होगा जो जांच करना चाहता है।



पुनश्च। वास्तव में, मुझे मेम्चेचेबडी और क्योटो टाइकून की थोड़ी सतही तुलना मिली, और थोड़ा अधिक विस्तृत परीक्षण - क्योटो टाइकून। किसी भी मामले में, मुझे कानों से परिणाम आकर्षित नहीं हुए, मैंने जिन परियोजनाओं का समर्थन किया, उनमें से एक के वास्तविक डेटा के साथ मैंने काम किया।



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



यूपीडीटी । अंतिम परीक्षण के परिणामों का विश्लेषण करते हुए, मैंने पाया कि क्योटो टाइकून सर्वर को शुरू करने के बाद, इसे सहेजने के लिए डेटा भेजने से पहले 5-10 सेकंड इंतजार करना उचित है। परीक्षण के दौरान, जब मैंने सर्वर को नए मापदंडों के साथ फिर से शुरू किया और तुरंत उसे डेटा भेजना शुरू किया, तो लगभग 16 हजार पहले रिकॉर्ड खो गए। यानी पहले 2 सेकंड के लिए, डेटा लोडर ने दीवार के खिलाफ अपना सिर पीटा। पहले से चल रहे सर्वर के साथ काम करते समय, कोई नुकसान नहीं हुआ। इस तरह की देरी सामान्य है - डेटा फ़ील्ड को चिह्नित करना, काम की तैयारी।



UPDT2 । चूंकि मेम्चेचेबीडी के लिए डिफ़ॉल्ट कैश आकार 64 एमबी है, इसने एमएसआईज = 64 मीटर के साथ एक परीक्षण किया - इसने कैश आकार को बराबर कर दिया।

परिणाम:

- रिकॉर्डिंग - 25 मिनट 43 सेकंड

- पढ़ना - 12 मिनट 26 सेकंड

यानी वैसे भी, गति अधिक है। लेकिन उन्होंने उसी समय 400 एमबी - मेमेचेबीडी से दो गुना अधिक रैम को खा लिया।

इसलिए, रैम - एक नुकसान, डिस्क पर डेटाबेस की गति और आकार - लाभ (डेटाबेस का आकार लगभग 2.5 गुना है)।

निश्चित रूप से गति में लाभ अधिक कॉम्पैक्ट स्टोरेज के कारण भी है - कम डिस्क संचालन।



UPDT3 (01.03.2011 से) । ऊपर वर्णित परीक्षण के दौरान प्राप्त किए गए डेटाबेस के उल्लेखनीय रूप से छोटे फ़ाइल आकार के कारण, क्योटो टाइकून को एक अन्य परियोजना पर रखा गया जहां बर्कलेबीडीबी (फ्रंट-एंड में मेमाचेबीडी के साथ) 32 गीगा के आकार तक पहुंच गया। अब क्योटो टाइकून डेटाबेस फ़ाइल "वेट" 30 गिग है। मैंने केवल गीगाबाइट के एक जोड़े को बचाया, अंतर कई बार नहीं है। बचत डेटा के प्रकार पर अत्यधिक निर्भर हैं। परीक्षणों ने पाठ डेटा का उपयोग किया, जो अच्छी तरह से संपीड़ित है, और नई परियोजना में, द्विआधारी डेटा के ब्लॉक। मैं इस मामले में काम की गति के बारे में कुछ नहीं कह सकता। डेटाबेस को भरते समय, डाटा प्रोसेसिंग से गुजरता है, जो डेटाबेस से अधिक समय लेता है

।