MySQL बनाम MongoDB 1000 पढ़ता है


320

मैं MongoDb के बारे में बहुत उत्साहित हूं और हाल ही में इसका परीक्षण कर रहा हूं। मेरे पास MySQL में एक टेबल थी जिसे लगभग 20 मिलियन रिकॉर्ड्स के साथ पोस्ट किया गया था जिसे केवल 'id' नामक फ़ील्ड पर अनुक्रमित किया गया था।

मैं MongoDB के साथ गति की तुलना करना चाहता था और मैंने एक परीक्षण चलाया जो हमारे विशाल डेटाबेस से यादृच्छिक रूप से 15 रिकॉर्ड प्राप्त करेगा और प्रिंट करेगा। मैंने mysql और MongoDB के लिए प्रत्येक के बारे में 1,000 बार क्वेरी चलाई और मुझे आश्चर्य हुआ कि मुझे गति में बहुत अंतर नहीं दिखता है। शायद MongoDB 1.1 गुना तेज है। यह बहुत निराशाजनक है। क्या कुछ है जो मैं गलत कर रहा हूँ? मुझे पता है कि मेरे परीक्षण सही नहीं हैं, लेकिन जब यह गहन कार्य पढ़ने के लिए आता है, तो यह MongoDb के बराबर है।


ध्यान दें:

  • मेरे पास दोहरे कोर + (2 धागे) i7 सीपीयू और 4 जीबी रैम हैं
  • मेरे 1 मिलियन रिकॉर्ड्स में से MySQL पर 20 विभाजन हैं

MongoDB परीक्षण के लिए प्रयुक्त नमूना कोड

<?php
function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}
$time_taken = 0;
$tries = 100;
// connect
$time_start = microtime_float();

for($i=1;$i<=$tries;$i++)
{
    $m = new Mongo();
    $db = $m->swalif;
    $cursor = $db->posts->find(array('id' => array('$in' => get_15_random_numbers())));
    foreach ($cursor as $obj)
    {
        //echo $obj["thread_title"] . "<br><Br>";
    }
}

$time_end = microtime_float();
$time_taken = $time_taken + ($time_end - $time_start);
echo $time_taken;

function get_15_random_numbers()
{
    $numbers = array();
    for($i=1;$i<=15;$i++)
    {
        $numbers[] = mt_rand(1, 20000000) ;

    }
    return $numbers;
}

?>


MySQL परीक्षण के लिए नमूना कोड

<?php
function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}
$BASE_PATH = "../src/";
include_once($BASE_PATH  . "classes/forumdb.php");

$time_taken = 0;
$tries = 100;
$time_start = microtime_float();
for($i=1;$i<=$tries;$i++)
{
    $db = new AQLDatabase();
    $sql = "select * from posts_really_big where id in (".implode(',',get_15_random_numbers()).")";
    $result = $db->executeSQL($sql);
    while ($row = mysql_fetch_array($result) )
    {
        //echo $row["thread_title"] . "<br><Br>";
    }
}
$time_end = microtime_float();
$time_taken = $time_taken + ($time_end - $time_start);
echo $time_taken;

function get_15_random_numbers()
{
    $numbers = array();
    for($i=1;$i<=15;$i++)
    {
        $numbers[] = mt_rand(1, 20000000);

    }
    return $numbers;
}
?>

11
वास्तविक समय क्या हैं?
अबे पेट्रिलो

30
मैं एक डीबीए नहीं हूं, इसलिए यह एक टिप्पणी है एक जवाब नहीं है, लेकिन MySQL और MongoDB के बीच चयन करते समय गति मुख्य विचार नहीं होनी चाहिए। स्कीमालेस बनाम स्कीमा (यानी आपके डेटा स्कीमा को कितनी बार बदलने की आवश्यकता है) और आकार में स्केलिंग (यानी कितना आसान है अपने डेटा को शार्प करना ताकि एक सामान्य रीड को केवल एक सर्वर से डेटा की आवश्यकता होती है) पसंद के लिए अधिक महत्वपूर्ण हैं इस तरह।
rossdavidh

17
यह पढ़ने में तेज कैसे हो सकता है? यह एक यांत्रिक उपकरण से पढ़ता है। MySQL के रूप में भी। यह डिवाइस की गति पर ही निर्भर करता है, आप हार्डवेयर की सीमाओं को तोड़ने के लिए कोड के माध्यम से कुछ अजीब जादू को नियोजित नहीं कर सकते हैं।
एनबी

