MySQL और MariaDB के साथ बड़े डेटा वॉल्यूम को संभालना

अधिकांश डेटाबेस समय के साथ आकार में बढ़ते हैं। डेटाबेस के प्रदर्शन को प्रभावित करने के लिए विकास हमेशा पर्याप्त तेज़ नहीं होता है, लेकिन निश्चित रूप से ऐसे मामले होते हैं जहां ऐसा होता है। जब ऐसा होता है, तो हम अक्सर आश्चर्य करते हैं कि उस प्रभाव को कम करने के लिए क्या किया जा सकता है और बड़े पैमाने पर डेटा से निपटने के दौरान हम सुचारू डेटाबेस संचालन कैसे सुनिश्चित कर सकते हैं।

सबसे पहले, आइए यह परिभाषित करने का प्रयास करें कि "बड़े डेटा वॉल्यूम" का क्या अर्थ है? MySQL या MariaDB के लिए यह InnoDB असम्पीडित है। InnoDB इस तरह से काम करता है कि यह उपलब्ध मेमोरी से दृढ़ता से लाभान्वित होता है - मुख्य रूप से InnoDB बफर पूल। जब तक डेटा वहां फिट बैठता है, तब तक डिस्क एक्सेस को केवल लिखने के लिए कम से कम किया जाता है - मेमोरी से रीड की सेवा की जाती है। क्या होता है जब डेटा मेमोरी को बढ़ा देता है? पंक्तियों तक पहुँचने की आवश्यकता होने पर डिस्क से अधिक से अधिक डेटा को पढ़ना पड़ता है, जो वर्तमान में कैश्ड नहीं हैं। जब डेटा की मात्रा बढ़ जाती है, तो वर्कलोड CPU-बाउंड से I/O-बाउंड की ओर स्विच हो जाता है। इसका मतलब है कि अड़चन अब सीपीयू नहीं है (जो तब होता था जब डेटा मेमोरी में फिट होता था - मेमोरी में डेटा एक्सेस तेज होता है, डेटा ट्रांसफॉर्मेशन और एग्रीगेशन धीमा होता है) बल्कि यह आई / ओ सबसिस्टम है (डेटा पर सीपीयू ऑपरेशन रास्ता है डिस्क से डेटा एक्सेस करने की तुलना में तेज़।) फ्लैश को अपनाने के साथ, I/O बाउंड वर्कलोड उतना भयानक नहीं है जितना कि वे कताई ड्राइव के समय हुआ करते थे (SSD के साथ रैंडम एक्सेस बहुत तेज है) लेकिन प्रदर्शन हिट अभी भी है ।

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

आइए इस ब्लॉग के उद्देश्य के लिए मान लें, और यह एक वैज्ञानिक परिभाषा नहीं है, कि बड़े डेटा वॉल्यूम से हमारा मतलब ऐसे मामले से है जहां सक्रिय डेटा का आकार मेमोरी के आकार को काफी बढ़ा देता है। यह 100GB हो सकता है जब आपके पास 2GB मेमोरी हो, यह 20TB हो सकता है जब आपके पास 200GB मेमोरी हो। टिपिंग बिंदु यह है कि आपका कार्यभार सख्ती से I/O बाध्य है। जब हम MySQL और MariaDB के लिए उपलब्ध कुछ विकल्पों पर चर्चा करते हैं तो हमारे साथ रहें।

विभाजन

बड़ी मात्रा में डेटा को संभालने के लिए ऐतिहासिक (लेकिन पूरी तरह मान्य) दृष्टिकोण विभाजन को लागू करना है। इसके पीछे का विचार तालिका को विभाजन में विभाजित करना है, एक उप-सारणी की तरह। विभाजन उपयोगकर्ता द्वारा परिभाषित नियमों के अनुसार होता है। आइए कुछ उदाहरणों पर एक नज़र डालें (SQL उदाहरण MySQL 8.0 दस्तावेज़ से लिए गए हैं)

MySQL 8.0 निम्न प्रकार के विभाजन के साथ आता है:

• रेंज
• सूची
• कॉलम
• हैश
• कुंजी

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

HASH विभाजन के लिए उपयोगकर्ता को एक कॉलम परिभाषित करने की आवश्यकता होती है, जिसे हैश किया जाएगा। फिर, डेटा को उस हैश मान के आधार पर उपयोगकर्ता द्वारा परिभाषित विभाजनों की संख्या में विभाजित किया जाएगा:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH( YEAR(hired) )
PARTITIONS 4;

इस मामले में 'किराए पर' कॉलम पर YEAR() फ़ंक्शन द्वारा उत्पन्न परिणाम के आधार पर हैश बनाया जाएगा।

कुंजी विभाजन अपवाद के समान है कि उपयोगकर्ता परिभाषित करता है कि कौन सा कॉलम हैश किया जाना चाहिए और बाकी को संभालने के लिए MySQL पर निर्भर है।

जबकि HASH और KEY विभाजन बेतरतीब ढंग से विभाजन की संख्या में डेटा वितरित करते हैं, RANGE और LIST उपयोगकर्ता को यह तय करने देते हैं कि क्या करना है। RANGE आमतौर पर समय या तारीख के साथ प्रयोग किया जाता है:

CREATE TABLE quarterly_report_status (
    report_id INT NOT NULL,
    report_status VARCHAR(20) NOT NULL,
    report_updated TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
PARTITION BY RANGE ( UNIX_TIMESTAMP(report_updated) ) (
    PARTITION p0 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-01-01 00:00:00') ),
    PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-04-01 00:00:00') ),
    PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-07-01 00:00:00') ),
    PARTITION p3 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-10-01 00:00:00') ),
    PARTITION p4 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-01-01 00:00:00') ),
    PARTITION p5 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-04-01 00:00:00') ),
    PARTITION p6 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-07-01 00:00:00') ),
    PARTITION p7 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-10-01 00:00:00') ),
    PARTITION p8 VALUES LESS THAN ( UNIX_TIMESTAMP('2010-01-01 00:00:00') ),
    PARTITION p9 VALUES LESS THAN (MAXVALUE)
);

इसका उपयोग अन्य प्रकार के स्तंभों के साथ भी किया जा सकता है:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

LIST विभाजन उन मानों की सूची के आधार पर काम करते हैं जो पंक्तियों को कई विभाजनों में क्रमबद्ध करते हैं:

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY LIST(store_id) (
    PARTITION pNorth VALUES IN (3,5,6,9,17),
    PARTITION pEast VALUES IN (1,2,10,11,19,20),
    PARTITION pWest VALUES IN (4,12,13,14,18),
    PARTITION pCentral VALUES IN (7,8,15,16)
);

आप पूछ सकते हैं कि विभाजन का उपयोग करने का क्या मतलब है? मुख्य बिंदु यह है कि गैर-विभाजित तालिका की तुलना में लुकअप काफी तेज है। मान लीजिए कि आप उन पंक्तियों को खोजना चाहते हैं जो किसी दिए गए महीने में बनाई गई थीं। यदि आपके पास तालिका में संग्रहीत कई वर्षों का डेटा है, तो यह एक चुनौती होगी - एक इंडेक्स का उपयोग करना होगा और, जैसा कि हम जानते हैं, इंडेक्स पंक्तियों को खोजने में मदद करते हैं लेकिन उन पंक्तियों तक पहुंचने के परिणामस्वरूप यादृच्छिक रीड का एक गुच्छा होगा पूरी मेज। यदि आपके पास वर्ष-महीने के आधार पर विभाजन बनाए गए हैं, तो MySQL केवल उस विशेष विभाजन से सभी पंक्तियों को पढ़ सकता है - अनुक्रमणिका तक पहुँचने की कोई आवश्यकता नहीं है, यादृच्छिक पढ़ने की कोई आवश्यकता नहीं है:बस विभाजन से सभी डेटा को क्रमिक रूप से पढ़ें, और हम हैं पूरी तरह तैयार।

डेटा रोटेशन से निपटने में विभाजन भी बहुत उपयोगी होते हैं। यदि MySQL आसानी से हटाने के लिए पंक्तियों की पहचान कर सकता है और उन्हें एकल विभाजन में मैप कर सकता है, तो तालिका से DELETE WHERE … चलाने के बजाय, जो पंक्तियों का पता लगाने के लिए अनुक्रमणिका का उपयोग करेगा, आप विभाजन को छोटा कर सकते हैं। यह RANGE विभाजन के साथ अत्यंत उपयोगी है - ऊपर के उदाहरण से चिपके हुए, यदि हम केवल 2 वर्षों के लिए डेटा रखना चाहते हैं, तो हम आसानी से एक क्रॉन जॉब बना सकते हैं, जो पुराने विभाजन को हटा देगा और अगले महीने के लिए एक नया, खाली बना देगा।

InnoDB संपीड़न

यदि हमारे पास बड़ी मात्रा में डेटा है (जरूरी नहीं कि डेटाबेस के बारे में सोच रहे हों), तो हमारे दिमाग में पहली बात यह आती है कि इसे संपीड़ित किया जाए। ऐसे कई टूल हैं जो आपकी फ़ाइलों को संपीड़ित करने का विकल्प प्रदान करते हैं, उनके आकार को महत्वपूर्ण रूप से कम करते हैं। InnoDB के पास इसके लिए एक विकल्प भी है - MySQL और MariaDB दोनों InnoDB संपीड़न का समर्थन करते हैं। संपीड़न का उपयोग करने का मुख्य लाभ I/O गतिविधि में कमी है। डेटा, जब संपीड़ित होता है, तो छोटा होता है इसलिए इसे पढ़ने और लिखने में तेज़ होता है। विशिष्ट InnoDB पृष्ठ आकार में 16KB है, SSD के लिए यह पढ़ने या लिखने के लिए 4 I/O संचालन है (SSD आमतौर पर 4KB पृष्ठों का उपयोग करता है)। यदि हम 16KB को 4KB में संपीड़ित करने का प्रबंधन करते हैं, तो हमने I/O संचालन को चार से कम कर दिया है। यह वास्तव में डेटासेट से मेमोरी अनुपात के संबंध में बहुत मदद नहीं करता है। असल में, यह इसे और भी खराब कर सकता है - डेटा पर काम करने के लिए MySQL को पेज को डीकंप्रेस करना पड़ता है। फिर भी यह डिस्क से कंप्रेस्ड पेज को पढ़ता है। इसके परिणामस्वरूप InnoDB बफर पूल 4KB संपीड़ित डेटा और 16KB असंपीड़ित डेटा संग्रहीत करता है। बेशक, अनावश्यक डेटा को हटाने के लिए एल्गोरिदम मौजूद हैं (जब संभव हो तो असम्पीडित पृष्ठ को हटा दिया जाएगा, केवल एक को मेमोरी में संपीड़ित करके) लेकिन आप इस क्षेत्र में बहुत अधिक सुधार की उम्मीद नहीं कर सकते।

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

दुर्भाग्य से, भले ही संपीड़न मदद करता है, बड़ी मात्रा में डेटा के लिए यह अभी भी पर्याप्त नहीं हो सकता है। InnoDB के अलावा किसी और चीज़ की तलाश करना एक और कदम होगा।

माईरॉक्स

MyRocks एक स्टोरेज इंजन है जो MySQL और MariaDB के लिए उपलब्ध है जो InnoDB की तुलना में एक अलग अवधारणा पर आधारित है। मेरे सहयोगी, सेबस्टियन इंसॉस्टी के पास मारियाडीबी के साथ मायरॉक्स का उपयोग करने के बारे में एक अच्छा ब्लॉग है। सार यह है, इसके डिजाइन के कारण (यह लॉग स्ट्रक्चर्ड मर्ज, एलएसएम का उपयोग करता है), MyRocks संपीड़न के मामले में InnoDB (जो B + ट्री संरचना पर आधारित है) की तुलना में काफी बेहतर है। MyRocks को बड़ी मात्रा में डेटा को संभालने और लिखने की संख्या को कम करने के लिए डिज़ाइन किया गया है। इसकी उत्पत्ति फेसबुक से हुई है, जहां डेटा की मात्रा बड़ी है और डेटा तक पहुंचने की आवश्यकताएं अधिक हैं। इस प्रकार एसएसडी भंडारण - फिर भी, इतने बड़े पैमाने पर संपीड़न में हर लाभ बहुत बड़ा है। MyRocks InnoDB की तुलना में 2x तक बेहतर संपीड़न प्रदान कर सकता है (जिसका अर्थ है कि आपने सर्वरों की संख्या में दो की कटौती की है)। इसे लेखन प्रवर्धन को कम करने के लिए भी डिज़ाइन किया गया है (पंक्ति सामग्री के परिवर्तन को संभालने के लिए आवश्यक लेखन की संख्या) - इसके लिए InnoDB की तुलना में 10x कम लिखने की आवश्यकता होती है। यह, जाहिर है, I/O लोड को कम करता है, लेकिन इससे भी महत्वपूर्ण बात यह है कि यह एक SSD के जीवनकाल को InnoDB का उपयोग करके समान लोड को सौंपने की तुलना में दस गुना बढ़ा देगा)। एक प्रदर्शन के दृष्टिकोण से, डेटा की मात्रा जितनी कम होगी, उतनी ही तेजी से इस तरह के स्टोरेज इंजन तक पहुंच डेटा को तेजी से डेटाबेस से बाहर निकालने में मदद कर सकती है (भले ही MyRocks को डिजाइन करते समय यह सर्वोच्च प्राथमिकता नहीं थी)।

