डीबी सर्वश्रेष्ठ आवेषण/सेकंड प्रदर्शन के साथ?

हम एक (AJAX- आधारित) त्वरित संदेशवाहक को तैनात करते हैं जिसे धूमकेतु सर्वर द्वारा सर्विस किया जाता है। कानूनी प्रतिधारण आवश्यकताओं को पूरा करने के लिए हमें दीर्घकालिक अभिलेखीय उद्देश्यों के लिए भेजे गए संदेशों को डीबी में संग्रहीत करने की आवश्यकता है।डीबी सर्वश्रेष्ठ आवेषण/सेकंड प्रदर्शन के साथ?

कौन सा डीबी इंजन इस लेखन में सबसे अच्छा प्रदर्शन प्रदान करता है-एक बार, दुर्लभ अपवादों के साथ कभी नहीं पढ़ता?

हमें कम से कम 5000 सम्मिलित/सेक की आवश्यकता है। मैं मानता हूं कि न तो MySQL और न ही PostgreSQL इन आवश्यकताओं को पूरा कर सकता है।

उच्च प्रदर्शन समाधान के लिए कोई प्रस्ताव? हैम्स्टर डीबी, एसक्यूएलआईटी, मोंगोडीबी ...?

स्रोत

2010-08-19 Nenad

मैं कुछ आवेदनों को पुनर्गठन की प्रक्रिया में हूं जो एमओएनओडीबी में है। आप अपनी सूची में कॉच डीबी भूल गए हैं, लेकिन जो मैंने सीखा है, उससे मैं भी एमओएनओडीबी का चयन करूंगा ... – polemon

धन्यवाद, इसका मतलब है कि मैं मोंगो डीबी के साथ सही तरीके से होगा, मोंगोडीबी के लिए और अधिक वोट? :-) – Nenad

मेरे हालिया परीक्षणों में, मैंने क्वाड-कोर सर्वर पर MySQL/Innodb के साथ 14 के टीपीएस प्राप्त किए और थ्रूपुट पाइथन में cpu-bound था, mysql नहीं। दूसरे शब्दों में MySQL के बारे में आपकी धारणा काफी गलत थी। मेरे लेन-देन विवाद के साथ काफी सरल परीक्षण और सम्मिलित थे, सोचते हैं कि "हिल ऑफ किंग" कई उपयोगकर्ताओं के बीच खेला जाता है। –

यदि आप कभी भी डेटा पूछने के लिए नहीं जा रहे हैं, तो मैं इसे डेटाबेस में संग्रहीत नहीं करता, आप उन्हें केवल एक फ्लैट फ़ाइल में लिखने के प्रदर्शन को हरा नहीं देंगे।

क्या आप विचार करना चाहते हैं स्केलिंग मुद्दे हैं, क्या होता है जब डेटा को एक फ्लैट फ़ाइल में लिखना धीमा होता है, तो क्या आप तेज डिस्क में निवेश करेंगे, या कुछ और।

विचार करने के लिए एक और बात यह है कि सेवा को कैसे स्केल करें ताकि आप प्रत्येक सर्वर के लॉग को समन्वयित किए बिना और उन्हें मैन्युअल रूप से समेकित किए बिना अधिक सर्वर जोड़ सकें।

संपादित करें: आपने लिखा है कि आप इसे डेटाबेस में रखना चाहते हैं, और फिर मैं लाइन पर डेटा को बनाए रखने के साथ सुरक्षा मुद्दों पर भी विचार करूंगा, जब आपकी सेवा से समझौता किया जाता है तो क्या होता है, क्या आप चाहते हैं कि आपके हमलावर सक्षम हों क्या कहा गया है के इतिहास को बदलें?

इसे अस्थायी रूप से फ़ाइल में संग्रहीत करना बेहतर हो सकता है, और उसके बाद इसे एक ऑफ-साइट स्थान पर डंप कर दें जो आपके इंटरनेट मोर्चों को हैक करने पर पहुंच योग्य नहीं है।

स्रोत

2010-08-19 08:40:42

