गो मधील बिटमॅप अनुक्रमणिका: जंगली वेगाने शोधा

परिचय

मी हा अहवाल मॉस्कोमधील गोफरकॉन रशिया 2019 परिषदेत इंग्रजीत आणि निझनी नोव्हगोरोड येथे झालेल्या बैठकीत रशियन भाषेत दिला. आम्ही बिटमॅप इंडेक्सबद्दल बोलत आहोत - बी-ट्रीपेक्षा कमी सामान्य, परंतु कमी मनोरंजक नाही. शेअरिंग मुद्रित करणे कॉन्फरन्समधील भाषणे इंग्रजीमध्ये आणि मजकूर प्रतिलिपी रशियनमध्ये.

बिटमॅप इंडेक्स कसे कार्य करते, ते केव्हा चांगले असते, ते इतर निर्देशांकांपेक्षा केव्हा वाईट असते आणि कोणत्या बाबतीत ते त्यांच्यापेक्षा लक्षणीयरीत्या वेगवान असते ते आम्ही पाहू; कोणत्या लोकप्रिय DBMS मध्ये आधीपासून बिटमॅप इंडेक्स आहेत ते पाहूया; चला गो मध्ये स्वतःचे लिहिण्याचा प्रयत्न करूया. आणि "मिठाईसाठी" आम्ही आमचा स्वतःचा सुपर-फास्ट स्पेशलाइज्ड डेटाबेस तयार करण्यासाठी तयार लायब्ररी वापरू.

मला आशा आहे की माझी कामे तुमच्यासाठी उपयुक्त आणि मनोरंजक असतील. जा!

परिचय

http://bit.ly/bitmapindexes
https://github.com/mkevac/gopherconrussia2019

सर्वांना नमस्कार! संध्याकाळचे सहा वाजले आहेत आणि आम्ही सर्व थकलो आहोत. कंटाळवाणा डेटाबेस इंडेक्स सिद्धांताबद्दल बोलण्यासाठी उत्तम वेळ, बरोबर? काळजी करू नका, माझ्याकडे सोर्स कोडच्या दोन ओळी इथे आणि तिथे असतील. 🙂

सर्व विनोद बाजूला ठेवून, अहवाल माहितीने भरलेला आहे आणि आमच्याकडे जास्त वेळ नाही. चला तर मग सुरुवात करूया.

आज मी पुढील गोष्टींबद्दल बोलणार आहे.

• निर्देशांक काय आहेत;
• बिटमॅप इंडेक्स म्हणजे काय;
• ते कुठे वापरले जाते आणि कुठे वापरले जात नाही आणि का;
• गो मध्ये सोपी अंमलबजावणी आणि कंपाइलरशी थोडा संघर्ष;
• गो असेंबलरमध्ये थोडेसे कमी सोपे, परंतु अधिक उत्पादक अंमलबजावणी;
• बिटमॅप इंडेक्सच्या "समस्या";
• विद्यमान अंमलबजावणी.

तर अनुक्रमणिका म्हणजे काय?

इंडेक्स ही एक वेगळी डेटा रचना आहे जी आम्ही मुख्य डेटा व्यतिरिक्त राखतो आणि अपडेट करतो. याचा उपयोग शोध वेग वाढवण्यासाठी केला जातो. निर्देशांकांशिवाय, शोधासाठी डेटा पूर्णपणे जाणे आवश्यक आहे (एक प्रक्रिया ज्याला पूर्ण स्कॅन म्हणतात), आणि या प्रक्रियेमध्ये रेखीय अल्गोरिदमिक जटिलता आहे. परंतु डेटाबेसमध्ये सामान्यत: प्रचंड प्रमाणात डेटा असतो आणि रेखीय जटिलता खूप मंद असते. आदर्शपणे, आपल्याला लॉगरिदमिक किंवा स्थिरांक मिळेल.

हा एक अत्यंत गुंतागुंतीचा विषय आहे, ज्यात बारीकसारीक गोष्टी आणि व्यापार-ऑफ आहेत, परंतु अनेक दशकांच्या डेटाबेस विकास आणि संशोधनाकडे पाहिल्यानंतर, मी हे सांगण्यास तयार आहे की डेटाबेस निर्देशांक तयार करण्यासाठी फक्त काही व्यापकपणे वापरले जाणारे दृष्टिकोन आहेत.

शोध जागा पदानुक्रमाने कमी करणे, शोध जागा लहान भागांमध्ये विभागणे हा पहिला दृष्टीकोन आहे.

आपण हे सहसा वेगवेगळ्या प्रकारच्या झाडांचा वापर करून करतो. एक उदाहरण म्हणजे तुमच्या कपाटातील साहित्याचा एक मोठा बॉक्स ज्यामध्ये वेगवेगळ्या विषयांमध्ये विभागलेल्या साहित्याचे छोटे बॉक्स असतील. जर तुम्हाला साहित्य हवे असेल, तर तुम्ही कदाचित ते "कुकीज" ऐवजी "सामग्री" म्हणणाऱ्या बॉक्समध्ये शोधाल, बरोबर?

दुसरा दृष्टिकोन म्हणजे ताबडतोब इच्छित घटक किंवा घटकांचा गट निवडणे. आम्ही हे हॅश मॅप किंवा रिव्हर्स इंडेक्समध्ये करतो. हॅश नकाशे वापरणे हे मागील उदाहरणासारखेच आहे, परंतु बॉक्सच्या बॉक्सऐवजी, आपल्याकडे आपल्या कपाटात अंतिम वस्तूंचे लहान बॉक्स आहेत.

