क्लिकहाऊसचा प्रभावी वापर. अलेक्सी मिलोविडोव्ह (यांडेक्स)

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

सर्वांना नमस्कार! माझे नाव अॅलेक्सी आहे, मी क्लिकहाऊस बनवतो.

प्रथम, मी लगेच तुम्हाला संतुष्ट करण्यासाठी घाई केली, आज मी तुम्हाला क्लिकहाऊस काय आहे हे सांगणार नाही. खरे सांगायचे तर मला त्याचा कंटाळा आला आहे. प्रत्येक वेळी मी तुम्हाला ते काय आहे ते सांगतो. आणि कदाचित प्रत्येकाला आधीच माहित आहे.

त्याऐवजी, मी तुम्हाला सांगेन की कोणत्या संभाव्य चुका आहेत, म्हणजेच तुम्ही क्लिकहाऊस चुकीच्या पद्धतीने कसे वापरू शकता. खरं तर, घाबरण्याची गरज नाही, कारण आम्ही क्लिकहाऊस ही एक सोपी, सोयीस्कर आणि बॉक्सच्या बाहेर काम करणारी प्रणाली म्हणून विकसित करत आहोत. मी ते स्थापित केले, कोणतीही समस्या नाही.

परंतु तरीही तुम्हाला हे लक्षात घेणे आवश्यक आहे की ही प्रणाली विशेषीकृत आहे आणि तुम्ही या प्रणालीला त्याच्या कम्फर्ट झोनमधून बाहेर काढणारे असामान्य वापर प्रकरण सहजपणे पाहू शकता.

तर, तेथे कोणत्या प्रकारचे रेक आहे? मुख्यतः मी स्पष्ट गोष्टींबद्दल बोलेन. सर्व काही प्रत्येकासाठी स्पष्ट आहे, प्रत्येकाला सर्वकाही समजते आणि ते इतके हुशार आहेत याचा आनंद होऊ शकतो आणि ज्यांना समजत नाही ते काहीतरी नवीन शिकतील.

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

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

आणि वैशिष्ट्यपूर्ण कामगिरी काय असेल ते पाहूया. उदाहरणार्थ, आमच्याकडे Yandex.Metrica डेटावरून एक सारणी आहे. हिट्स. 105 काही स्तंभ. 700 बाइट्स असंपीडित. आणि आम्ही एक दशलक्ष पंक्तींच्या बॅचमध्ये चांगल्या प्रकारे घालू.

आम्ही टेबलमध्ये MergeTree समाविष्ट करतो, ते प्रति सेकंद अर्धा दशलक्ष पंक्ती बाहेर वळते. मस्त. प्रतिकृती सारणीमध्ये ते थोडेसे लहान असेल, अंदाजे 400 पंक्ती प्रति सेकंद.

आणि तुम्ही कोरम इन्सर्शन सक्षम केल्यास, तुम्हाला थोडे कमी, परंतु तरीही सभ्य कामगिरी, 250 अटी प्रति सेकंद मिळेल. क्लिकहाऊस* मध्‍ये कोरम इन्सर्शन हे एक अदस्तांकित वैशिष्ट्य आहे.

* 2020 पर्यंत, आधीच दस्तऐवजीकरण.

आपण काही वाईट केले तर काय होईल? आम्ही MergeTree टेबलमध्ये एक पंक्ती घालतो आणि प्रति सेकंद 59 पंक्ती मिळवतो. ते 10 पटीने कमी आहे. ReplicatedMergeTree मध्ये - 000 पंक्ती प्रति सेकंद. आणि जर कोरम चालू असेल तर तो प्रति सेकंद 6 ओळी निघतो. माझ्या मते, हा एक प्रकारचा निरपेक्ष बकवास आहे. आपण असे कसे कमी करू शकता? मी माझ्या टी-शर्टवर देखील लिहिले आहे की क्लिकहाऊसची गती कमी होऊ नये. पण असे असले तरी कधीकधी असे घडते.

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

तांत्रिक दृष्टिकोनातून, मुद्दा असा आहे की जेव्हा तुम्ही क्लिकहाऊसमध्ये इन्सर्ट करता तेव्हा डेटा कोणत्याही मेमटेबलमध्ये संपत नाही. आमच्याकडे वास्तविक लॉग स्ट्रक्चर देखील नाही MergeTree, परंतु फक्त एक MergeTree, कारण तेथे लॉग किंवा मेमटेबल नाही. आम्‍ही तात्‍काळ फाईल सिस्‍टममध्‍ये डेटा लिहितो, आधीपासून स्‍तंभांमध्ये मांडलेला असतो. आणि जर तुमच्याकडे 100 कॉलम असतील तर 200 पेक्षा जास्त फाइल्स वेगळ्या डिरेक्टरीमध्ये लिहिल्या जातील. हे सर्व खूप त्रासदायक आहे.

आणि प्रश्न उद्भवतो: "ते योग्य कसे करावे?" जर परिस्थिती अशी आहे की आपल्याला अद्याप क्लिकहाऊसमध्ये कसा तरी डेटा रेकॉर्ड करणे आवश्यक आहे.

पद्धत 1. हा सर्वात सोपा मार्ग आहे. काही प्रकारची वितरित रांग वापरा. उदाहरणार्थ, काफ्का. तुम्ही फक्त काफ्का कडून डेटा काढा आणि सेकंदातून एकदा बॅच करा. आणि सर्व काही ठीक होईल, आपण रेकॉर्ड करा, सर्वकाही ठीक कार्य करते.

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

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

परंतु या पद्धतीचा तोटा असा आहे की जर तुमचा सर्व्हर ज्यावर लॉग तयार केले जातात ते कुठेतरी गायब झाले तर डेटा देखील गायब होईल.

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

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

पद्धत 4. ​​आणखी एक मनोरंजक पद्धत. तुमच्याकडे काही प्रकारची सर्व्हर प्रक्रिया आहे का. आणि ते त्वरित क्लिकहाऊसला डेटा पाठवू शकते, परंतु ते एका कनेक्शनमध्ये करू शकते. उदाहरणार्थ, मी ट्रान्सफर-एनकोडिंगसह http विनंती पाठवली: chunked with insert. आणि तो भाग तयार करतो फार क्वचितच नाही, तुम्ही प्रत्येक ओळ पाठवू शकता, जरी हा डेटा फ्रेम करण्यासाठी ओव्हरहेड असेल.

तथापि, या प्रकरणात डेटा त्वरित क्लिकहाऊसवर पाठविला जाईल. आणि क्लिकहाऊस त्यांना स्वतः बफर करेल.