यह डीबी सिस्टम के लिए एक कारण है, उनमें से अधिकतर बिना किसी परेशानी के उन्हें स्केल करने में सक्षम होंगे। फिलहाल मेरा पसंदीदा मोंगोडीबी है लेकिन मुझे आश्चर्य है कि क्या एक और डीबी सिस्टम अधिक सम्मिलित/सेक – Nenad

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

पुराना, लेकिन Google में शीर्ष 5 परिणाम .. मैं इस समय एक परियोजना पर विचार कर रहा हूं, इसी तरह के सेटअप .. न भूलें, डेटाबेस भी दिन के अंत में एक फ्लैट फ़ाइल है, इसलिए जब तक आप लोड को फैलाने के बारे में जानते हैं .. अपनी खुद की स्टोरेज विधि का पता लगाएं और एक्सेस करें .. यह एक बहुत ही व्यवहार्य विकल्प है .. इसलिए मुझे उपरोक्त कथन से सहमत होना है। सामान्य अभ्यास अब जेएसओएन डेटा स्टोर करना है, इस तरह आप संरचित जानकारी को क्रमबद्ध और आसानी से एक्सेस कर सकते हैं। डेटाबेस में उनकी जगह है, लेकिन यदि आप एक संग्रह कर रहे हैं ... यह करने का यह तरीका है। एक फ्लैट फ़ाइल का उपयोग करने पर – Mayhem

यदि आपको प्रश्न पूछने की आवश्यकता नहीं है, तो डेटाबेस आपको जो चाहिए वह नहीं है। एक लॉग फ़ाइल का प्रयोग करें।

स्रोत

2010-08-19 08:39:02 jmz

मैंने पाया कि हम डीबी सिस्टम के साथ डेटा को आसान तरीके से संभाल सकते हैं, हम अपने वेब ऐप के लिए डेटा से पूछताछ नहीं करते हैं, लेकिन अगर कानून से कुछ जांच है तो हमें अनुरोधित डेटा वितरित करने में सक्षम होना चाहिए, इसका मतलब है कि यह कम उपयोग करेगा इसे इकट्ठा करने के लिए समय। – Nenad

मैं एक टेक्स्ट-फ़ाइल आधारित समाधान के लिए भी जाऊंगा। उन्हें खोजने के लिए आप कमांडलाइन टूल जैसे grep या सरल टेक्स्ट प्रोसेसिंग का उपयोग कर सकते हैं। इस नौकरी के लिए डीबीएमएस स्केल करने में आपने जो समय बिताया था, वह लॉगफाइल का विश्लेषण करने के लिए कुछ छोटी लिपियों को लिखने से कहीं अधिक होगा, खासकर अगर आपके पास एक निश्चित रूप से संरचित लॉगफाइल है। यदि यह कानूनी उद्देश्यों के लिए है: सीडी/डीवीडी पर एक टेक्स्ट फ़ाइल अभी भी 10 वर्षों में पठनीय होगी (बशर्ते डिस्क स्वयं क्षतिग्रस्त न हो), क्या आप सुनिश्चित हैं कि आपके डेटाबेस डंप होंगे? –

ट्रेडऑफ को समझें। आखिरी क्वेरी एक बार हो सकती है, या बिल्कुल नहीं। आप इसके लिए अनुकूलन कितना समय बिताना चाहते हैं, इस पर विचार करते हुए कि आपको सटीक अनुरोध भी नहीं पता हो सकता है? यह आवश्यक है कि सभी आवश्यक डेटा रखने के लिए अक्सर व्यवहार्य और कानूनी रूप से उचित हो, और पुलिस अनुरोध आने पर मैन्युअल रूप से पूछताछ करें। – MSalters

यदि पैसा कोई भूमिका निभाता है, तो आप टाइम्सटेन का उपयोग कर सकते हैं। http://www.oracle.com/timesten/index.html

अद्भुत गति के साथ मेमोरी डेटाबेस में एक पूर्ण।

स्रोत

2010-08-19 08:43:25 BitKFu

मुझे यह उल्लेख करना भूल जाता है कि हम कम बजट पर हैं :-) – Nenad