तिसरा दृष्टीकोन म्हणजे शोधाची गरज दूर करणे. आम्ही हे ब्लूम फिल्टर किंवा कोकीळ फिल्टर वापरून करतो. प्रथम लोक त्वरित उत्तर देतात, तुम्हाला शोधण्यापासून वाचवतात.

आधुनिक हार्डवेअरने दिलेल्या सर्व शक्तीचा पूर्ण वापर करणे हा शेवटचा दृष्टीकोन आहे. आपण बिटमॅप इंडेक्समध्ये हेच करतो. होय, त्यांचा वापर करताना आम्हाला कधीकधी संपूर्ण निर्देशांकातून जावे लागते, परंतु आम्ही ते अत्यंत कार्यक्षमतेने करतो.

मी म्हटल्याप्रमाणे, डेटाबेस इंडेक्सचा विषय विस्तृत आणि तडजोडीने भरलेला आहे. याचा अर्थ असा की कधीकधी आम्ही एकाच वेळी अनेक पद्धती वापरू शकतो: जर आम्हाला शोध आणखी वेगवान करायचा असेल किंवा आम्हाला सर्व संभाव्य शोध प्रकार कव्हर करायचे असतील तर.

आज मी यापैकी सर्वात कमी ज्ञात दृष्टिकोन - बिटमॅप निर्देशांकांबद्दल बोलणार आहे.

या विषयावर बोलणारा मी कोण?

मी Badoo येथे टीम लीड म्हणून काम करतो (कदाचित तुम्ही आमच्या इतर उत्पादन, बंबलबद्दल अधिक परिचित असाल). आमच्याकडे आधीपासूनच जगभरात 400 दशलक्षाहून अधिक वापरकर्ते आहेत आणि त्यांच्यासाठी सर्वोत्तम जुळणी निवडणारी अनेक वैशिष्ट्ये आहेत. बिटमॅप इंडेक्ससह सानुकूल सेवा वापरून आम्ही हे करतो.

तर बिटमॅप इंडेक्स म्हणजे काय?

बिटमॅप अनुक्रमणिका, नावाप्रमाणेच, शोध निर्देशांक लागू करण्यासाठी बिटमॅप किंवा बिटसेट वापरतात. पक्ष्यांच्या नजरेतून, या निर्देशांकामध्ये कोणत्याही घटकांचे (जसे की लोक) आणि त्यांचे गुणधर्म किंवा पॅरामीटर्स (वय, डोळ्यांचा रंग इ.) दर्शवणारे एक किंवा अधिक बिटमॅप असतात आणि बिट ऑपरेशन्स (AND, OR, NOT) वापरून अल्गोरिदम असतात. ) शोध प्रश्नाचे उत्तर देण्यासाठी.

आम्हाला सांगण्यात आले आहे की बिटमॅप इंडेक्सेस सर्वोत्तम अनुकूल आहेत आणि अशा प्रकरणांसाठी अतिशय कार्यक्षम आहेत जिथे शोध आहेत जे अनेक कमी कार्डिनॅलिटी स्तंभांमध्ये क्वेरी एकत्र करतात (विचार करा "डोळ्याचा रंग" किंवा "वैवाहिक स्थिती" विरुद्ध "शहर केंद्रापासून अंतर" सारखे काहीतरी). पण मी नंतर दाखवेन की ते उच्च कार्डिनॅलिटी कॉलमसाठी देखील चांगले काम करतात.

बिटमॅप इंडेक्सचे सर्वात सोपे उदाहरण पाहू.

अशी कल्पना करा की आमच्याकडे यासारख्या बायनरी गुणधर्मांसह मॉस्को रेस्टॉरंट्सची यादी आहे:

• मेट्रो जवळ;
• खाजगी पार्किंग आहे;
• एक व्हरांडा आहे (टेरेस आहे);
• तुम्ही टेबल आरक्षित करू शकता (आरक्षण स्वीकारते);
• शाकाहारींसाठी योग्य (शाकाहारी अनुकूल);
• महाग (महाग).

चला प्रत्येक रेस्टॉरंटला 0 पासून सुरू होणारा एक क्रम क्रमांक देऊ आणि 6 बिटमॅप्ससाठी (प्रत्येक वैशिष्ट्यासाठी एक) मेमरी देऊ. त्यानंतर रेस्टॉरंटकडे ही मालमत्ता आहे की नाही यावर अवलंबून आम्ही हे बिटमॅप तयार करू. जर रेस्टॉरंट 4 मध्ये व्हरांडा असेल, तर बिट क्रमांक 4 मधील “व्हरांडा आहे” बिटमॅप 1 वर सेट केला जाईल (जर व्हरांडा नसेल तर 0 वर).

आता आमच्याकडे शक्य तितका सोपा बिटमॅप इंडेक्स आहे आणि आम्ही ते प्रश्नांची उत्तरे देण्यासाठी वापरू शकतो:

• “मला शाकाहारी-अनुकूल रेस्टॉरंट दाखवा”;
• "मला व्हरांडा असलेली स्वस्त रेस्टॉरंट दाखवा जिथे तुम्ही टेबल आरक्षित करू शकता."