पण समस्याही निर्माण होतात. आता तुमची प्रक्रिया कधी संपली आणि क्लिकहाऊस प्रक्रिया नष्ट झाली यासह तुमचा डेटा गमवाल, कारण ती अपूर्ण टाकली जाईल. आणि क्लिकहाऊस इन्सर्टमध्ये पंक्तींच्या आकारात विशिष्ट निर्दिष्ट थ्रेशोल्डपर्यंत अणू असतात. तत्वतः, हा एक मनोरंजक मार्ग आहे. देखील वापरता येईल.

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

* 2020 नुसार, देखील विचारात जोडले जावे किटनहाऊस.

पद्धत 6. दुसरी पद्धत म्हणजे बफर टेबल वापरणे. या पद्धतीचा फायदा असा आहे की वापरणे सुरू करणे खूप सोपे आहे. एक बफर टेबल तयार करा आणि त्यात घाला.

गैरसोय म्हणजे समस्या पूर्णपणे सोडवली जात नाही. जर, MergeTree सारख्या दरामध्ये, तुम्हाला प्रति सेकंद एका बॅचने डेटा गटबद्ध करायचा असेल, तर बफर टेबलमधील दरानुसार, तुम्हाला प्रति सेकंद किमान हजारांपर्यंत गट करणे आवश्यक आहे. जर ते प्रति सेकंद 10 पेक्षा जास्त असेल, तरीही ते खराब होईल. आणि जर तुम्ही ते बॅचमध्ये घातले तर तुम्ही पाहिले की ते प्रति सेकंद एक लाख ओळी होते. आणि हे आधीच बर्‍यापैकी भारी डेटावर आहे.

आणि बफर टेबलमध्ये लॉग नाही. आणि जर तुमच्या सर्व्हरमध्ये काही गडबड असेल तर डेटा नष्ट होईल.

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

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

* 2020 पर्यंत, समान समर्थन दिसले आहे ससा MQ.

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

* या क्षणी, समस्येचे पूर्णपणे निराकरण झाले आहे, VALUES मध्ये अभिव्यक्ती वापरताना कोणतेही कार्यप्रदर्शन प्रतिगमन नाही.

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

* अलीकडे, प्रायोगिक मोडमध्ये, क्लिकहाऊसने राइट-अहेड लॉगसह रॅममधील भाग आणि भागांच्या कॉम्पॅक्ट फॉरमॅटसाठी समर्थन जोडले, जे जवळजवळ पूर्णपणे समस्येचे निराकरण करते.

आता दुसऱ्या प्रकारची समस्या पाहू - डेटा टायपिंग.

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

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

उदाहरणार्थ, आमच्याकडे एक IP पत्ता आहे. एका बाबतीत, आम्ही ते स्ट्रिंग म्हणून जतन केले. उदाहरणार्थ, 192.168.1.1. आणि दुसर्‍या बाबतीत, तो UInt32* प्रकारचा एक नंबर असेल. IPv32 पत्त्यासाठी 4 बिट पुरेसे आहेत.

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

परंतु प्रोसेसर वेळ आणि क्वेरी अंमलबजावणी वेळेत एक गंभीर फरक आहे.

अनन्य IP पत्ते संख्या म्हणून संग्रहित असल्यास त्यांची संख्या मोजू. ते प्रति सेकंद 137 दशलक्ष ओळींवर कार्य करते. जर तेच स्ट्रिंग्सच्या स्वरूपात असेल, तर प्रति सेकंद 37 दशलक्ष रेषा. हा योगायोग का घडला माहीत नाही. मी स्वतः या विनंत्या पूर्ण केल्या. परंतु तरीही सुमारे 4 पट हळू.

आणि जर आपण डिस्क स्पेसमधील फरक मोजला तर फरक देखील आहे. आणि फरक सुमारे एक चतुर्थांश आहे, कारण बरेच अद्वितीय IP पत्ते आहेत. आणि जर थोड्या संख्येने भिन्न अर्थ असलेल्या ओळी असतील तर त्या डिक्शनरीनुसार अंदाजे समान व्हॉल्यूममध्ये सहजपणे संकुचित केल्या जातील.

आणि चौपट वेळेचा फरक रस्त्यावर पडत नाही. कदाचित तुम्ही नक्कीच दाद देणार नाही, पण जेव्हा मी असा फरक पाहतो तेव्हा मला वाईट वाटते.

चला भिन्न प्रकरणे पाहू.

1. एक केस जेव्हा तुमच्याकडे काही भिन्न अद्वितीय मूल्ये असतात. या प्रकरणात, आम्ही एक सोपा सराव वापरतो जो तुम्हाला कदाचित माहित असेल आणि कोणत्याही DBMS साठी वापरू शकता. हे सर्व केवळ क्लिकहाऊससाठीच नाही तर अर्थपूर्ण आहे. डेटाबेसमध्ये फक्त अंकीय अभिज्ञापक लिहा. आणि तुम्ही स्ट्रिंग्समध्ये रूपांतरित करू शकता आणि तुमच्या ऍप्लिकेशनच्या बाजूला.

उदाहरणार्थ, तुमच्याकडे एक प्रदेश आहे. आणि तुम्ही ते स्ट्रिंग म्हणून सेव्ह करण्याचा प्रयत्न करत आहात. आणि तेथे लिहिले जाईल: मॉस्को आणि मॉस्को क्षेत्र. आणि जेव्हा मी पाहतो की ते "मॉस्को" म्हणते तेव्हा ते काहीही नाही, परंतु जेव्हा ते मॉस्को असते तेव्हा ते पूर्णपणे दुःखी होते. हे किती बाइट्स आहे.

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

दुसरा पर्याय अंदाजे समान आहे, परंतु क्लिकहाऊसमध्ये समर्थनासह. हा Enum डेटा प्रकार आहे. एनममध्ये तुम्हाला आवश्यक असलेली सर्व मूल्ये तुम्ही फक्त लिहा. उदाहरणार्थ, डिव्हाइसचा प्रकार आणि तेथे लिहा: डेस्कटॉप, मोबाइल, टॅब्लेट, टीव्ही. एकूण 4 पर्याय आहेत.

गैरसोय असा आहे की आपल्याला ते वेळोवेळी बदलण्याची आवश्यकता आहे. फक्त एक पर्याय जोडला. चला टेबल बदलू. खरं तर, क्लिकहाऊसमधील ऑल्टर टेबल विनामूल्य आहे. एनमसाठी विशेषतः विनामूल्य कारण डिस्कवरील डेटा बदलत नाही. पण तरीही, alter टेबलवर लॉक* मिळवतो आणि सर्व निवडी कार्यान्वित होईपर्यंत प्रतीक्षा करणे आवश्यक आहे. आणि त्यानंतरच हे बदल अंमलात आणले जातील, म्हणजे अजूनही काही गैरसोयी आहेत.