एह, यदि आप इन-मेमोरी समाधान चाहते हैं तो अपना $$ बचाएं। MySQL की तरह कुछ उपयोग करें लेकिन निर्दिष्ट करें कि तालिका मेमरी स्टोरेज इंजन का उपयोग करती है, और उसके बाद स्मृति तालिका को एक अनुक्रमित myisam तालिका में दोहराने के लिए एक गुलाम सर्वर सेट अप करें। समस्या हल हो गई, और $$ बचाया। – Timothy

पिछली बार मैं कुछ गड़बड़ करने की कोशिश कर रहा था, मुझे मेमोरी टेबल पर रिकॉर्ड सीमा के साथ परेशानी हो रही थी, लेकिन सबसे बड़ी समस्या यह थी कि इस थ्रेड के लॉक/अनलॉक के साथ प्रदर्शन की कमी थी जब कई धागे के साथ प्रयोग किया जाता था। – Nenad

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

[email protected]:~$ fbexport -i -d test -f test.fbx -v table1 -p ** 
Connecting to: 'LOCALHOST'...Connected. 
Creating and starting transaction...Done. 
Create statement...Done. 
Doing verbatim import of table: TABLE1 
Importing data... 
SQL: INSERT INTO TABLE1 (AKCIJA,DATUM,KORISNIK,PK,TABELA) VALUES (?,?,?,?,?) 
Prepare statement...Done. 
Checkpoint at: 1000 lines. 
Checkpoint at: 2000 lines. 
Checkpoint at: 3000 lines. 
...etc. 
Checkpoint at: 20000 lines. 
Checkpoint at: 21000 lines. 
Checkpoint at: 22000 lines. 

Start : Thu Aug 19 10:43:12 2010 
End  : Thu Aug 19 10:43:14 2010 
Elapsed : 2 seconds. 
22264 rows imported from test.fbx.

Firebird खुला स्रोत, और यहां तक कि वाणिज्यिक परियोजनाओं के लिए पूरी तरह से स्वतंत्र है।

स्रोत

2010-08-19 08:46:38

मैं वास्तव में आरडीबीएमएस सिस्टम के साथ अद्यतित नहीं हूं, लेकिन पिछली बार जब मैं फायरबर्ड को स्पर्श करता हूं तो यह सबसे धीमा आरडीबीएमएस इंसर्ट के लिए उपलब्ध था। अगर मैं गलत नहीं हूं तो मोंडो डीबी इंसर्ट्स के लिए लगभग 5 गुना तेज है तो फायरबर्ड। – Nenad

फायरबर्ड एक अच्छा डीबीएमएस है, लेकिन _if_ आप डीबीएमएस के लिए जाते हैं, मैं किसी भी समय फायरबर्ड पर PostgreSQL चुनता हूं। PostgreSQL का समुदाय फ़ायरबर्ड की तुलना में अधिक सक्रिय है और इसमें पर्याप्त रिलीज चक्र हैं। फायरबर्ड का सबसे बड़ा दोष असंगठित मैनुअल है। यदि आपको एक विशिष्ट सुविधा/फ़ंक्शन ढूंढने की आवश्यकता है, तो आपको पहले इंटरबेस मैनुअल के माध्यम से जाना होगा, और फिर तब से रिलीज़ नोट्स के प्रत्येक (!) के माध्यम से जाना होगा। वर्तमान रिलीज के लिए कोई पूर्ण और समेकित मैनुअल नहीं है, जो बहुत ही परेशान है –

यह केवल कानूनी कारणों से संग्रहीत है।

और विस्तृत आवश्यकताओं के बारे में क्या? आप नोएसक्यूएल समाधान का जिक्र करते हैं, लेकिन ये वादा नहीं कर सकता कि डेटा डिस्क पर वास्तव में संग्रहीत है। PostgreSQL में सब कुछ लेनदेन सुरक्षित है, इसलिए आप 100% सुनिश्चित हैं कि डेटा डिस्क पर है और उपलब्ध है। (बस fsync की बारी न करें)

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

स्रोत

2010-08-19 09:02:05