कसे? चला एक नजर टाकूया. पहिली विनंती अगदी सोपी आहे. आम्हाला फक्त “शाकाहारी अनुकूल” बिटमॅप घ्यायचा आहे आणि ते रेस्टॉरंट्सच्या यादीत बदलायचे आहे ज्यांचे बिट उघड झाले आहेत.


दुसरी विनंती थोडी अधिक क्लिष्ट आहे. स्वस्त रेस्टॉरंट्सची यादी मिळवण्यासाठी आम्हाला “महाग” बिटमॅपवर नॉट बिटमॅप वापरण्याची आवश्यकता आहे, आणि नंतर “मी टेबल बुक करू शकतो” बिटमॅपसह आणि आणि “व्हरांडा आहे” बिटमॅपसह परिणाम. परिणामी बिटमॅपमध्ये आमच्या सर्व निकषांची पूर्तता करणाऱ्या आस्थापनांची सूची असेल. या उदाहरणात, हे फक्त युनोस्ट रेस्टॉरंट आहे.


यात बरेच सिद्धांत गुंतलेले आहेत, परंतु काळजी करू नका, आम्ही लवकरच कोड पाहू.

बिटमॅप इंडेक्स कुठे वापरले जातात?

तुम्ही Google बिटमॅप इंडेक्स केल्यास, 90% उत्तरे ओरॅकल डीबीशी संबंधित असतील. परंतु इतर डीबीएमएस देखील कदाचित अशा छान गोष्टीला समर्थन देतात, बरोबर? खरंच नाही.

मुख्य संशयितांची यादी पाहू.