7
यह सवाल सिर्फ इस बात की याद दिलाता है: mongodb-is-web-scale.com
एलिगॉफ्रेन

13
लोगों को गलत लगता है कि उन्हें लगता है कि वे एक या दूसरे के साथ जाएंगे। आपको अपनी रसोई में माइक्रोवेव और ओवन दोनों की आवश्यकता होगी। आप सिर्फ यह नहीं कह सकते कि मैं केवल एक या दूसरे का उपयोग करूंगा। दोनों प्रणालियों के मामले अलग-अलग हैं। यदि आपको अपने ऐप के भाग के लिए ACID की आवश्यकता है, तो RDBMS का उपयोग करें, यदि स्थिरता और बाधाओं की परवाह नहीं है और आपकी इकाइयाँ सभी को एक (संग्रह) में संग्रहीत किया जा सकता है तो MongoDB का उपयोग करें। आप एक हाइब्रिड सिस्टम का उपयोग करके समाप्त हो जाएंगे, मुख्य बिंदु यह तय कर रहा है कि कहां स्टोर करना है।
तेमन शिपाही

जवाबों:


645

MongoDB जादुई रूप से तेज़ नहीं है। यदि आप उसी डेटा को स्टोर करते हैं, जो मूल रूप से उसी फैशन में व्यवस्थित है, और इसे बिल्कुल उसी तरह एक्सेस करते हैं, तो आपको वास्तव में अपने परिणामों को बेतहाशा अलग होने की उम्मीद नहीं करनी चाहिए। आखिरकार, MySQL और MongoDB दोनों GPL हैं, इसलिए यदि Mongo में कुछ जादुई रूप से बेहतर IO कोड होता, तो MySQL टीम इसे अपने कोडबेस में शामिल कर सकती थी।

लोग वास्तविक दुनिया MongoDB प्रदर्शन को बड़े पैमाने पर देख रहे हैं क्योंकि MongoDB आपको एक अलग तरीके से क्वेरी करने की अनुमति देता है जो आपके कार्यभार के लिए अधिक समझदार है।

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

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

MongoDB में, पूरी इकाई को पुनः प्राप्त करने के लिए, आपको प्रदर्शन करना होगा:

  • संग्रह पर एक अनुक्रमणिका लुकअप (आईडी द्वारा प्राप्त की गई इकाई मानकर)
  • एक डेटाबेस पृष्ठ की सामग्री को पुनः प्राप्त करें (वास्तविक बाइनरी जोंस दस्तावेज़)

तो एक बी-ट्री लुकअप, और एक बाइनरी पेज पढ़ा। लॉग (n) + 1 IOs। यदि अनुक्रमणिका पूरी तरह से मेमोरी में निवास कर सकती है, तो 1 आईओ।

20 टेबल के साथ MySQL में, आपको प्रदर्शन करना होगा:

  • रूट टेबल पर एक इंडेक्स लुकअप (फिर से, इकाई को आईडी द्वारा प्राप्त किया जाता है)
  • एक संकुल सूचकांक के साथ, हम मान सकते हैं कि मूल पंक्ति के मान सूचकांक में हैं
  • इकाई के पीके मूल्य के लिए 20+ रेंज लुकअप (एक सूचकांक पर उम्मीद है)
  • ये संभवत: अनुक्रमित क्लस्टर नहीं हैं, इसलिए एक ही 20+ डेटा लुकअप एक बार हम यह पता लगा लेते हैं कि उपयुक्त चाइल्ड रो क्या हैं।

तो mysql के लिए कुल, यहां तक ​​कि यह मानते हुए कि सभी सूचकांक मेमोरी में हैं (जो कि कठिन है क्योंकि उनमें से 20 गुना अधिक हैं) लगभग 20 रेंज लुकअप हैं।

इन रेंज लुकअपों में यादृच्छिक IO शामिल होने की संभावना है - अलग-अलग टेबल डिस्क पर अलग-अलग स्पॉट में निश्चित रूप से निवास करेंगे, और यह संभव है कि एक इकाई के लिए एक ही तालिका में एक ही रेंज में अलग-अलग पंक्तियाँ सन्निहित नहीं हो सकती हैं (यह निर्भर करता है कि इकाई कैसे हुई है) अद्यतन, आदि)।