कानूनी कारणों से डिस्क पर 100% निश्चित नहीं हो सकता है। यदि आप साबित कर सकते हैं कि आपके पास डिस्क क्रैश था, और विशेष रूप से इसके कारण किसी विशेष कानूनी अनुरोध का पालन नहीं किया जा सकता है, तो उस क्रैश को भगवान का एक अधिनियम माना जा सकता है। – MSalters

कौन जानता है। लेकिन भगवान का एक अधिनियम? अदालत में एक अच्छा बयान होगा, लेकिन आप एक अच्छा मौका खो देंगे। बस आवश्यकताओं की जांच करें और समाधान ढूंढने के लिए। –

@ फ्रैंक हेइकेंस - डेटा एक डेटिंग साइट के आईएम से है, इसे लेनदेन को सुरक्षित रखने की कोई आवश्यकता नहीं है। निश्चित रूप से मुझे उम्मीद है कि हम किसी भी डेटा को नुकसान नहीं पहुंचाएंगे। चूंकि हमारा बजट सीमित है, हमारे पास एक धूमकेतु वाले बॉक्स पर इस धूमकेतु सर्वर के लिए है जो आईएम वार्तालापों को संभालेगा और उसी पर हम डेटा स्टोर करेंगे। मैं PostgreSQL के लाभों को जानता हूं लेकिन इस वास्तविक परिदृश्य में मुझे लगता है कि यह मोंगो डीबी के प्रदर्शन से मेल नहीं खा सकता है जब तक कि हम 48 कोर सर्वर, एसएसडी सरणी और अधिक रैम के लिए कई रुपये खर्च नहीं करते हैं। – Nenad

आपके सिस्टम सेटअप में निर्भर करता है MySQL आसानी से प्रति सेकंड 50,000 से अधिक आवेषण संभाल सकता है।

वर्तमान प्रणाली पर परीक्षण के लिए मैं काम कर रहा हूं कि हमें प्रति सेकंड 200k से अधिक आवेषण मिलेंगे। 10 तालिकाओं पर 100 समवर्ती कनेक्शन के साथ (केवल कुछ मान)।

यह नहीं कह रहा कि यह सबसे अच्छा विकल्प है क्योंकि सोफे जैसे अन्य सिस्टम प्रतिकृति/बैकअप/स्केलिंग को आसान बना सकते हैं, लेकिन पूरी तरह से इस तथ्य पर mysql को खारिज कर सकते हैं कि यह डेटा की इतनी मामूली मात्रा को संभाल नहीं सकता है।

मुझे लगता है कि वहां बेहतर समाधान हैं (पढ़ें: सस्ता, प्रशासन करने में आसान) समाधान।

स्रोत

2010-08-19 09:10:37 edorian

क्या आप मुझे अपने वर्तमान सिस्टम के हार्डवेयर हार्डवेयर बता सकते हैं? – Nenad

मैं आपको सटीक चश्मा (निर्माता इत्यादि) नहीं बता सकता लेकिन आम तौर पर यह एक 8core, 16 जीबी रैम मशीन है जिसमें एक संलग्न भंडारण के साथ ~ 8-12 600 जीबी ड्राइव चल रहा है 10 – edorian

मुझे पता है कि यह पुराना है लेकिन यदि आप हैं अभी भी ... इन थोक आवेषण थे? – lcm

यदि तालिका में इंडेक्स नहीं हैं तो फायरबर्ड आसानी से 5000 सम्मिलित/सेकेंड को संभाल सकता है।

स्रोत

2010-08-19 12:38:50

मैं मोंगोडीबी –

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

स्रोत

2010-08-19 12:52:05

के साथ 5000 आवेषण/सेकंड प्राप्त कर सकता हूं। मैंने जो बेंचमार्क किया है, वह मुझे दिखाता है कि MySQL वास्तव में एक गंभीर आरडीबीएमएस है। – Nenad

उपर्युक्त बेंचमार्क को अनदेखा करें जिसमें हमारे अंदर एक बग था।