* ClickHouse च्या नवीनतम आवृत्त्यांमध्ये, ALTER पूर्णपणे नॉन-ब्लॉकिंग केले आहे.

क्लिकहाऊससाठी अगदी अद्वितीय असलेला दुसरा पर्याय म्हणजे बाह्य शब्दकोश जोडणे. तुम्ही क्लिकहाऊसमध्ये अंक लिहू शकता आणि तुमच्यासाठी सोयीस्कर असलेल्या कोणत्याही प्रणालीमध्ये तुमची निर्देशिका ठेवू शकता. उदाहरणार्थ, तुम्ही वापरू शकता: MySQL, Mongo, Postgres. तुम्ही तुमची स्वतःची मायक्रोसर्व्हिस देखील तयार करू शकता जी हा डेटा http द्वारे पाठवेल. आणि क्लिकहाऊस स्तरावर, तुम्ही एक फंक्शन लिहा जे हा डेटा संख्यांपासून स्ट्रिंगमध्ये रूपांतरित करेल.

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

येथे एक उदाहरण आहे. Yandex.Direct आहे. आणि एक जाहिरात कंपनी आणि बॅनर आहे. कदाचित लाखो जाहिरात कंपन्या आहेत. आणि ते साधारणपणे RAM मध्ये बसतात. आणि कोट्यवधी बॅनर आहेत, ते बसत नाहीत. आणि आम्ही MySQL वरून कॅशे केलेला शब्दकोश वापरतो.

फक्त समस्या अशी आहे की हिट दर 100% च्या जवळ असल्यास कॅशे केलेला शब्दकोश चांगले कार्य करेल. जर ते लहान असेल, तर डेटाच्या प्रत्येक बॅचसाठी क्वेरीवर प्रक्रिया करताना, तुम्हाला प्रत्यक्षात गहाळ की घ्याव्या लागतील आणि MySQL वरून डेटा मिळवा. क्लिकहाऊस बद्दल, मी अजूनही याची हमी देऊ शकतो - होय, ते कमी होत नाही, मी इतर सिस्टमबद्दल बोलणार नाही.

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

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

एकमात्र समस्या अशी आहे की जर हॅश 64-बिट असेल तर तुम्हाला जवळजवळ नक्कीच टक्कर होतील. कारण जर तेथे एक अब्ज ओळी असतील तर संभाव्यता आधीच लक्षात येईल.

आणि अशा प्रकारे जाहिरात कंपन्यांची नावे हॅश करणे फार चांगले होणार नाही. निरनिराळ्या कंपन्यांच्या जाहिरातींची सरमिसळ केली, तर काहीतरी अनाकलनीय होईल.

आणि एक सोपी युक्ती आहे. खरे आहे, हे गंभीर डेटासाठी देखील फारसे योग्य नाही, परंतु जर काहीतरी फारसे गंभीर नसेल, तर डिक्शनरी कीमध्ये क्लायंट अभिज्ञापक जोडा. आणि मग तुमची टक्कर होईल, परंतु केवळ एका क्लायंटमध्ये. आणि आम्ही Yandex.Metrica मधील लिंक नकाशांसाठी ही पद्धत वापरतो. आमच्याकडे URL आहेत, आम्ही हॅश संचयित करतो. आणि आम्हाला माहित आहे की, अर्थातच टक्कर आहेत. परंतु जेव्हा पृष्ठ प्रदर्शित केले जाते, तेव्हा एका वापरकर्त्याच्या एका पृष्ठावर काही URL एकत्र अडकले आहेत आणि हे लक्षात येईल या संभाव्यतेकडे दुर्लक्ष केले जाऊ शकते.

बोनस म्हणून, बर्‍याच ऑपरेशन्ससाठी फक्त हॅश पुरेसे आहेत आणि स्ट्रिंग्स कुठेही संग्रहित करण्याची आवश्यकता नाही.

दुसरे उदाहरण म्हणजे स्ट्रिंग लहान असल्यास, उदाहरणार्थ, वेबसाइट डोमेन. ते जसेच्या तसे संग्रहित केले जाऊ शकतात. किंवा, उदाहरणार्थ, ब्राउझर भाषा ru - 2 बाइट्स. अर्थात, मला बाइट्सबद्दल खरोखर वाईट वाटते, परंतु काळजी करू नका, 2 बाइट्स ही खेदाची गोष्ट नाही. कृपया ते जसेच्या तसे ठेवा, काळजी करू नका.

दुसरी केस अशी आहे की, त्याउलट, खूप ओळी आहेत आणि त्यामध्ये खूप अद्वितीय आहेत, आणि संच देखील संभाव्य अमर्यादित आहे. एक विशिष्ट उदाहरण म्हणजे शोध वाक्यांश किंवा URL. टायपोसह वाक्यांश शोधा. दररोज किती अद्वितीय शोध वाक्यांश आहेत ते पाहूया. आणि असे दिसून आले की ते सर्व घटनांपैकी जवळजवळ निम्मे आहेत. आणि या प्रकरणात, आपण विचार करू शकता की आपल्याला डेटा सामान्य करणे आवश्यक आहे, अभिज्ञापकांची गणना करणे आणि त्यास वेगळ्या टेबलमध्ये ठेवणे आवश्यक आहे. पण तुम्हाला ते करण्याची गरज नाही. या ओळी जशा आहेत तशाच ठेवा.

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

आणि जर डेटा जागेवर संग्रहित केला असेल तर तो फक्त फाइल सिस्टममधून आवश्यक क्रमाने वाचला जातो आणि सर्व काही ठीक आहे.

जर तुमच्याकडे URL किंवा काही इतर जटिल लांब स्ट्रिंग असतील, तर हे लक्षात घेण्यासारखे आहे की तुम्ही काही प्रकारच्या अर्कांची आगाऊ गणना करू शकता आणि ते वेगळ्या स्तंभात लिहू शकता.

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

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

आणि एका प्रकरणात आम्ही फक्त URL मिळवू आणि डोमेनची गणना करू. ते 166 मिलिसेकंदांपर्यंत कार्य करते. आणि जर तुम्ही रेडीमेड डोमेन घेतले तर ते फक्त 67 मिलिसेकंद, म्हणजे जवळजवळ तीनपट वेगवान होते. आणि हे वेगवान आहे कारण आम्हाला काही गणना करणे आवश्यक आहे, परंतु आम्ही कमी डेटा वाचतो म्हणून.

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

