कौन सा डेटाबेस अरबों / खरबों के रिकॉर्ड के भंडारण को संभाल सकता है?

Question

हम नेटफ्लो डेटा को पकड़ने और विश्लेषण करने के लिए एक टूल विकसित कर रहे हैं, जिसमें से हम जबरदस्त मात्रा में इकट्ठा होते हैं। हर दिन हम ~ 1.4 बिलियन प्रवाह रिकॉर्ड पर कब्जा कर लेते हैं, जो कि इस प्रकार के रूप में दिखाई देगा:

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

हम डेटा सेट पर तेजी से खोजों (10 सेकंड से कम) करने में सक्षम होना चाहते हैं, समय की संकीर्ण स्लाइस (10 - 30 मिनट अंतराल) पर सबसे अधिक संभावना है। हम अधिकांश डेटा बिंदुओं को अनुक्रमित करना चाहते हैं ताकि हम उनमें से प्रत्येक पर जल्दी से खोज कर सकें। जब खोज निष्पादित की जाती हैं तो हम डेटा को अद्यतित करना भी चाहेंगे। खुले स्रोत की दुनिया में रहना बहुत अच्छा होगा, लेकिन हम इस परियोजना के लिए मालिकाना समाधान देखने के विरोध में नहीं हैं।

यह विचार लगभग एक महीने का डेटा रखने का है, जो ~ 43.2 बिलियन रिकॉर्ड होगा। एक मोटा अनुमान है कि प्रत्येक रिकॉर्ड में लगभग 480 बाइट्स डेटा होंगे, जो एक महीने में ~ 18.7 टेराबाइट्स डेटा के बराबर होगा, और शायद तीन बार अनुक्रमित के साथ। आखिरकार हम इस प्रणाली की क्षमता को अरबों-खरबों की संख्या में विकसित करना चाहेंगे।

हमारे पास इस परियोजना के लिए अभी तक संभावित उम्मीदवारों के रूप में काउचबेस, कैसंड्रा, और मोंगोडब का मूल्यांकन किया गया है, हालांकि प्रत्येक ने अपनी चुनौतियों का प्रस्ताव किया है। Couchbase के साथ अनुक्रमण अंतराल पर किया जाता है और डेटा के सम्मिलन के दौरान नहीं होता है, इसलिए दृश्य अद्यतित नहीं होते हैं, कैसेंड्रा के द्वितीयक अनुक्रमणिका परिणाम वापस करने में बहुत कुशल नहीं होते हैं क्योंकि उन्हें आमतौर पर परिणामों के लिए संपूर्ण क्लस्टर को स्कैन करने की आवश्यकता होती है, और मोंगोडब दिखते हैं लेकिन यह मास्टर / स्लेव / शार्ल्ड होने के साथ-साथ स्केल करना अधिक कठिन प्रतीत होता है। हमारे द्वारा मूल्यांकन किए जाने वाले कुछ अन्य उम्मीदवारों में इलास्टिक्स खोज, mysql (निश्चित रूप से यदि यह भी लागू है तो निश्चित नहीं है), और कुछ कॉलम उन्मुख रिलेशनल डेटाबेस हैं। किसी भी सुझाव या वास्तविक दुनिया के अनुभव की सराहना की जाएगी।

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— पॉल व्हाइट

Answer 1

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

सिद्धांत

• अपना डेटा साझा करें। ऐसा कोई तरीका नहीं है कि एक एकल सर्वर मज़बूती से और वास्तविक रूप से डेटा की ऐसी मात्रा को पकड़ सके।
• हार्डवेयर दोष और पूरे नोड विफलताओं के लिए तैयार रहें, डेटा की नकल करें।
• शुरुआत से कई बैक-एंड सर्वर का उपयोग करना शुरू करें।
• टॉप-एंड हाई परफॉर्मेंस वाले की तुलना में कई सस्ते कमोडिटी सर्वर का उपयोग करें।
• सुनिश्चित करें कि डेटा समान रूप से शार्क के बीच वितरित किया गया है।
• अपने प्रश्नों की योजना बनाने में बहुत समय व्यतीत करें। प्रश्नों से एपीआई एपीआई और फिर ध्यान से टेबल डिजाइन करें। यह सबसे महत्वपूर्ण और लम्बा कार्य है।
• कैसंड्रा में, आप एक समग्र स्तंभ कुंजी डिज़ाइन कर सकते हैं और ओ (1) में उस कुंजी तक पहुंच प्राप्त कर सकते हैं। उन पर काम करते हुए समय बिताएं। इसका उपयोग सेकेंडरी इंडेक्स के बजाय खोज योग्य रिकॉर्ड तक पहुंचने के लिए किया जाएगा।
• चौड़ी पंक्तियों का उपयोग करें। वे समय-मुद्रांकित घटनाओं के भंडारण के लिए उपयोगी हैं।
• कभी भी फुल-स्कैन या वास्तव में ऐसी मात्रा पर O (Log N) से अधिक कोई ऑपरेशन नहीं करें। यदि आपको O (लॉग एन) से अधिक कुछ चाहिए, तो इस तरह के ऑपरेशन को मैप-कम एल्गोरिदम पर लोड करें।