कॉलमनार डेटास्टोर

किसी बिंदु पर हम केवल यह स्वीकार कर सकते हैं कि हम MySQL का उपयोग करके डेटा की इतनी मात्रा को संभाल नहीं सकते हैं। ज़रूर, आप इसे शार्प कर सकते हैं, आप अलग-अलग काम कर सकते हैं लेकिन अंततः इसका कोई मतलब नहीं है। अतिरिक्त समाधान खोजने का समय आ गया है। उनमें से एक कॉलमर डेटास्टोर्स - डेटाबेस का उपयोग करना होगा, जिन्हें बड़े डेटा एनालिटिक्स को ध्यान में रखकर बनाया गया है। निश्चित रूप से, वे OLTP प्रकार के ट्रैफ़िक के साथ मदद नहीं करेंगे, लेकिन आजकल एनालिटिक्स बहुत मानक हैं क्योंकि कंपनियां डेटा-चालित होने की कोशिश करती हैं और सटीक संख्याओं के आधार पर निर्णय लेती हैं, न कि यादृच्छिक डेटा। कई कॉलमर डेटास्टोर हैं लेकिन हम यहां उनमें से दो का उल्लेख करना चाहेंगे। मारियाडीबी एएक्स और क्लिकहाउस। हमारे पास कुछ ब्लॉग हैं जो बताते हैं कि MariaDB AX क्या है और MariaDB AX का उपयोग कैसे किया जा सकता है। क्या महत्वपूर्ण है, मारियाडीबी एएक्स को एक क्लस्टर के रूप में बढ़ाया जा सकता है, जिससे प्रदर्शन में सुधार होता है। क्लिकहाउस एनालिटिक्स चलाने के लिए एक और विकल्प है - MySQL से डेटा को दोहराने के लिए क्लिकहाउस को आसानी से कॉन्फ़िगर किया जा सकता है, जैसा कि हमने अपने एक ब्लॉग पोस्ट में चर्चा की थी। यह तेज़ है, यह मुफ़्त है और इसका उपयोग क्लस्टर बनाने और बेहतर प्रदर्शन के लिए डेटा को शार्प करने के लिए भी किया जा सकता है।

निष्कर्ष

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