आणि जर आपण डिस्कवरील डेटाचे प्रमाण पाहिले तर असे दिसून आले की URL 126 मेगाबाइट्स आहे आणि डोमेन फक्त 5 मेगाबाइट्स आहे. हे 25 पट कमी बाहेर वळते. परंतु असे असले तरी, विनंती केवळ 4 पट वेगाने कार्यान्वित केली जाते. पण डेटा गरम असल्यामुळे. आणि जर ते थंड असेल तर डिस्क I/O मुळे ते कदाचित 25 पट वेगवान असेल.

तसे, तुम्ही URL पेक्षा डोमेन किती लहान आहे याचा अंदाज लावल्यास, ते सुमारे 4 पट लहान असल्याचे दिसून येते. परंतु काही कारणास्तव, डिस्कवर डेटा 25 पट कमी लागतो. का? संपीडन मुळे. आणि URL संकुचित आहे, आणि डोमेन संकुचित आहे. परंतु बर्‍याचदा URL मध्ये कचरा असतो.

आणि, अर्थातच, ते योग्य डेटा प्रकार वापरण्यासाठी देय देते जे विशेषतः इच्छित मूल्यांसाठी डिझाइन केलेले आहेत किंवा ते योग्य आहेत. तुम्ही IPv4 मध्ये असल्यास, UInt32* स्टोअर करा. जर IPv6 असेल, तर FixedString(16), कारण IPv6 पत्ता 128 बिट्स आहे, म्हणजे थेट बायनरी फॉरमॅटमध्ये संग्रहित केला जातो.

पण तुमच्याकडे कधी IPv4 पत्ते आणि कधी IPv6 असल्यास काय? होय, तुम्ही दोन्ही साठवू शकता. एक स्तंभ IPv4 साठी, दुसरा IPv6 साठी. अर्थात, IPv4 मध्ये IPv6 प्रदर्शित करण्याचा पर्याय आहे. हे देखील कार्य करेल, परंतु जर तुम्हाला वारंवार विनंत्यांमध्ये IPv4 पत्त्याची आवश्यकता असेल, तर ते वेगळ्या स्तंभात ठेवणे चांगले होईल.

* ClickHouse मध्ये आता स्वतंत्र IPv4, IPv6 डेटा प्रकार आहेत जे डेटा संख्यांइतकेच कार्यक्षमतेने संग्रहित करतात, परंतु स्ट्रिंग्सप्रमाणेच त्यांचे प्रतिनिधित्व करतात.

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

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

तर या प्रकरणात 4 स्तंभांमध्ये विभागणे अधिक योग्य होईल. येथे घाबरू नका, कारण हे क्लिकहाऊस आहे. क्लिकहाऊस हा स्तंभीय डेटाबेस आहे. आणि अधिक व्यवस्थित छोटे स्तंभ, चांगले. 5 ब्राउझर आवृत्त्या असतील, 5 कॉलम बनवा. हे ठीक आहे.

आता तुमच्याकडे खूप लांब स्ट्रिंग्स, खूप लांब अॅरे असल्यास काय करायचे ते पाहू. ते अजिबात क्लिकहाऊसमध्ये संग्रहित करण्याची आवश्यकता नाही. त्याऐवजी, तुम्ही फक्त ClickHouse मध्ये एक अभिज्ञापक संचयित करू शकता. आणि या लांबलचक रेषा दुसऱ्या कोणत्या तरी सिस्टीममध्ये टाका.

उदाहरणार्थ, आमच्या एका विश्लेषण सेवेमध्ये काही इव्हेंट पॅरामीटर्स आहेत. आणि जर इव्हेंटसाठी अनेक पॅरामीटर्स असतील तर, आम्ही फक्त समोर येणारे पहिले 512 जतन करतो. कारण 512 ही खेदाची गोष्ट नाही.

आणि जर तुम्ही तुमच्या डेटा प्रकारांवर निर्णय घेऊ शकत नसाल, तर तुम्ही क्लिकहाऊसमध्ये डेटा रेकॉर्ड करू शकता, परंतु तात्पुरत्या डेटासाठी खास लॉग प्रकाराच्या तात्पुरत्या टेबलमध्ये. यानंतर, आपण तेथे मूल्यांचे कोणते वितरण आहे, सर्वसाधारणपणे काय आहे याचे विश्लेषण करू शकता आणि योग्य प्रकार तयार करू शकता.

*क्लिकहाऊसमध्ये आता डेटा प्रकार आहे कमी कार्डिनॅलिटी जे तुम्हाला कमी प्रयत्नात स्ट्रिंग्स कार्यक्षमतेने साठवण्याची परवानगी देते.

आता आणखी एक मनोरंजक प्रकरण पाहू. कधीकधी लोकांसाठी गोष्टी विचित्रपणे कार्य करतात. मी आत येऊन हे पाहतो. आणि लगेच असे दिसते की हे काही अत्यंत अनुभवी, स्मार्ट प्रशासकाने केले आहे ज्यांना MySQL आवृत्ती 3.23 सेट करण्याचा व्यापक अनुभव आहे.

येथे आपण एक हजार तक्ते पाहतो, ज्यापैकी प्रत्येक एक हजाराने काय भागाकाराच्या उर्वरित नोंदी करतो.

तत्वतः, मी इतर लोकांच्या अनुभवाचा आदर करतो, ज्यात या अनुभवातून मिळू शकणार्‍या दुःखाच्या आकलनासह.

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

दुसरे कारण असे आहे की मोठ्या टेबलांवर कोणतेही बदल ऑपरेशन करणे कठीण आहे. सर्व काही अवरोधित केले जाईल. जरी MySQL च्या आधुनिक आवृत्त्यांमध्ये ही समस्या आता इतकी गंभीर नाही.

किंवा, उदाहरणार्थ, मायक्रोशार्डिंग, परंतु नंतर त्याबद्दल अधिक.

क्लिकहाऊसमध्ये हे करण्याची आवश्यकता नाही, कारण, प्रथम, प्राथमिक की क्लस्टर केली जाते, डेटा प्राथमिक की द्वारे क्रमबद्ध केला जातो.

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

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

क्लिकहाऊसमधील ऑल्टर अॅड/ड्रॉप कॉलममध्ये बदल केल्यास विनामूल्य आहे.

आणि तुम्ही लहान तक्ते बनवू नका, कारण तुमच्याकडे टेबलमध्ये 10 पंक्ती किंवा 10 पंक्ती असतील तर काही फरक पडत नाही. क्लिकहाऊस ही एक प्रणाली आहे जी थ्रूपुट ऑप्टिमाइझ करते, विलंब नाही, त्यामुळे 000 ओळींवर प्रक्रिया करण्यात काही अर्थ नाही.