अभ्यास

• ओएस चित्र बनाने या भौतिक मशीनों पर सर्वर स्थापित करने में समय खर्च न करें। त्वरित प्रोटोटाइप के लिए क्लाउड आधारित प्रदाताओं का उपयोग करें। मैंने Amazon EC2 के साथ काम किया और इसकी सादगी, विश्वसनीयता और प्रोटोटाइप की गति के लिए अत्यधिक अनुशंसा कर सकता हूं।
• विंडोज मशीन बूट समय के दौरान धीमी हो जाती हैं और आइडल राज्य में होने वाले संसाधनों को काफी अधिक लेती हैं। यूनिक्स-आधारित ओएस का उपयोग करने पर विचार करें। निजी तौर पर, मुझे उबंटू सर्वर एक विश्वसनीय ओएस लगता है, लेकिन इसके अलावा आस्कुबंटु में एक बहुत अच्छा समुदाय है
• नेटवर्किंग के बारे में सोचें, तेज गपशप और मेटा-डेटा एक्सचेंज की अनुमति देने के लिए नोड्स आदर्श रूप से एक-दूसरे के करीब होंगे।
• चरम मामलों में न जाएं: वास्तव में विस्तृत स्तंभ पंक्तियाँ या असाधारण रूप से लंबे स्तंभ परिवार (टेबल)। सर्वश्रेष्ठ प्रदर्शनों को सीमा सीमाओं में प्राप्त किया जाता है - अगर DB डिजाइन द्वारा कई एन पंक्तियों का समर्थन करता है , तो इसका मतलब यह नहीं है कि यह अच्छा प्रदर्शन करता है।
• हमारी खोज में लगभग 3-5 सेकंड लगते हैं, बहुत कुछ यूआई और डेटाबेस के बीच मध्यवर्ती नोड्स के कारण होता है। डेटाबेस के करीब अनुरोध लाने के बारे में विचार करें।
• एक नेटवर्क लोड बैलेंसर का उपयोग करें। एक स्थापित चुनें। हम HAProxy का उपयोग करते हैं, जो सरल है, लेकिन मृत तेज है। इसके साथ कभी कोई समस्या नहीं थी।
• जटिल समाधानों के लिए सादगी को प्राथमिकता दें।
• जब तक आप निगम के आकार के बजट का समर्थन नहीं करते हैं, तब तक मुक्त स्रोत के समाधान देखें। एक बार जब आप कई सर्वरों से अधिक हो जाते हैं, तो बुनियादी ढांचे की लागत अधिक हो सकती है।

मैं अमेज़ॅन के लिए काम नहीं करता हूं और HAProxy और Ubuntu टीमों के साथ कोई संबंध नहीं है। यह किसी भी प्रकार के प्रचार के बजाय एक व्यक्तिगत राय है।

Comments

मुझे पूरा यकीन है कि एक ओ (1) खोज अत्यंत तुच्छ / बेकार मामलों से अलग है।

— फिजिट्समोन

कृपया कोई अपराध न करें, लेकिन Google को बताएं। सावधान डिजाइन के तहत पीबी पैमाने पर ओ (1) खोज संभव है।

— ओलेक्सी

@oleksii बिलियन डॉलर Google बजट आकर्षित करने के लिए एक उचित तुलना नहीं है।

— मार्क स्टोरी-स्मिथ

मैं 3 पिछली टिप्पणियोंO(1) search <=> unbounded storage space <=> unlimited supply of cash

— ypercube

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

— कंसर्नडऑफटुनब्रिजवेल्स