इस उदाहरण के लिए, MongoDB की तुलना में अंतिम तार्किक प्रति MySQL प्रति तार्किक पहुंच के साथ लगभग 20 गुना अधिक IO है।

यह है कि MongoDB कुछ उपयोग मामलों में प्रदर्शन को कैसे बढ़ा सकता है ।


43
क्या होगा अगर हम सिर्फ एक मुख्य तालिका mysql में डाल दें?
अरिसो

98
@ariso: यह अपभ्रंश द्वारा अनुकूलन है। यह एक प्रदर्शन को बढ़ावा दे सकता है। हालाँकि, यदि आप ऐसा करते हैं, तो आप एक रिलेशनल डेटाबेस के अपने साफ डिज़ाइन, और सभी पावर (अधिकांश सुविधाओं का उल्लेख नहीं करना) को फेंक रहे हैं। और यह केवल तब तक काम करता है जब तक आप कॉलम की सीमा से नहीं टकराते।
सीन रिली

7
@ सीनियनिली संस्थाओं के साथ आपका उदाहरण (वस्तुओं के साथ संपादित किया जाना चाहिए, कोई इकाई उन्मुख प्रोग्रामिंग नहीं है :)) अमान्य है। जैसा कि आरिसो ने कहा, आप किसी वस्तु को क्रमबद्ध कर सकते हैं और इसे डीबी में स्टोर कर सकते हैं और जब जरूरत हो (धारावाहिक के किसी भी रूप) में डिसेर्बलाइज कर सकते हैं। स्थायी वस्तुओं की सच्ची शक्ति को udbms में रखा गया है न कि documnet db सिस्टम। लेकिन मैं मानता हूं कि प्रत्येक का अपना उद्देश्य और स्ट्रेंथ है (लेकिन आपका उदाहरण इस विषय की दृष्टि और प्रासंगिकता को अधिक बाधित करता है)।
जियो सी।

9
20 जोड़, मैं कहूंगा, सबसे अच्छा डेटाबेस स्कीमा पर सबसे अच्छी क्वेरी नहीं है ये संभवतः हो सकते हैं।
ऑड्रियस मेसकॉस्कस

8
@ सीनियरिली मुझे आपका उदाहरण बहुत मददगार लगा। आप MySQL के लिए एक विशेष इंटरफ़ेस का निर्माण कर सकते हैं जो स्वचालित रूप से ऑब्जेक्ट्स को टेबल पर क्रमबद्ध और डिस्क्रिअलाइज़ करता है और जिस तरह से मोंगोडब करता है वह व्यवहार करता है। लेकिन फिर, क्यों न केवल विशेष रूप से उस तरह से उपयोग किए जाने वाले कुछ का उपयोग करें? इसके अलावा "इकाई" का आपका उपयोग समझ में आता है। मुद्दा यह है कि आप डेटा को एक तालिका में फ़ील्ड के बजाय दस्तावेज़ के रूप में व्यवस्थित कर रहे हैं। दस्तावेज़ OO भाषा में रचित एक वस्तु है या नहीं, उदाहरण के लिए अप्रासंगिक है।
BHS

57

क्या आपके पास एक साथ उपयोगकर्ता हैं? यदि आप सिर्फ एक धागे से सीधे 1000 बार क्वेरी चलाते हैं, तो लगभग कोई अंतर नहीं होगा। इन इंजनों के लिए बहुत आसान :)

लेकिन मैं दृढ़ता से सुझाव देता हूं कि आप एक सच्चे लोड परीक्षण सत्र का निर्माण करते हैं, जिसका अर्थ है 10, 20 या 50 उपयोगकर्ताओं के साथ JMeter जैसे इंजेक्टर का उपयोग करना, ताकि आप वास्तव में अंतर देख सकें (इस कोड को एक वेब पेज के अंदर एम्बेड करने की कोशिश करें) क्वेरी कर सकता है)।

मैंने अभी इसे एक ही सर्वर (और एक साधारण संग्रह / तालिका) पर किया था और परिणाम काफी दिलचस्प और आश्चर्यजनक हैं (MyoAM इंजन और InnoDb इंजन की तुलना में MongoDb वास्तव में लिखने और पढ़ने में तेज था)।