एक मोठे टेबल वापरणे योग्य आहे. जुन्या स्टिरियोटाइपपासून मुक्त व्हा, सर्व काही ठीक होईल.

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

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

* आता ClickHouse देखील आहे टेबल फंक्शन इनपुट.

दुसरा अँटीपॅटर्न म्हणजे मायक्रोशार्डिंग. उदाहरणार्थ, तुम्हाला डेटा शार्ड करणे आवश्यक आहे आणि तुमच्याकडे 5 सर्व्हर आहेत आणि उद्या 6 सर्व्हर असतील. आणि हा डेटा कसा संतुलित करायचा याचा विचार करा. आणि त्याऐवजी तुम्ही 5 शार्ड्समध्ये नाही तर 1 शार्ड्समध्ये मोडता. आणि मग तुम्ही यातील प्रत्येक मायक्रोशार्ड्स वेगळ्या सर्व्हरवर मॅप करा. आणि तुम्हाला, उदाहरणार्थ, एका सर्व्हरवर 000 क्लिक हाऊसेस मिळतील. स्वतंत्र पोर्ट किंवा स्वतंत्र डेटाबेसवर स्वतंत्र उदाहरणे.

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

दुसरे कारण असे आहे की या सर्व उदाहरणांमध्ये कामाचे वितरण असमान असेल. काही लवकर संपतील, काही नंतर संपतील. जर हे सर्व एका प्रसंगात घडले असेल, तर क्लिकहाऊस स्वतः थ्रेड्समध्ये डेटा योग्यरित्या कसा वितरित करायचा हे शोधून काढेल.

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

दुसरा अँटीपॅटर्न, जरी त्याला क्वचितच अँटीपॅटर्न म्हटले जाऊ शकते. हे प्री-एग्रीगेशनचे मोठे प्रमाण आहे.

सर्वसाधारणपणे, पूर्व-एकत्रीकरण चांगले आहे. तुमच्याकडे एक अब्ज पंक्ती होत्या, तुम्ही ती एकत्रित केली आणि ती 1 पंक्ती झाली आणि आता क्वेरी त्वरित कार्यान्वित केली जाते. सर्व काही छान आहे. आपण हे करू शकता. आणि यासाठी, अगदी ClickHouse मध्ये AggregatingMergeTree, एक विशेष टेबल प्रकार आहे, जो डेटा टाकल्यावर वाढीव एकत्रीकरण करतो.

परंतु असे काही वेळा असतात जेव्हा आपण असा विचार करतो की आम्ही यासारखा डेटा एकत्रित करू आणि यासारखा डेटा एकत्रित करू. आणि काही शेजारच्या विभागात, मी कोणते हे सांगू इच्छित नाही, ते प्राथमिक की द्वारे सारांशित करण्यासाठी SummingMergeTree सारण्या वापरतात आणि सुमारे 20 स्तंभ प्राथमिक की म्हणून वापरले जातात. फक्त बाबतीत, मी गोपनीयतेसाठी काही स्तंभांची नावे बदलली आहेत, परंतु ते खूप आहे.

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

आणि त्यात विशेष काय आहे? वस्तुस्थिती अशी आहे की शेजारच्या विभागातील हे लोक कधीकधी जातात आणि प्राथमिक कीमध्ये दुसरा कॉलम जोडण्यास सांगतात. म्हणजेच, आम्ही याप्रमाणे डेटा एकत्रित केला, परंतु आता आम्हाला थोडे अधिक हवे आहे. परंतु ClickHouse मध्ये alter प्राथमिक की नाही. म्हणून, आपल्याला C++ मध्ये काही स्क्रिप्ट लिहिल्या पाहिजेत. आणि मला स्क्रिप्ट आवडत नाहीत, जरी त्या C++ मध्ये असल्या तरी.

आणि क्लिकहाऊस कशासाठी तयार केले गेले ते आपण पाहिल्यास, नॉन-एकत्रित डेटा हीच परिस्थिती आहे ज्यासाठी तो जन्माला आला होता. तुम्ही नॉन-एकत्रित डेटासाठी क्लिकहाऊस वापरत असल्यास, तुम्ही ते योग्य करत आहात. आपण एकत्रित केल्यास, हे कधीकधी क्षम्य असते.

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

उदाहरणार्थ, यासारखे. हे लगेच स्पष्ट आहे की सर्व काही एका विनंतीमध्ये केले जाऊ शकते. फक्त तेथे url आणि यादी लिहा.

अंतहीन लूपमधील अशा अनेक प्रश्न वाईट का आहेत? जर इंडेक्स वापरला नसेल, तर तुम्हाला त्याच डेटावर अनेक पास असतील. परंतु जर निर्देशांक वापरला असेल, उदाहरणार्थ, तुमच्याकडे ru साठी प्राथमिक की आहे आणि तुम्ही तेथे url = काहीतरी लिहा. आणि तुम्हाला वाटते की जर टेबलमधून फक्त एक URL वाचली गेली तर सर्वकाही ठीक होईल. पण प्रत्यक्षात नाही. कारण क्लिकहाऊस सर्व काही बॅचमध्ये करते.

जेव्हा त्याला विशिष्ट श्रेणीचा डेटा वाचण्याची आवश्यकता असते, तेव्हा तो थोडे अधिक वाचतो, कारण क्लिकहाऊसमधील निर्देशांक विरळ असतो. ही अनुक्रमणिका आपल्याला सारणीमध्ये एक वैयक्तिक पंक्ती शोधण्याची परवानगी देत ​​​​नाही, फक्त काही प्रकारची श्रेणी. आणि डेटा ब्लॉकमध्ये संकुचित केला जातो. एक ओळ वाचण्यासाठी, तुम्हाला संपूर्ण ब्लॉक घ्यावा लागेल आणि तो अनक्लेंच करावा लागेल. आणि जर तुम्ही अनेक प्रश्न करत असाल, तर तुमच्याकडे खूप ओव्हरलॅप असेल आणि तुम्हाला पुन्हा पुन्हा खूप काम करावे लागेल.