हमने निम्नलिखित कॉलम के साथ 1 एम रिकॉर्ड डाला है: आईडी (int), स्थिति (int), संदेश (140 char, यादृच्छिक)। 500 जीबी सटा डिस्क के साथ एक डेस्कटॉप पीसी i5 पर सी ++ चालक के साथ सभी परीक्षण किए गए थे।

MongoDB साथ बेंचमार्क सूचकांक के बिना

1M रिकॉर्ड्स सम्मिलित

time: 23s, insert/s: 43478

ईद

पर 1M रिकॉर्ड्स सम्मिलित सूचकांक साथ

time: 50s, insert/s: 20000

अगले हम 1M रिकॉर्ड करने के लिए जोड़ इंडेक्स ए के साथ एक ही टेबल एन 1 एम रिकॉर्ड

time: 78s, insert/s: 12820

कि सभी परिणाम fs पर 4 जीबी फाइलों के नजदीक हैं।

MySQL साथ बेंचमार्क सूचकांक के बिना

1M रिकॉर्ड्स सम्मिलित

time: 49s, insert/s: 20408

1M रिकॉर्ड्स सूचकांक के साथ सम्मिलित

time: 56s, insert/s: 17857

अगले हम एक ही करने के लिए 1M रिकॉर्ड जोड़ने इंडेक्स और 1 एम के साथ टेबल रिकॉर्ड

time: 56s, insert/s: 17857

बिल्कुल वैसा ही प्रदर्शन, विकास

पर mysql पर कोई नुकसान नहीं हम देखते हैं मोंगो इस परीक्षण और लोड CPU के 3 कोर के दौरान चारों ओर 384 एमबी राम खाने गया है, MySQL 14 MB और भार के साथ खुश था केवल 1 कोर

एडोरियन अपने प्रस्ताव के साथ सही तरीके से चल रहा था, मैं कुछ और बेंचमार्क करूँगा और मुझे यकीन है कि हम 2x क्वाड कोर सर्वर 50 के इंसर्ट/सेकंड पर पहुंच सकते हैं।

मुझे लगता है कि MySQL जाने का सही तरीका होगा।

स्रोत

2010-08-19 14:46:14 Nenad

वाह ... ये महान आंकड़े हैं। हालांकि मैं पूछ सकता हूं, क्या ये थोक आवेषण थे या ...? – lcm

यह मुझे कुछ भी नहीं बताता है कि क्या समवर्ती आवेषण थे, यदि थोक संचालन का उपयोग किया गया था, या कैश की स्थिति क्या थी। एक मिनट लंबा बेंचमार्क लगभग बेकार है, खासकर जब दो मौलिक रूप से अलग डेटाबेस प्रकारों की तुलना करते हैं। – slang

मेरा मानना है कि उत्तर हार्ड डिस्क प्रकार (एसएसडी या नहीं) पर निर्भर करता है और आपके द्वारा डाले गए डेटा का आकार भी निर्भर करता है। मैं एक दोहरी कोर उबंटू मशीन पर मोंगोडीबी में एक फ़ील्ड डेटा डाल रहा था और प्रति सेकंड 100 से अधिक रिकॉर्ड मार रहा था। मैंने एक क्षेत्र में कुछ बड़े डेटा पेश किए और यह लगभग 9पीएस तक गिर गया और सीपीयू लगभग 175% पर चल रहा है! बॉक्स में एसएसडी नहीं है और इसलिए मुझे आश्चर्य है कि अगर मैं इसके साथ बेहतर हो गया होता।

मैंने भी MySQL चलाया और 20 मीटर रिकॉर्ड (लगभग 4 सभ्य इंडेक्स के साथ) के साथ तालिका में 50 रिकॉर्ड डालने के लिए बस 50 सेकंड लग रहे थे, साथ ही साथ MySQL के साथ यह आपके द्वारा कितनी अनुक्रमणिका में निर्भर करेगा इस पर निर्भर करेगा।

स्रोत

2017-05-18 20:15:17 Antony

डीबी सर्वश्रेष्ठ आवेषण/सेकंड प्रदर्शन के साथ?

उत्तर

संबंधित मुद्दे