MySQL अद्याप बिटमॅप निर्देशांकांना समर्थन देत नाही, परंतु हा पर्याय जोडण्याचा प्रस्ताव आहे (https://dev.mysql.com/worklog/task/?id=1524).

PostgreSQL बिटमॅप इंडेक्सेसला सपोर्ट करत नाही, परंतु इतर अनेक इंडेक्सेसमध्ये शोध परिणाम एकत्र करण्यासाठी साधे बिटमॅप आणि बिट ऑपरेशन्स वापरते.

टारनटूलमध्ये बिटसेट अनुक्रमणिका आहेत आणि त्यावर साध्या शोधांना समर्थन देते.

रेडिसमध्ये साधे बिटफिल्ड आहेत (https://redis.io/commands/bitfield) त्यांचा शोध घेण्याच्या क्षमतेशिवाय.

मोंगोडीबी अद्याप बिटमॅप निर्देशांकांना समर्थन देत नाही, परंतु हा पर्याय जोडण्याचा प्रस्ताव देखील आहे https://jira.mongodb.org/browse/SERVER-1723

Elasticsearch अंतर्गत बिटमॅप वापरते (https://www.elastic.co/blog/frame-of-reference-and-roaring-bitmaps).

• पण आमच्या घरात एक नवीन शेजारी दिसला: पिलोसा. हा गो मध्ये लिहिलेला नवीन नॉन-रिलेशनल डेटाबेस आहे. त्यामध्ये फक्त बिटमॅप इंडेक्स असतात आणि त्यावर सर्व गोष्टींचा आधार असतो. आपण याबद्दल थोड्या वेळाने बोलू.

गो मध्ये अंमलबजावणी

पण बिटमॅप इंडेक्स इतके क्वचितच का वापरले जातात? या प्रश्नाचे उत्तर देण्यापूर्वी, मी तुम्हाला गो मध्ये अगदी सोप्या बिटमॅप इंडेक्सची अंमलबजावणी कशी करावी हे दाखवू इच्छितो.

बिटमॅप हे मूलत: फक्त डेटाचे तुकडे असतात. गो मध्ये, यासाठी बाइट स्लाइस वापरू.

आमच्याकडे एका रेस्टॉरंटच्या वैशिष्ट्यासाठी एक बिटमॅप आहे आणि बिटमॅपमधील प्रत्येक बिट विशिष्ट रेस्टॉरंटमध्ये ही मालमत्ता आहे की नाही हे सूचित करते.

आम्हाला दोन हेल्पर फंक्शन्सची आवश्यकता असेल. यादृच्छिक डेटासह आमचे बिटमॅप भरण्यासाठी एक वापरला जाईल. यादृच्छिक, परंतु विशिष्ट संभाव्यतेसह की रेस्टॉरंटमध्ये प्रत्येक मालमत्ता आहे. उदाहरणार्थ, माझा विश्वास आहे की मॉस्कोमध्ये खूप कमी रेस्टॉरंट्स आहेत जिथे आपण टेबल आरक्षित करू शकत नाही आणि मला असे दिसते की सुमारे 20% आस्थापना शाकाहारींसाठी योग्य आहेत.

दुसरे फंक्शन बिटमॅपला रेस्टॉरंटच्या सूचीमध्ये रूपांतरित करेल.


"मला अशी स्वस्त रेस्टॉरंट दाखवा ज्यात पॅटिओ आहे आणि ते आरक्षण करू शकतात" या प्रश्नाचे उत्तर देण्यासाठी आम्हाला दोन बिट ऑपरेशन्सची आवश्यकता आहे: नाही आणि आणि.

अधिक जटिल आणि नाही ऑपरेटर वापरून आम्ही आमचा कोड थोडासा सोपा करू शकतो.

आमच्याकडे या प्रत्येक ऑपरेशनसाठी कार्ये आहेत. ते दोन्ही स्लाइसमधून जातात, प्रत्येकाकडून संबंधित घटक घ्या, त्यांना थोड्या ऑपरेशनसह एकत्र करा आणि परिणामी स्लाइसमध्ये परिणाम ठेवा.

आणि आता आपण शोध क्वेरीचे उत्तर देण्यासाठी आमचे बिटमॅप आणि कार्ये वापरू शकतो.

कार्यप्रदर्शन इतके उच्च नाही, जरी फंक्शन्स अगदी सोपी आहेत आणि प्रत्येक वेळी फंक्शन कॉल केल्यावर नवीन परिणामी स्लाइस परत न करून आम्ही खूप पैसे वाचवले.

pprof सोबत थोडेसे प्रोफाइलिंग केल्यावर, माझ्या लक्षात आले की गो कंपाइलरमध्ये एक अतिशय साधे पण अतिशय महत्त्वाचे ऑप्टिमायझेशन गहाळ आहे: फंक्शन इनलाइनिंग.

वस्तुस्थिती अशी आहे की गो कंपाइलरला स्लाइसमधून जाणाऱ्या लूपची भीती वाटते आणि अशा लूप असलेल्या इनलाइन फंक्शन्सना स्पष्टपणे नकार दिला जातो.

पण मला भीती वाटत नाही आणि जुन्या दिवसांप्रमाणे मी लूपऐवजी गोटो वापरून कंपाइलरला फसवू शकतो.

आणि, तुम्ही बघू शकता, आता कंपाइलर आनंदाने आमचे कार्य इनलाइन करेल! परिणामी, आम्ही सुमारे 2 मायक्रोसेकंद वाचविण्यास व्यवस्थापित करतो. वाईट नाही!

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

सर्व स्लाइस समान आकाराचे आहेत हे दाखवून कंपाइलरला आश्वस्त करू या. आपण आपल्या फंक्शनच्या सुरुवातीला एक साधी तपासणी जोडून हे करू शकतो.

हे पाहून, कंपाइलर आनंदाने चेक वगळतो आणि आम्ही आणखी 500 नॅनोसेकंद वाचवतो.

मोठे बुच

ठीक आहे, आम्ही आमच्या सोप्या अंमलबजावणीतून काही कार्यप्रदर्शन पिळून काढण्यात व्यवस्थापित केले, परंतु हा परिणाम सध्याच्या हार्डवेअरच्या शक्यतेपेक्षा खूपच वाईट आहे.

आम्ही फक्त मूलभूत बिट ऑपरेशन्स करतो आणि आमचे प्रोसेसर ते अतिशय कार्यक्षमतेने करतात. परंतु, दुर्दैवाने, आम्ही आमच्या प्रोसेसरला कामाच्या अगदी लहान तुकड्यांसह "फीड" करतो. आमची कार्ये बाइट-बाय-बाइट आधारावर कार्य करतात. UInt8 स्लाइस वापरून 64-बाइट भागांसह कार्य करण्यासाठी आम्ही आमच्या कोडमध्ये अगदी सहजपणे बदल करू शकतो.

तुम्ही बघू शकता, या छोट्या बदलामुळे बॅचचा आकार आठ पटीने वाढवून आमचा कार्यक्रम आठ पटीने वाढला. लाभ रेखीय आहे असे म्हणता येईल.

असेंबलर मध्ये अंमलबजावणी

पण हा शेवट नाही. आमचे प्रोसेसर 16, 32 आणि अगदी 64 बाइट्सच्या भागांसह कार्य करू शकतात. अशा "ब्रॉड" ऑपरेशन्सना सिंगल इंस्ट्रक्शन मल्टिपल डेटा (SIMD; एक इंस्ट्रक्शन, अनेक डेटा) म्हणतात आणि कोड ट्रान्स्फॉर्म करण्याच्या प्रक्रियेला व्हेक्टरायझेशन म्हणतात.

दुर्दैवाने, गो कंपाइलर व्हेक्टरायझेशनमध्ये उत्कृष्ट नाही. सध्या, गो कोड व्हेक्टराइज करण्याचा एकमेव मार्ग म्हणजे गो असेंबलर वापरून ही ऑपरेशन्स मॅन्युअली घेणे आणि ठेवणे.

गो असेंबलर एक विचित्र पशू आहे. तुम्हाला कदाचित माहित असेल की असेंब्ली लँग्वेज ही अशी गोष्ट आहे जी तुम्ही ज्या कॉम्प्युटरसाठी लिहित आहात त्याच्या आर्किटेक्चरशी जोरदारपणे जोडलेली आहे, परंतु गो मध्ये तसे नाही. गो असेंबलर ही IRL (मध्यवर्ती प्रतिनिधित्व भाषा) किंवा मध्यवर्ती भाषेसारखी आहे: ती व्यावहारिकदृष्ट्या स्वतंत्र प्लॅटफॉर्म आहे. रॉब पाईकने उत्कृष्ट कामगिरी केली अहवाल या विषयावर अनेक वर्षांपूर्वी डेन्व्हरमधील गोफरकॉन येथे.

याव्यतिरिक्त, गो असामान्य प्लॅन 9 फॉरमॅट वापरते, जे सामान्यतः स्वीकारल्या जाणार्‍या AT&T आणि Intel फॉरमॅटपेक्षा वेगळे आहे.

हे सांगणे सुरक्षित आहे की हाताने गो असेंबलर लिहिणे सर्वात मजेदार नाही.

परंतु, सुदैवाने, आधीच दोन उच्च-स्तरीय साधने आहेत जी आम्हाला Go असेंबलर लिहिण्यास मदत करतात: PeachPy आणि avo. दोन्ही उपयुक्तता अनुक्रमे पायथन आणि गो मध्ये लिहिलेल्या उच्च-स्तरीय कोडमधून Go असेंबलर तयार करतात.

या उपयुक्तता नोंदणी वाटप, लेखन लूप यासारख्या गोष्टी सुलभ करतात आणि गो मधील असेंब्ली प्रोग्रामिंगच्या जगात प्रवेश करण्याची प्रक्रिया साधारणपणे सुलभ करतात.

आम्ही एव्हो वापरु, त्यामुळे आमचे कार्यक्रम जवळजवळ नियमित गो प्रोग्राम असतील.

एव्हो प्रोग्रामचे सर्वात सोपे उदाहरण असे दिसते. आमच्याकडे मुख्य() फंक्शन आहे, जे स्वतःमध्ये Add() फंक्शन परिभाषित करते, ज्याचा अर्थ दोन संख्या जोडणे आहे. नावानुसार पॅरामीटर्स मिळवण्यासाठी आणि विनामूल्य आणि योग्य प्रोसेसर रजिस्टरपैकी एक मिळवण्यासाठी येथे मदतनीस कार्ये आहेत. प्रत्येक प्रोसेसर ऑपरेशनमध्ये ADDQ मध्ये पाहिल्याप्रमाणे, avo वर संबंधित कार्य असते. शेवटी, परिणामी व्हॅल्यू संचयित करण्यासाठी आम्हाला एक हेल्पर फंक्शन दिसते.

गो जनरेट कॉल करून, आम्ही एव्हीओवर प्रोग्राम कार्यान्वित करू आणि परिणामी, दोन फाइल्स तयार होतील:

• Go असेंबलरमध्ये परिणामी कोडसह add.s;
• दोन जग जोडण्यासाठी फंक्शन हेडरसह stub.go: जा आणि असेंबलर.

आता आपण एव्हो काय आणि कसे करतो ते पाहिले आहे, आता आपली कार्ये पाहू. मी फंक्शन्सच्या दोन्ही स्केलर आणि वेक्टर (SIMD) आवृत्त्या लागू केल्या.

प्रथम स्केलर आवृत्त्या पाहू.

मागील उदाहरणाप्रमाणे, आम्ही विनामूल्य आणि वैध सामान्य उद्देश रजिस्टरसाठी विचारत आहोत, आम्हाला युक्तिवादांसाठी ऑफसेट आणि आकारांची गणना करण्याची आवश्यकता नाही. avo हे सर्व आमच्यासाठी करतो.

कार्यप्रदर्शन सुधारण्यासाठी आणि गो कंपाइलरची युक्ती करण्यासाठी आम्ही लेबले आणि गोटो (किंवा जंप) वापरायचो, परंतु आता आम्ही ते सुरुवातीपासून करत आहोत. मुद्दा असा आहे की सायकल ही उच्च-स्तरीय संकल्पना आहे. असेंबलरमध्ये, आमच्याकडे फक्त लेबले आणि उडी आहेत.

उर्वरित कोड आधीच परिचित आणि समजण्यासारखा असावा. आम्ही लेबल्स आणि जंपसह लूपचे अनुकरण करतो, आमच्या दोन स्लाइसमधून डेटाचा एक छोटा तुकडा घेतो, त्यांना थोडा ऑपरेशनसह एकत्र करतो (आणि या प्रकरणात नाही) आणि नंतर परिणामी स्लाइसमध्ये निकाल ठेवतो. सर्व.

अंतिम असेंबलर कोड असे दिसते. आम्हाला ऑफसेट आणि आकार (हिरव्या रंगात हायलाइट केलेले) किंवा वापरलेल्या नोंदींचा मागोवा ठेवण्याची गरज नव्हती (लाल रंगात हायलाइट केलेले).

गो मधील सर्वोत्कृष्ट अंमलबजावणीच्या कामगिरीशी असेंब्ली लँग्वेज अंमलबजावणीच्या कामगिरीची तुलना केल्यास, आम्हाला ते समान असल्याचे दिसेल. आणि हे अपेक्षित आहे. शेवटी, आम्ही काही विशेष केले नाही - आम्ही फक्त गो कंपाइलर काय करेल याचे पुनरुत्पादन केले.

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

त्यामुळे असेंब्ली भाषेत छोट्या फंक्शन्सचा फायदा मिळणे अशक्य आहे. आम्हाला एकतर मोठी फंक्शन्स लिहावी लागतील किंवा नवीन गणित/बिट्स पॅकेज वापरावे लागेल किंवा असेंबलर भाषा बायपास करावी लागेल.

आता आपल्या फंक्शन्सच्या वेक्टर आवृत्त्या पाहू.

या उदाहरणासाठी, मी AVX2 वापरण्याचा निर्णय घेतला, म्हणून आम्ही 32-बाइट भागांवर चालणारी ऑपरेशन्स वापरू. कोडची रचना स्केलर आवृत्तीसारखीच आहे: पॅरामीटर्स लोड करणे, विनामूल्य सामायिक नोंदणीसाठी विचारणे इ.

एक नावीन्य म्हणजे व्यापक वेक्टर ऑपरेशन्स विशेष वाइड रजिस्टर्स वापरतात. 32-बाइट भागांच्या बाबतीत, हे Y सह प्रीफिक्स केलेले रजिस्टर आहेत. यामुळे तुम्हाला कोडमध्ये YMM() फंक्शन दिसते. मी AVX-512 64-बिट भागांसह वापरत असल्यास, उपसर्ग Z असेल.

दुसरा नावीन्य असा आहे की मी लूप अनरोलिंग नावाचे ऑप्टिमायझेशन वापरण्याचे ठरवले, याचा अर्थ लूपच्या सुरूवातीस जाण्यापूर्वी आठ लूप ऑपरेशन्स व्यक्तिचलितपणे करणे. हे ऑप्टिमायझेशन कोडमधील शाखांची संख्या कमी करते आणि उपलब्ध मोफत नोंदणींच्या संख्येने मर्यादित आहे.

बरं, कामगिरीबद्दल काय? ती सुंदर आहे! सर्वोत्कृष्ट गो सोल्यूशनच्या तुलनेत आम्ही सुमारे सात पट वेग गाठला. प्रभावी, बरोबर?

परंतु क्वेरी शेड्यूलरसाठी AVX-512, प्रीफेचिंग किंवा JIT (जस्ट-इन-टाइम कंपाइलर) वापरून ही अंमलबजावणी संभाव्यपणे वेगवान केली जाऊ शकते. पण हा स्वतंत्र अहवालाचा विषय नक्कीच आहे.

बिटमॅप इंडेक्ससह समस्या

आता आम्ही गो मधील बिटमॅप इंडेक्सची साधी अंमलबजावणी आणि असेंब्ली भाषेत अधिक फलदायी पाहिली आहे, शेवटी बिटमॅप इंडेक्स इतके क्वचित का वापरले जातात याबद्दल बोलूया.

जुने पेपर्स बिटमॅप इंडेक्ससह तीन समस्यांचा उल्लेख करतात, परंतु नवीन पेपर्स आणि मी असा युक्तिवाद करतो की ते यापुढे संबंधित नाहीत. आपण या प्रत्येक समस्येत खोलवर डोकावणार नाही, तर वरवरच्या नजरेने पाहू.

उच्च कार्डिनॅलिटीची समस्या

म्हणून, आम्हाला सांगण्यात आले आहे की बिटमॅप निर्देशांक फक्त कमी कार्डिनॅलिटी असलेल्या फील्डसाठी योग्य आहेत, म्हणजे ज्यांची काही मूल्ये आहेत (उदाहरणार्थ, लिंग किंवा डोळ्याचा रंग), आणि कारण असे आहे की अशा फील्डचे नेहमीचे प्रतिनिधित्व (एक बिट प्रति मूल्य) उच्च कार्डिनॅलिटीच्या बाबतीत, ते खूप जागा घेईल आणि त्याशिवाय, हे बिटमॅप निर्देशांक खराब (क्वचितच) भरले जातील.


कधीकधी आम्ही भिन्न प्रतिनिधित्व वापरू शकतो, जसे की आम्ही संख्या दर्शवण्यासाठी वापरतो. परंतु कॉम्प्रेशन अल्गोरिदमच्या आगमनाने सर्वकाही बदलले. गेल्या दशकांमध्ये, शास्त्रज्ञ आणि संशोधकांनी बिटमॅपसाठी मोठ्या प्रमाणात कॉम्प्रेशन अल्गोरिदम आणले आहेत. त्यांचा मुख्य फायदा असा आहे की बिट ऑपरेशन्स करण्यासाठी बिटमॅप्स डीकॉम्प्रेस करण्याची आवश्यकता नाही - आम्ही थेट कॉम्प्रेस केलेल्या बिटमॅप्सवर बिट ऑपरेशन्स करू शकतो.

अलीकडे, हायब्रीड पध्दती दिसू लागल्या आहेत, जसे की गर्जना बिटमॅप. ते एकाच वेळी बिटमॅपसाठी तीन भिन्न प्रतिनिधित्व वापरतात - बिटमॅप स्वतः, अॅरे आणि तथाकथित बिट रन - आणि कार्यप्रदर्शन वाढवण्यासाठी आणि मेमरी वापर कमी करण्यासाठी त्यांच्यामध्ये संतुलन राखतात.

आपण सर्वात लोकप्रिय अनुप्रयोगांमध्ये गर्जना करणारे बिटमॅप शोधू शकता. Go साठी तीनपेक्षा जास्त अंमलबजावणीसह विविध प्रकारच्या प्रोग्रामिंग भाषांसाठी आधीपासूनच मोठ्या संख्येने अंमलबजावणी आहेत.

आणखी एक दृष्टीकोन जो आपल्याला उच्च कार्डिनॅलिटीचा सामना करण्यास मदत करू शकतो त्याला बिनिंग म्हणतात. अशी कल्पना करा की तुमच्याकडे एखाद्या व्यक्तीची उंची दर्शवणारे फील्ड आहे. उंची हा फ्लोटिंग पॉईंट नंबर आहे, परंतु आपण मानव त्याचा तसा विचार करत नाही. आमच्यासाठी 185,2 सेमी आणि 185,3 सेमी उंचीमध्ये फरक नाही.

असे दिसून आले की आम्ही समान मूल्ये 1 सेमीच्या आत गटांमध्ये गटबद्ध करू शकतो.

आणि जर आपल्याला हे देखील माहित असेल की फारच कमी लोक 50 सेमी पेक्षा लहान आणि 250 सेमी पेक्षा उंच आहेत, तर आपण मूलत: असीम कार्डिनॅलिटी असलेल्या फील्डला सुमारे 200 मूल्यांच्या कार्डिनॅलिटीच्या फील्डमध्ये बदलू शकतो.

अर्थात, आवश्यक असल्यास, आम्ही नंतर अतिरिक्त फिल्टरिंग करू शकतो.

उच्च बँडविड्थ समस्या

बिटमॅप इंडेक्सेसची पुढील समस्या अशी आहे की त्यांना अपडेट करणे खूप महाग असू शकते.

संभाव्यतः इतर शेकडो क्वेरी डेटा शोधत असताना डेटाबेस डेटा अद्यतनित करण्यास सक्षम असणे आवश्यक आहे. समवर्ती डेटा प्रवेश किंवा इतर सामायिकरण समस्या टाळण्यासाठी आम्हाला लॉकची आवश्यकता आहे. आणि जेथे एक मोठे कुलूप आहे, तेथे एक समस्या आहे - लॉक विवाद, जेव्हा हे लॉक अडथळे बनते.

शार्डिंग वापरून किंवा आवृत्तीत अनुक्रमणिका वापरून ही समस्या सोडवली किंवा दूर केली जाऊ शकते.

Sharding ही एक साधी आणि सुप्रसिद्ध गोष्ट आहे. तुम्ही इतर कोणत्याही डेटाप्रमाणे बिटमॅप इंडेक्स शार्ड करू शकता. एका मोठ्या लॉकऐवजी, तुम्हाला लहान कुलूपांचा समूह मिळेल आणि अशा प्रकारे लॉक विवादातून मुक्त व्हा.

समस्येचे निराकरण करण्याचा दुसरा मार्ग म्हणजे आवृत्तीत अनुक्रमणिका वापरणे. तुमच्याकडे अनुक्रमणिकेची एक प्रत असू शकते जी तुम्ही शोधण्यासाठी किंवा वाचण्यासाठी वापरता आणि एक प्रत तुम्ही लिहिण्यासाठी किंवा अपडेट करण्यासाठी वापरता. आणि ठराविक कालावधीत एकदा (उदाहरणार्थ, प्रत्येक 100 ms किंवा 500 ms मध्ये एकदा) तुम्ही त्यांची डुप्लिकेट करा आणि त्यांची अदलाबदल करा. अर्थात, हा दृष्टीकोन केवळ अशा प्रकरणांमध्येच लागू होतो जेव्हा तुमचा अनुप्रयोग थोडासा मागे पडणारा शोध निर्देशांक हाताळू शकतो.

हे दोन पध्दती एकाच वेळी वापरल्या जाऊ शकतात: तुमच्याकडे शार्डेड वर्जन इंडेक्स असू शकतात.

अधिक जटिल प्रश्न

बिटमॅप इंडेक्सेसची अंतिम समस्या ही आहे की आम्हाला सांगितले जाते की ते अधिक जटिल प्रकारच्या क्वेरीसाठी योग्य नाहीत, जसे की स्पॅन क्वेरी.

खरंच, जर तुम्ही त्याबद्दल विचार केला तर, AND, OR, इत्यादी बिट ऑपरेशन्स प्रश्नांसाठी फारशी योग्य नाहीत a la "मला दर रात्री 200 ते 300 डॉलर्सच्या खोलीचे दर असलेले हॉटेल दाखवा."

प्रत्येक डॉलर मूल्यासाठी परिणाम घेणे आणि त्यांना बिटवाइज किंवा ऑपरेशनसह एकत्र करणे हा एक भोळा आणि अत्यंत मूर्ख उपाय असेल.

थोडा चांगला उपाय म्हणजे ग्रुपिंग वापरणे. उदाहरणार्थ, 50 डॉलर्सच्या गटांमध्ये. हे आमच्या प्रक्रियेला 50 पटीने गती देईल.

परंतु या प्रकारच्या विनंतीसाठी विशेषतः तयार केलेले दृश्य वापरून समस्या देखील सहजपणे सोडविली जाते. वैज्ञानिक पेपर्समध्ये याला रेंज-एनकोडेड बिटमॅप्स म्हणतात.

या प्रतिनिधित्वामध्ये, आम्ही काही मूल्यासाठी फक्त एक बिट सेट करत नाही (उदाहरणार्थ, 200), परंतु हे मूल्य आणि सर्व काही उच्च सेट करतो. 200 आणि वरील. 300: 300 आणि वरील साठी समान. वगैरे.

हे प्रतिनिधित्व वापरून, आम्ही अनुक्रमणिका फक्त दोनदा ट्रॅव्हर्स करून अशा प्रकारच्या शोध प्रश्नाचे उत्तर देऊ शकतो. प्रथम, आम्हाला अशा हॉटेलची यादी मिळेल जिथे खोलीची किंमत $300 किंवा $199 कमी आहे आणि नंतर आम्ही त्या हॉटेलमधून काढून टाकू जिथे खोलीची किंमत कमी किंवा $XNUMX आहे. तयार.

तुम्हाला आश्चर्य वाटेल, पण बिटमॅप इंडेक्स वापरून जिओक्वेरीज देखील शक्य आहेत. युक्ती म्हणजे भौमितिक प्रतिनिधित्व वापरणे जे तुमच्या समन्वयाला भौमितिक आकृतीसह घेरते. उदाहरणार्थ, Google कडून S2. आकृती तीन किंवा अधिक छेदणार्‍या रेषांच्या स्वरूपात दर्शवू शकते ज्यांना क्रमांकित केले जाऊ शकते. अशा प्रकारे आपण आपली जिओक्वेरी “अलोंग द गॅप” (या क्रमांकाच्या रेषांसह) अनेक क्वेरींमध्ये बदलू शकतो.

तयार उपाय

मला आशा आहे की मला तुमची थोडीशी आवड आहे आणि आता तुमच्या शस्त्रागारात आणखी एक उपयुक्त साधन आहे. तुम्हाला कधीही असे काहीतरी करण्याची आवश्यकता असल्यास, तुम्हाला कोणत्या मार्गाने पहावे हे समजेल.

तथापि, सुरवातीपासून बिटमॅप निर्देशांक तयार करण्यासाठी प्रत्येकाकडे वेळ, संयम किंवा संसाधने नसतात. विशेषतः अधिक प्रगत, SIMD वापरून, उदाहरणार्थ.

सुदैवाने, तुम्हाला मदत करण्यासाठी अनेक तयार उपाय आहेत.

गर्जना बिटमॅप्स

प्रथम, तीच गर्जना करणारी बिटमॅप लायब्ररी आहे ज्याबद्दल मी आधीच बोललो आहे. त्यामध्ये सर्व आवश्यक कंटेनर आणि बिट ऑपरेशन्स आहेत ज्यांची तुम्हाला संपूर्ण बिटमॅप इंडेक्स तयार करण्याची आवश्यकता असेल.

दुर्दैवाने, याक्षणी, Go अंमलबजावणींपैकी कोणतीही SIMD वापरत नाही, याचा अर्थ Go अंमलबजावणी C अंमलबजावणीपेक्षा कमी कार्यक्षम आहेत, उदाहरणार्थ.

पिलोसा

आणखी एक उत्पादन जे तुम्हाला मदत करू शकते ते म्हणजे पिलोसा डीबीएमएस, ज्यामध्ये खरे तर फक्त बिटमॅप निर्देशांक आहेत. हा तुलनेने नवीन उपाय आहे, परंतु तो खूप वेगाने मने जिंकत आहे.

Pilosa अंतर्गतपणे roaring bitmaps वापरते आणि तुम्हाला ते वापरण्याची क्षमता देते, मी वर बोललेल्या सर्व गोष्टी सुलभ करते आणि स्पष्ट करते: गटबद्ध करणे, श्रेणी-एनकोड केलेले बिटमॅप, फील्डची संकल्पना इ.

आपण आधीच परिचित असलेल्या प्रश्नाचे उत्तर देण्यासाठी Pilosa वापरण्याचे उदाहरण पाहू या.

उदाहरण तुम्ही आधी पाहिलेल्यासारखेच आहे. आम्ही पिलोसा सर्व्हरवर क्लायंट तयार करतो, एक अनुक्रमणिका आणि आवश्यक फील्ड तयार करतो, नंतर आमची फील्ड संभाव्यतेसह यादृच्छिक डेटाने भरतो आणि शेवटी, परिचित क्वेरी कार्यान्वित करतो.

त्यानंतर, आम्ही "महाग" फील्डवर नाही वापरतो, नंतर परिणाम (किंवा आणि ते) "टेरेस" फील्ड आणि "आरक्षण" फील्डसह छेदतो. आणि शेवटी, आम्हाला अंतिम परिणाम मिळेल.

मला खरोखर आशा आहे की नजीकच्या भविष्यात हा नवीन प्रकारचा निर्देशांक MySQL आणि PostgreSQL - bitmap indexes सारख्या DBMS मध्ये देखील दिसून येईल.

निष्कर्ष

तुम्हाला अजून झोप लागली नसेल तर धन्यवाद. मर्यादित वेळेमुळे मला बर्‍याच विषयांवर थोडक्यात स्पर्श करावा लागला, परंतु मला आशा आहे की चर्चा उपयुक्त होती आणि कदाचित प्रेरणादायक देखील होती.

बिटमॅप इंडेक्सेसची आपल्याला आत्ता गरज नसली तरीही त्याबद्दल जाणून घेणे चांगले आहे. त्यांना तुमच्या टूलबॉक्समधील दुसरे साधन असू द्या.

आम्ही Go साठी विविध कार्यप्रदर्शन युक्त्या पाहिल्या आहेत आणि गो कंपाइलर अद्याप चांगल्या प्रकारे हाताळत नसलेल्या गोष्टी पाहिल्या आहेत. परंतु हे प्रत्येक गो प्रोग्रामरला जाणून घेण्यासाठी पूर्णपणे उपयुक्त आहे.

मला तुला एवढेच सांगायचे होते. धन्यवाद!

स्त्रोत: www.habr.com