आणि बोनस म्हणून, तुम्ही लक्षात घेऊ शकता की क्लिकहाऊसमध्ये तुम्ही अगदी मेगाबाइट्स आणि अगदी शेकडो मेगाबाइट्स IN विभागात हस्तांतरित करण्यास घाबरू नका. मला आमच्या सरावातून आठवते की जर MySQL मध्ये आम्ही IN विभागात मूल्यांचा एक समूह हस्तांतरित करतो, उदाहरणार्थ, आम्ही तेथे काही संख्यांचे 100 मेगाबाइट्स हस्तांतरित करतो, तर MySQL 10 गीगाबाइट्स मेमरी खातो आणि इतर काहीही घडत नाही, सर्वकाही. खराब काम करते.

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

पण तरीही काही अडचणी आहेत. उदाहरणार्थ, सबक्वेरीसह IN निर्देशांक वापरत नाही हे तथ्य. पण ही आमची समस्या आहे आणि ती सोडवायला हवी. येथे मूलभूत काहीही नाही. आम्ही त्याचे निराकरण करू*.

आणि आणखी एक मनोरंजक गोष्ट अशी आहे की जर तुमच्याकडे खूप लांबची विनंती असेल आणि वितरित विनंतीची प्रक्रिया चालू असेल, तर ही खूप मोठी विनंती प्रत्येक सर्व्हरला कॉम्प्रेशनशिवाय पाठविली जाईल. उदाहरणार्थ, 100 मेगाबाइट्स आणि 500 ​​सर्व्हर. आणि, त्यानुसार, आपल्याकडे नेटवर्कवर 50 गीगाबाइट्स हस्तांतरित केले जातील. ते प्रसारित केले जाईल आणि नंतर सर्वकाही यशस्वीरित्या पूर्ण होईल.

* आधीच वापरत आहे; आश्वासनाप्रमाणे सर्व काही निश्चित झाले.

आणि जेव्हा API कडून विनंत्या येतात तेव्हा एक सामान्य केस असते. उदाहरणार्थ, तुम्ही तुमची स्वतःची सेवा तयार केली आहे. आणि जर एखाद्याला तुमच्या सेवेची गरज असेल, तर तुम्ही API उघडता आणि अक्षरशः दोन दिवसांनंतर तुम्हाला काहीतरी अनाकलनीय घडत असल्याचे दिसेल. सर्व काही ओव्हरलोड झाले आहे आणि काही भयानक विनंत्या येत आहेत ज्या कधीच घडल्या नसाव्यात.

आणि एकच उपाय आहे. जर तुम्ही API उघडले असेल तर तुम्हाला ते कापावे लागेल. उदाहरणार्थ, काही प्रकारचे कोटा सादर करा. इतर कोणतेही सामान्य पर्याय नाहीत. अन्यथा, ते ताबडतोब स्क्रिप्ट लिहितील आणि अडचणी येतील.

आणि क्लिकहाऊसमध्ये एक विशेष वैशिष्ट्य आहे - कोटा गणना. शिवाय, तुम्ही तुमची कोटा की हस्तांतरित करू शकता. हे, उदाहरणार्थ, अंतर्गत वापरकर्ता आयडी आहे. आणि त्या प्रत्येकासाठी कोटा स्वतंत्रपणे मोजला जाईल.

आता आणखी एक मनोरंजक गोष्ट. ही मॅन्युअल प्रतिकृती आहे.

मला अनेक प्रकरणे माहित आहेत जिथे क्लिकहाऊसमध्ये अंगभूत प्रतिकृती समर्थन असूनही, लोक क्लिकहाऊसची प्रतिकृती व्यक्तिचलितपणे तयार करतात.

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

आणि वेळोवेळी तुम्हाला अजूनही मॅन्युअली सिंक करावे लागेल. उदाहरणार्थ, महिन्यातून एकदा प्रशासक rsync करतात.

खरं तर, क्लिकहाऊसमध्ये तयार केलेली प्रतिकृती वापरणे खूप सोपे आहे. परंतु काही विरोधाभास असू शकतात, कारण यासाठी आपल्याला ZooKeeper वापरण्याची आवश्यकता आहे. मी ZooKeeper बद्दल काहीही वाईट म्हणणार नाही, तत्वतः, सिस्टम कार्य करते, परंतु असे होते की जावा-फोबियामुळे लोक ते वापरत नाहीत, कारण क्लिकहाऊस ही एक चांगली प्रणाली आहे, जी C++ मध्ये लिहिलेली आहे, जी तुम्ही वापरू शकता आणि सर्व काही ठीक होईल. आणि ZooKeeper जावा मध्ये आहे. आणि कसे तरी आपण पाहू इच्छित नाही, परंतु नंतर आपण मॅन्युअल प्रतिकृती वापरू शकता.

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

आपण आदिम टेबल इंजिन वापरल्यास पुढील समस्या उद्भवू शकतात. क्लिकहाऊस हा एक कन्स्ट्रक्टर आहे ज्यामध्ये वेगवेगळ्या टेबल इंजिनांचा समूह आहे. सर्व गंभीर प्रकरणांसाठी, दस्तऐवजीकरणात लिहिल्याप्रमाणे, MergeTree कुटुंबातील सारण्या वापरा. आणि बाकीचे सर्व - हे असे आहे, वैयक्तिक प्रकरणांसाठी किंवा चाचण्यांसाठी.

MergeTree टेबलमध्ये, तुमच्याकडे कोणतीही तारीख आणि वेळ असणे आवश्यक नाही. तुम्ही अजूनही ते वापरू शकता. तारीख आणि वेळ नसल्यास, डीफॉल्ट 2000 आहे असे लिहा. हे कार्य करेल आणि संसाधनांची आवश्यकता नाही.

आणि सर्व्हरच्या नवीन आवृत्तीमध्ये, तुम्ही हे देखील निर्दिष्ट करू शकता की तुमच्याकडे विभाजन कीशिवाय सानुकूल विभाजन आहे. तसेच असेल.

दुसरीकडे, आपण आदिम टेबल इंजिन वापरू शकता. उदाहरणार्थ, एकदा डेटा भरा आणि पहा, फिरवा आणि हटवा. आपण लॉग वापरू शकता.

किंवा इंटरमीडिएट प्रक्रियेसाठी लहान व्हॉल्यूम संचयित करणे म्हणजे StripeLog किंवा TinyLog.

डेटाचे प्रमाण कमी असल्यास मेमरी वापरली जाऊ शकते आणि आपण RAM मध्ये काहीतरी फिरवू शकता.

क्लिकहाऊसला पुनर्नवीनीकरण केलेला डेटा खरोखर आवडत नाही.