यह वास्तव में आपके परीक्षण का हिस्सा होना चाहिए: संगामिति और MySQL इंजन। फिर, डेटा / स्कीमा डिज़ाइन और एप्लिकेशन की आवश्यकताएं प्रतिक्रिया समय से परे, निश्चित रूप से बहुत बड़ी आवश्यकताएं हैं। मुझे पता है जब आप परिणाम प्राप्त करते हैं, तो मुझे इस बारे में इनपुट की भी आवश्यकता है!


42
क्या आप परिणाम साझा कर सकते हैं?
इमरान उमर बख्श

1
हां, उस पर परिणाम बहुत उपयोगी होंगे
वासिल पोपोव

3
निश्चित रूप से यह सिर्फ पैमाना होगा ... अगर यह एपल्स टू एपल्स था जैसा कि वे इस विषय के बाकी हिस्सों में कह रहे हैं। तो अगर यह avg पर यह एक्स प्रदर्शन करता है, तो अब कई स्रोतों से अनुकरण करें, कृपया बताएं कि मोंगो अधिक तेज क्यों होगा। यानी सिर्फ समझौते के लिए कहना है कि mysql एकल अनुरोध के लिए तेजी से औसत पर था ... क्यों अब कई के लिए तेजी से बढ़ेगा? मुझे यह बहुत वैज्ञानिक नहीं लगता। Im कह रहा है कि परीक्षण वैध है .. लेकिन इतना निश्चित नहीं है कि अंतर कितना बड़ा होगा यदि आप सेब की तुलना सेब से कर रहे हैं जैसे कि बाकी विषय बताते हैं।
सीबकॉक

36

स्रोत: https://github.com/webcaetano/mongo-mysql

10 पंक्तियाँ

mysql insert: 1702ms
mysql select: 11ms

mongo insert: 47ms
mongo select: 12ms

100 पंक्तियाँ

mysql insert: 8171ms
mysql select: 10ms

mongo insert: 167ms
mongo select: 60ms

1000 पंक्तियाँ

mysql insert: 94813ms (1.58 minutes)
mysql select: 13ms

mongo insert: 1013ms
mongo select: 677ms

10.000 पंक्तियाँ

mysql insert: 924695ms (15.41 minutes)
mysql select: 144ms

mongo insert: 9956ms (9.95 seconds)
mongo select: 4539ms (4.539 seconds)

91
10,000 पंक्तियों को सम्मिलित करने के लिए 15 मिनट? यह एक बहुत ही एनीमिक MySQL डेटाबेस है। मेरे अनुभव में, अगर इस तरह की कार्रवाई अवधि में 1s तक पहुंचती है, तो मेरा फोन शिकायतों के साथ रोशनी करता है। :)
मोर्दकै

1
Xtreme बाइकर लिंक पर एक नज़र रखना। मैंने अन्य लोगों से अन्य सेटिंग्स के साथ परीक्षण पोस्ट किया।
user2081518

14
कुछ बिंदुओं: 1) मैसकल को अनुकूलित और ठीक से कॉन्फ़िगर करने की आवश्यकता है, बड़ी मात्रा में डेटा डालने के लिए बहुत सारे तरीके हैं, और ठीक से किया गया यह 15 मिनट का 0.1% ले सकता है, उदाहरण के लिए इस पृष्ठ को देखें। 2) MongoDB सीधे डिस्क को डेटा नहीं लिखता है, यही कारण है कि यह "तेज" दिखता है, लेकिन यदि आपका कंप्यूटर क्रैश हो जाता है, तो डेटा खो जाता है। 3) MySQL में पढ़ना बहुत तेज है
elipoultorak

81
10.000 पंक्तियों के लिए 15 मिनट? आपने प्रत्येक पंक्ति टाइप की? =))))
इउरी माने

6
किसी को भी, जो दावा करता है कि दस पंक्तियों को mysql में डालने के लिए 1.7 सेकंड लगते हैं, वे उस दर्द के हकदार हैं जो उन्हें मोंगो से मिलता है
जॉन ह्युग्लैंड

20

आदमी ,,, इसका उत्तर यह है कि आप मूल रूप से PHP का परीक्षण कर रहे हैं, डेटाबेस का नहीं।

परिणामों की पुनरावृत्ति करने से परेशान न हों, चाहे वह टिप्पणी प्रिंट करें या नहीं। समय का एक हिस्सा है।

   foreach ($cursor as $obj)
    {
        //echo $obj["thread_title"] . "<br><Br>";
    }

जबकि दूसरा हिस्सा रैंड नंबरों का एक गुच्छा भर रहा है।