Answer 2

यदि मैं इसे SQL सर्वर में डालने जा रहा हूं, तो मैं एक तालिका का सुझाव दूंगा:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

यह एकल तालिका के लिए कुल अनुमानित भंडारण आवश्यकता में परिणाम करता है, जिसमें 43.2 बीलियन रिकॉर्ड (आपकी निर्दिष्ट आवश्यकता) के लिए 5.5 टीबी का कोई और सूचकांक नहीं है। यह डेटा के लिए 130 बाइट्स के रूप में गणना की जाती है, ओवरहेड की पंक्ति प्रति 7 बाइट्स, और ओवरहेड के प्रति पेज 96 बाइट्स। SQL सर्वर 8KB पृष्ठों में डेटा संग्रहीत करता है, प्रति पृष्ठ 59 पंक्तियों के लिए अनुमति देता है। यह डेटा के एक महीने के लिए 732,203,390 पृष्ठों के बराबर है।

SQL सर्वर 8-पृष्ठ विखंडू (64KB) में डिस्क को लिखना पसंद करता है, जो कि I / O प्रति 472 पंक्तियों के बराबर है। प्रत्येक सेकंड में 16,203 प्रवाह रिकॉर्ड बनाए जाने के साथ, आपको 34 IOps की न्यूनतम I / O दर की आवश्यकता होगी, प्रत्येक और हर सेकंड की गारंटी। यद्यपि यह अपने आप में एक बड़ी राशि नहीं है, लेकिन सिस्टम में अन्य I / O (SQL Server और अन्यथा) को IOps की इस आवश्यक दर पर उल्लंघन करने की आवश्यकता नहीं है। इसलिए आपको कम से कम एक ऑर्डर-ऑफ-परिमाण अधिक IOps, या 340 निरंतर IOps के लिए सक्षम प्रणाली डिज़ाइन करने की आवश्यकता होगी - मुझे यह अनुमान लगाना होगा कि आपको थ्रूपुट की गारंटी के लिए परिमाण के 2 ऑर्डर अधिक टिकाऊ IOps की आवश्यकता है।

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

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

Comments

मैं शायद binary(4)या binary(16)क्रमशः उपयोग करेगा । 1,000,000 लाख से गुणा करने पर 4 बाइट्स / पंक्ति बहुत सारे स्टोरेज में जुड़ जाती है।

— जॉन सीगल

और पोर्ट नंबरों की 0-65535 रेंज है, इसलिए आप इसका उपयोग कर सकते हैं SMALLINTलेकिन वहां भी एक रूपांतरण रूटीन होना चाहिए।

— ypercube y

@MrTelly मैं असहमत हूं। यह SQL सर्वर में करने के लिए महंगा है अगर आप हा या बड़ा विफलता सामान की जरूरत है। एक ठोस डेटा स्टोर के लिए, जो वास्तव में साथ रहना आसान है, SQL सर्वर इसके लिए बहुत अच्छा है। यदि एचए की जरूरत है तो सभी सिस्टम बहुत महंगे (और जटिल) हो जाते हैं।

— संस्मिथ

IMO, SQL सर्वर निश्चित रूप से डेटा को स्टोर कर सकता है ; मैं अभी भी अनिश्चित हूँ अगर यह परियोजना के विश्लेषिकी भाग को हल करने के लिए सही समाधान है , ज्यादातर इसलिए क्योंकि मैं अन्य प्रणालियों के साथ पर्याप्त रूप से परिचित नहीं हूं।

— जॉन सीगल

@MrTelly दो खर्च हैं: a) डिस्क स्टोरेज (5-8 tb के लिए, इंडेक्स द्वारा उपयोग की जाने वाली जगह के आधार पर) b) RAM (प्रश्नों का समर्थन करने के लिए, इंडेक्स कैशिंग)। यह करने के लिए अखंड रूप से आमतौर पर एक बड़े RAID10 सरणी या SAN के साथ किया जाएगा। हालाँकि, ध्यान दें कि शार्किंग निश्चित रूप से किया जा सकता है, और आप कई SQL सर्वर पर कार्यभार को तेज करने के लिए एप्लिकेशन स्तर तर्क का उपयोग कर सकते हैं। यह आपको 0.5-2tb प्रत्येक के साथ सस्ते सर्वर का उपयोग करने की अनुमति दे सकता है, और शायद मुफ्त SQL सर्वर संस्करण का भी उपयोग कर सकता है। (ध्यान दें कि शेरिंग एक सामान्य अवधारणा है, अक्सर ऐप स्तर पर किया जाता है, और किसी भी हठ विधि पर लागू होता है)