येथे एक नमुनेदार उदाहरण आहे. ही URL ची प्रचंड संख्या आहे. तुम्ही त्यांना पुढील टेबलमध्ये ठेवा. आणि मग त्यांनी त्यांच्यासोबत सामील होण्याचा निर्णय घेतला, परंतु हे नियमानुसार कार्य करणार नाही, कारण क्लिकहाऊस फक्त हॅश जॉइनला समर्थन देते. कनेक्ट करणे आवश्यक असलेल्या बर्याच डेटासाठी पुरेशी RAM नसल्यास, JOIN कार्य करणार नाही*.

जर डेटा उच्च कार्डिनॅलिटीचा असेल, तर काळजी करू नका, ते डिनोर्मलाइज्ड फॉर्ममध्ये साठवा, URL थेट मुख्य टेबलमध्ये आहेत.

* आणि आता ClickHouse मध्ये देखील एक मर्ज जॉईन आहे आणि ते अशा परिस्थितीत कार्य करते जेथे इंटरमीडिएट डेटा RAM मध्ये बसत नाही. परंतु हे कुचकामी आहे आणि शिफारस लागू राहते.

आणखी एक दोन उदाहरणे, परंतु मला आधीच शंका आहे की ते पॅटर्नविरोधी आहेत की नाही.

क्लिकहाऊसमध्ये एक ज्ञात दोष आहे. अपडेट कसे करायचे ते कळत नाही*. काही मार्गांनी, हे अगदी चांगले आहे. जर तुमच्याकडे काही महत्त्वाचा डेटा असेल, उदाहरणार्थ, अकाउंटिंग, तर कोणीही तो पाठवू शकणार नाही, कारण कोणतेही अपडेट नाहीत.

* बॅच मोडमध्ये अपडेट आणि डिलीटसाठी समर्थन खूप पूर्वी जोडले गेले आहे.

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

क्लिकहाऊसमध्ये वितरीत केलेले जॉइन देखील क्वेरी प्लॅनरद्वारे खराब हाताळले जातात.

वाईट, पण कधी कधी ठीक.

सिलेक्ट* वापरून डेटा परत वाचण्यासाठी फक्त क्लिकहाऊस वापरणे.

मी क्लिष्ट गणनेसाठी क्लिकहाऊस वापरण्याची शिफारस करणार नाही. परंतु हे पूर्णपणे सत्य नाही, कारण आम्ही आधीच या शिफारसीपासून दूर जात आहोत. आणि आम्ही अलीकडे ClickHouse - Catboost मध्ये मशीन लर्निंग मॉडेल लागू करण्याची क्षमता जोडली आहे. आणि हे मला त्रास देते कारण मला वाटते, “किती भयानक आहे. प्रति बाईट किती चक्रे निघतात ते असे! मला बाइट्सवर घड्याळे वाया घालवणे खरोखर आवडत नाही.

परंतु घाबरू नका, क्लिकहाऊस स्थापित करा, सर्व काही ठीक होईल. जर काही असेल तर आमचा एक समुदाय आहे. तसे, समुदाय आपण आहात. आणि तुम्हाला काही समस्या असल्यास, तुम्ही आमच्या चॅटवर किमान जाऊ शकता आणि आशा आहे की ते तुम्हाला मदत करतील.

प्रश्न

अहवालाबद्दल धन्यवाद! क्लिकहाऊस क्रॅश झाल्याबद्दल मी कुठे तक्रार करू शकतो?

तुम्ही आत्ता वैयक्तिकरित्या माझ्याकडे तक्रार करू शकता.

मी अलीकडे क्लिकहाऊस वापरण्यास सुरुवात केली. मी लगेच cli इंटरफेस टाकला.

काय स्कोअर.

थोड्या वेळाने मी एका लहान निवडीने सर्व्हर क्रॅश केला.

तुमच्यात प्रतिभा आहे.

मी एक GitHub बग उघडला, परंतु त्याकडे दुर्लक्ष केले गेले.

आपण बघू.

अलेक्सीने मला अहवालात सहभागी होण्यासाठी फसवले, तुम्ही आत डेटा कसा ऍक्सेस करता ते मला सांगण्याचे वचन दिले.

अगदी साधे.

हे मला काल कळले. अधिक तपशील.

तेथे कोणत्याही भयानक युक्त्या नाहीत. फक्त ब्लॉक-बाय-ब्लॉक कॉम्प्रेशन आहे. डीफॉल्ट LZ4 आहे, तुम्ही ZSTD* सक्षम करू शकता. 64 किलोबाइट ते 1 मेगाबाइट पर्यंत ब्लॉक.

* विशेष कॉम्प्रेशन कोडेक्ससाठी समर्थन देखील आहे जे इतर अल्गोरिदमसह साखळीमध्ये वापरले जाऊ शकतात.

ब्लॉक्स फक्त कच्चा डेटा आहे का?

पूर्णपणे कच्चा नाही. अॅरे आहेत. जर तुमच्याकडे अंकीय स्तंभ असेल, तर एका ओळीतील संख्या अॅरेमध्ये ठेवल्या जातात.

हे स्पष्ट आहे.

अॅलेक्सी, एक उदाहरण जे IPs वर UniqExact सह होते, म्हणजे uniqExact ला संख्यांपेक्षा रेषेनुसार गणना करण्यास जास्त वेळ लागतो, इ. प्रूफरीडिंगच्या वेळी आपण कान आणि कास्ट वापरल्यास काय होईल? म्हणजेच, आपण असे म्हटले आहे की आमच्या डिस्कवर ते फार वेगळे नाही. जर आपण डिस्क आणि कास्ट मधील ओळी वाचल्या तर आमची समुच्चय वेगवान होईल की नाही? की इथे अजून थोडा फायदा होईल? मला असे वाटते की आपण याची चाचणी केली आहे, परंतु काही कारणास्तव ते बेंचमार्कमध्ये सूचित केले नाही.

मला वाटते की ते कास्ट न करता धीमे असेल. या प्रकरणात, IP पत्ता स्ट्रिंगमधून विश्लेषित करणे आवश्यक आहे. अर्थात, क्लिकहाऊसवर, आमचे आयपी अॅड्रेस पार्सिंग देखील ऑप्टिमाइझ केले आहे. आम्ही खूप प्रयत्न केला, पण तिथे तुम्ही दहा हजारव्या फॉर्ममध्ये अंक लिहिले आहेत. खूप अस्वस्थ. दुसरीकडे, uniqExact फंक्शन स्ट्रिंग्सवर हळू काम करेल, केवळ या स्ट्रिंग्स आहेत म्हणून नाही तर अल्गोरिदमचे वेगळे स्पेशलायझेशन निवडल्यामुळे देखील. स्ट्रिंग्सवर फक्त वेगळ्या पद्धतीने प्रक्रिया केली जाते.