function get_15_random_numbers()
{
    $numbers = array();
    for($i=1;$i<=15;$i++)
    {
        $numbers[] = mt_rand(1, 20000000) ;

    }
    return $numbers;
}

तब एक बड़ा अंतर बी / डब्ल्यू इम्पोड और इन में आता है।

और अंत में यहाँ क्या हो रहा है। हर बार एक कनेक्शन बनाने की तरह दिखता है, इस प्रकार इसका कनेक्शन समय और क्वेरी समय का परीक्षण करता है।

$m = new Mongo();

बनाम

$db = new AQLDatabase();

तो आपका 101% तेजी से जाज की छीन ली गई अंतर्निहित क्वेरी के लिए 1000% तेज हो सकता है।

urghhh।


4
स्वाभाविक रूप से, कोडिंग अभ्यास किसी भी स्थिति में एक बड़ा बदलाव ला सकता है, लेकिन यह किसी भी प्रकार की भाषा, एपीआई या विस्तार के लिए विशिष्ट नहीं है। टाइमर शुरू करने से पहले यादृच्छिक संख्याओं को उत्पन्न करने से फर्क पड़ेगा, लेकिन प्रक्रिया के भीतर अधिकांश समय डेटाबेस लेनदेन से कोई संदेह नहीं है। यादृच्छिक संख्या पीढ़ी तुच्छ है, SQL और NoSQL डेटाबेस नहीं हैं।
JSON

1
रैंड नंबर पर मत उठाओ। स्पष्ट रूप से आप हर बार कनेक्शन बनाने से चूक गए। सभी मुद्दों पर इरादा के अलावा कुछ और परीक्षण करने के लिए जोड़ें।
गाबे इंद्रधनुष

2
नहींं, यह याद नहीं किया। MySQL तब तक कनेक्शन बंद नहीं करता जब तक कि स्क्रिप्ट खत्म नहीं हो जाती जब तक कि mysqli_close () नहीं कहा जाता है। अन्यथा, mysqli_connect () के लिए पुन: कॉल केवल एक नई कनेक्शन प्रक्रिया करने के बजाय मौजूदा संसाधन तालिका से मौजूदा mysql संसाधन को खींच लेगा। मुझे बिलकुल यकीन नहीं है कि AQLDatabase object क्या है, लेकिन अगर यह mysql lib (जो यह संभावना करता है) का उपयोग करता है तो इसका व्यवहार समान होगा। MongoDB एक्सटेंशन कनेक्शन पूलिंग का उपयोग करता है, इसलिए स्क्रिप्ट में एक से अधिक बार मूंगबोड 'कनेक्शन' बनाते समय एक ही मूल बात होती है।
JSON

मैं मानता हूं कि उसका बेंचमार्क अलग तरह से किया जा सकता था, लेकिन यह अन्य MySQL बनाम Mongo बेंचों के समान मूल परिणामों को दर्शाता है जो मैंने देखा है। आम तौर पर (जब अधिक सरल आवेषण के लिए बहुत तेज) सम्मिलित करते हैं और चयन करते समय MySQL आमतौर पर तेज होता है।
JSON

माना जाता है कि मैं भी बहुत ताकतवर था; यह "<br>" का html string concat था जो वास्तव में मुझे 'उकसाया' था। आपको परीक्षणों में बहुत प्रिंट की आवश्यकता नहीं है। यहां तक ​​कि पुनरावृति यह एक php परीक्षण की तरह लगता है और डेटाबेस परीक्षण नहीं। कुल मिलाकर, कि AQLDatabase 'संभवतः / शायद' क्षण ... अधिक सामग्री का अर्थ अधिक अज्ञात है।
गेबे रेनबो

17

https://github.com/reoxey/benchmark

बेंचमार्क

GOLANG1.6 और PHP5 में MySQL और MongoDB की गति तुलना

सिस्टम बेंचमार्क के लिए उपयोग किया जाता है: डेल सीपीयू i5 4 जी जीन 1.70Ghz * 4 रैम 4 जीबी जीपीयू रैम 2 जीबी

INSERT, SELECT, UPDATE, DELETE के लिए RDBMS बनाम NoSQL की स्पीड तुलना 10,100,1000,10000,100000,1000000 की विभिन्न पंक्तियों को निष्पादित करने वाली

निष्पादित करने के लिए उपयोग की जाने वाली भाषा है: PHP5 और Google सबसे तेज़ भाषा GO 1.6