— samsmith

Answer 3

मैं HBase की सिफारिश करूंगा । आप सभी कच्चे डेटा को एक या एक से अधिक HBase तालिकाओं में संग्रहीत कर सकते हैं, जो आपको क्वेरी करने की आवश्यकता पर निर्भर करता है। HBase बड़े डेटा-सेट को संभाल सकता है और रीजन-स्प्लिट्स के माध्यम से ऑटो-शार्किंग करता है।

इसके अलावा, यदि आप पंक्ति कुंजियों को अच्छी तरह से डिज़ाइन करते हैं, तो आप ओ (1) प्रश्नों को भी बहुत तेज़ी से प्राप्त कर सकते हैं। ध्यान दें कि यदि आप एक बड़े डेटा सेट को पुनः प्राप्त कर रहे हैं, तो डेटा O (n) ऑपरेशन से पुनर्प्राप्त करने के बाद भी धीमा होने वाला है।

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

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

इसलिए यदि आप मार्च 27 12:00 पूर्वाह्न से 27 मार्च 12:01 बजे तक शुरू होने वाले 1.2.3.4 के सभी डेटा के लिए क्वेरी करना चाहते हैं, तो आप प्रारंभ के साथ एक रेंज स्कैन कर सकते हैं और निर्दिष्ट पंक्तियों को रोक सकते हैं।

IMHO, पंक्ति कुंजी डिज़ाइन HBase का उपयोग करने का सबसे महत्वपूर्ण हिस्सा है - यदि आप इसे अच्छी तरह से डिज़ाइन करते हैं, तो आप तेजी से क्वेरी करने और डेटा के बड़े संस्करणों को संग्रहीत करने में सक्षम होंगे।

Answer 4

ऐसा कहा :

... हम इस परियोजना के लिए मालिकाना समाधान देखने के विरोध में नहीं हैं

मेरा सुझाव है कि IBM Informix डेटाबेस + TimeSeries डेटाब्लेड पर विचार करें। कुछ लोग जो कहते हैं उसके विपरीत, इनफोरमिक्स जीवित है और बहुत अच्छा चल रहा है। अंतिम संस्करण पिछले महीने (मार्च / 2013, संस्करण 12.10) जारी किया गया था।

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

यहां आप बेंचमार्क की एक पीडीएफ की जांच कर सकते हैं जिसे संदर्भ के रूप में उपयोग किया जा सकता है। यहां अधिक तकनीकी उदाहरणों के साथ दो प्रस्तुतियां: डमी गाइड और अन्य युक्तियां

मेरे पास टाइमसीरीज के साथ व्यक्तिगत अनुभव नहीं है , इसलिए मैं सहमत नहीं हूं कि यह "समाधान" होगा, बस मूल्यांकन करने के लिए एक सुझाव।

Answer 5

मैं Informix TimeSeries को देखने के लिए सिफारिश करता हूं। आईबीएम साहित्य का दावा है कि TimeSeries इस तरह की जानकारी को 1/5 वें स्थान पर संग्रहीत कर सकती है और पारंपरिक संबंधपरक तालिकाओं के रूप में 5 गुना तेजी से प्रदर्शन कर सकती है।

अतिरिक्त लाभ वर्चुअल टेबल इंटरफ़ेस होगा जो टाइमसैरी डेटा को अंत उपयोगकर्ता के लिए पारंपरिक संबंधपरक तालिकाओं की तरह दिखाई दे सकता है (एप्लिकेशन डेवलपमेंट को सरल बनाते हुए, टाइमसैरीज का लाभ प्राप्त करते हुए सरलता से), एचडीआर नोड्स के साथ सरल हा जो अब संस्करण 12.1 में टाइमसेरी डेटा का समर्थन करते हैं और Informix Warehouse Accelerator में TimeSeries डेटा का एकीकरण, जिसका उपयोग जटिल डेटा वेयरहाउस रिपोर्ट और Informix में एक TimeSeries समाधान को प्रोटोटाइप करने की क्षमता को मुक्त Informix डेवलपर या Innovator-C संस्करणों का उपयोग करके किया जा सकता है।