जर आपण अधिक आदिम डेटा प्रकार घेतला तर? उदाहरणार्थ, आमच्याकडे असलेला युजर आयडी आम्ही खाली लिहिला, तो ओळ म्हणून लिहिला आणि नंतर तो स्क्रॅम्बल केला, ते अधिक मजेदार असेल की नाही?

मला शंका आहे. मला वाटते की हे आणखी दुःखदायक असेल, कारण शेवटी, संख्या पार्स करणे ही एक गंभीर समस्या आहे. मला असे वाटते की या सहकाऱ्याने दहा हजारव्या फॉर्ममध्ये संख्यांचे विश्लेषण करणे किती कठीण आहे याचा अहवाल देखील दिला आहे, परंतु कदाचित नाही.

अलेक्सी, अहवालासाठी खूप खूप धन्यवाद! आणि क्लिकहाऊससाठी खूप खूप धन्यवाद! मला योजनांबद्दल एक प्रश्न आहे. शब्दकोश अपूर्णपणे अद्यतनित करण्यासाठी वैशिष्ट्यासाठी काही योजना आहेत का?

म्हणजे, आंशिक रीबूट?

होय होय. तेथे MySQL फील्ड सेट करण्याच्या क्षमतेप्रमाणे, म्हणजे नंतर अपडेट करा जेणेकरून शब्दकोश खूप मोठा असेल तरच हा डेटा लोड केला जाईल.

एक अतिशय मनोरंजक वैशिष्ट्य. आणि मला वाटते की आमच्या चॅटमध्ये कोणीतरी ते सुचवले आहे. कदाचित ते तुम्ही देखील असाल.

मला नाही वाटत.

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

होय, परंतु, दुर्दैवाने, C++ मध्ये नाही.

तुमच्या सहकाऱ्यांना C++ मध्ये कसे लिहायचे हे माहित आहे का?

मी कोणीतरी शोधून काढेन.

छान*.

* अहवालानंतर दोन महिन्यांनी वैशिष्ट्य जोडले गेले - प्रश्नाच्या लेखकाने ते विकसित केले आणि पाठवले पुल विनंती.

धन्यवाद!

नमस्कार! अहवालाबद्दल धन्यवाद! तुम्ही नमूद केले आहे की क्लिकहाऊस त्याच्याकडे उपलब्ध असलेल्या सर्व संसाधनांचा वापर करण्यासाठी खूप चांगले आहे. आणि लक्सॉफ्टच्या पुढे असलेल्या स्पीकरने रशियन पोस्टसाठी त्याच्या समाधानाबद्दल बोलले. ते म्हणाले की त्यांना क्लिकहाऊस खरोखरच आवडले, परंतु त्यांनी ते त्यांच्या मुख्य स्पर्धकाऐवजी वापरले नाही कारण ते सर्व CPU खात होते. आणि ते ते त्यांच्या आर्किटेक्चरमध्ये, त्यांच्या ZooKeeper मध्ये डॉकर्ससह प्लग करू शकले नाहीत. क्लिकहाऊसला कसे तरी मर्यादित करणे शक्य आहे जेणेकरुन ते त्याच्यासाठी उपलब्ध असलेल्या सर्व गोष्टींचा वापर करू नये?

होय, हे शक्य आहे आणि खूप सोपे आहे. जर तुम्हाला कमी कोर वापरायचे असतील तर फक्त लिहा set max_threads = 1. आणि तेच आहे, ते विनंती एका कोरमध्ये कार्यान्वित करेल. शिवाय, आपण वेगवेगळ्या वापरकर्त्यांसाठी भिन्न सेटिंग्ज निर्दिष्ट करू शकता. त्यामुळे हरकत नाही. आणि Luxoft मधील तुमच्या सहकाऱ्यांना सांगा की त्यांना ही सेटिंग डॉक्युमेंटेशनमध्ये सापडली नाही हे चांगले नाही.

अलेक्सी, हॅलो! मला या प्रश्नाबद्दल विचारायचे आहे. अनेक लोक लॉगसाठी स्टोरेज म्हणून क्लिकहाऊस वापरण्यास सुरुवात करत आहेत हे मी पहिल्यांदाच ऐकले नाही. अहवालात तुम्ही हे करू नका असे सांगितले आहे, म्हणजे तुम्हाला लांब तार साठवण्याची गरज नाही. तुला या बद्दल काय वाटते?

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

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

एक किलोबाइट सामान्य आहे का?

ठीक आहे.

नमस्कार! अहवालाबद्दल धन्यवाद! मी चॅटमध्ये याबद्दल आधीच विचारले आहे, परंतु मला उत्तर मिळाले की नाही ते आठवत नाही. CTE च्या पद्धतीने WITH विभागाचा विस्तार करण्याची योजना आहे का?

अजून नाही. आमचा विथ विभाग काहीसा फालतू आहे. हे आमच्यासाठी एक लहान वैशिष्ट्य आहे.

मला समजते. धन्यवाद!

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

अपरिहार्यपणे. आमच्या रांगेतील हे आमचे पहिले काम आहे. आम्ही आता सर्वकाही योग्यरित्या कसे करावे याबद्दल सक्रियपणे विचार करत आहोत. आणि तुम्ही कीबोर्ड* दाबायला सुरुवात करावी.

* कीबोर्डवरील बटणे दाबली आणि सर्वकाही केले.

याचा प्रणालीच्या कार्यक्षमतेवर कसा तरी परिणाम होईल की नाही? आता जितका वेग आहे तितका प्रवेश होईल का?

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

आणि अजून एक छोटा प्रश्न. सादरीकरणात तुम्ही प्राथमिक की बद्दल बोललात. त्यानुसार, आमच्याकडे विभाजन आहे, जे डीफॉल्टनुसार मासिक आहे, बरोबर? आणि जेव्हा आपण महिन्यामध्ये बसणारी तारीख श्रेणी सेट करतो, तेव्हा फक्त हे विभाजन वाचले जाते, बरोबर?

होय

प्रश्न. जर आपण कोणतीही प्राथमिक की निवडू शकत नसाल, तर ती विशेषतः “तारीख” फील्डनुसार करणे योग्य आहे जेणेकरुन पार्श्वभूमीमध्ये या डेटाची कमी पुनर्रचना होईल जेणेकरून ते अधिक व्यवस्थितपणे बसेल? तुमच्याकडे रेंज क्वेरी नसल्यास आणि तुम्ही कोणतीही प्राथमिक की निवडू शकत नसल्यास, प्राथमिक कीमध्ये तारीख टाकणे योग्य आहे का?

होय

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

ठीक आहे, खूप खूप धन्यवाद!

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