________________________________________________
GOLANG with MySQL (engine = MyISAM)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            INSERT
------------------------------------------------
num of rows             time taken
------------------------------------------------
10                      1.195444ms
100                     6.075053ms
1000                    47.439699ms
10000                   483.999809ms
100000                  4.707089053s
1000000                 49.067407174s


            SELECT
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 872.709µs


        SELECT & DISPLAY
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 20.717354746s


            UPDATE
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 2.309209968s
100000                  257.411502ms
10000                   26.73954ms
1000                    3.483926ms
100                     915.17µs
10                      650.166µs


            DELETE
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 6.065949ms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


________________________________________________
GOLANG with MongoDB
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            INSERT
------------------------------------------------
num of rows             time taken
------------------------------------------------
10                      2.067094ms
100                     8.841597ms
1000                    106.491732ms
10000                   998.225023ms
100000                  8.98172825s
1000000                 1m 29.63203158s


            SELECT
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 5.251337439s


        FIND & DISPLAY (with index declared)
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 21.540603252s


            UPDATE
------------------------------------------------
num of rows             time taken
------------------------------------------------
1                       1.330954ms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

________________________________________________
PHP5 with MySQL (engine = MyISAM)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            INSERT
------------------------------------------------
num of rows             time taken
------------------------------------------------
 10                     0.0040680000000001s
 100                    0.011595s
 1000                   0.049718s
 10000                  0.457164s
 100000                 4s
 1000000                42s


            SELECT
------------------------------------------------
num of rows             time taken
------------------------------------------------
 1000000                <1s


            SELECT & DISPLAY
------------------------------------------------
num of rows             time taken
------------------------------------------------
  1000000               20s
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

________________________________________________
PHP5 with MongoDB 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            INSERT
------------------------------------------------
num of rows             time taken
------------------------------------------------
10                      0.065744s
100                     0.190966s
1000                    0.2163s
10000                   1s
100000                  8s
1000000                 78s


            FIND
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 <1s


            FIND & DISPLAY
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 7s


            UPDATE
------------------------------------------------
num of rows             time taken
------------------------------------------------
1000000                 9s

myisam innodb नहीं है, यह भी कि कौन सा mongodb संस्करण और भंडारण इंजन है?

1
MySQL और MongoDB संस्करण निर्दिष्ट करना महत्वपूर्ण है।
मिरॉन

1
MyISAM का उपयोग न करें। बैच वाले आवेषण का उपयोग करें!
रिक जेम्स

MySQL क्वेरी क्वेरी में Mongodb से तेज है ?! यह तब तक सही नहीं लगता जब तक mysql को कॉलम और रीरेलशिप तैयार करने की आवश्यकता नहीं होती। mysql सेलेक्ट मेंगोडब सेलेक्ट की तुलना में तेज़ है, लेकिन क्वैरी डालने में,
mongo

6

यहाँ एक छोटा शोध है जिसने MySQL vs Mongo का उपयोग करते हुए RDBMS बनाम NoSQL का पता लगाया, निष्कर्ष @Sean Reilly की प्रतिक्रिया के साथ इनलाइन थे। संक्षेप में, लाभ डिजाइन से आता है, न कि कुछ कच्ची गति के अंतर से। पृष्ठ 35-36 पर निष्कर्ष:

RDBMS बनाम NoSQL: प्रदर्शन और स्केलिंग तुलना

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


-6

सिंगल सर्वर पर, MongoDb, mysql MyISAM से अधिक तेजी से नहीं पढ़े और लिखेंगे, दिए गए टेबल / डॉक का आकार छोटे 1 GB से 20 GB हैं।
मोनो-एनडी मल्टी-नोड समूहों पर समानांतर कटौती पर अधिक तेज़ होगा, जहां मैसकल क्षैतिज रूप से स्केल नहीं कर सकता है।


5
क्या आप इसे वापस करने के लिए कुछ सबूत या अधिक विवरण प्रदान कर सकते हैं?
स्टीव वेस्टब्रुक

क्षैतिज रूप से माप नहीं सकते? NDB के बारे में क्या? DRBD ने MySQL का समर्थन किया?
अर्नेस्टस

यह सच नहीं है। MongoDB में 16MD दस्तावेज़ सीमा है। Mysql भी बहुत कुछ है अगर आप की तरह हो सकता है
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.