2011-09-21 11 views
7

Kilka miesięcy temu odkryłem mongodbę, a po przeczytaniu tego post, pomyślałem, że mongodb jest naprawdę szybszy od mysql, więc postanowiłem zbudować własną ławkę, problemem jest to, że nie mam tego samego wyniku, co autor powyższego posta, szczególnie w przypadku kwarantanny bazy danych: mongodb wydaje się wolniejszy niż tablice MyISAM. Można mieć wygląd mojego kodu Pythona, może coś jest nie tak w tym:MongoDB nie jest szybszy od MySQL?

from datetime import datetime 
import random 
import MySQLdb 
import pymongo 

mysql_db=MySQLdb.connect(user="me",passwd="mypasswd",db="test_kv") 
c=mysql_db.cursor() 

connection = pymongo.Connection() 
mongo_db = connection.test 
kvtab = mongo_db.kvtab 

nb=1000000 
thelist=[] 
for i in xrange(nb): 
    thelist.append((str(random.random()),str(random.random()))) 
t1=datetime.now() 

for k,v in thelist: 
    c.execute("INSERT INTO key_val_tab (k,v) VALUES ('" + k + "','" + v + "')") 

dt=datetime.now() - t1 
print 'MySQL insert elapse :',dt 

t1=datetime.now() 
for i in xrange(nb): 
    c.execute("select * FROM key_val_tab WHERE k='" + random.choice(thelist)[0] + "'") 
    result=c.fetchone() 

dt=datetime.now() - t1 
print 'MySQL select elapse :',dt 


t1=datetime.now() 

for k,v in thelist: 
    kvtab.insert({"key":k,"value":v}) 

dt=datetime.now() - t1 
print 'Mongodb insert elapse :',dt 
kvtab.ensure_index('key') 
t1=datetime.now() 
for i in xrange(nb): 
    result=kvtab.find_one({"key":random.choice(thelist)[0]}) 

dt=datetime.now() - t1 
print 'Mongodb select elapse :',dt 

Uwagi:

  • zarówno MySQL i MongoDB są na locahost.
  • zarówno MySQL i MongoDB posiada 'klucz' kolumna indeksowane

MySQL:

CREATE TABLE IF NOT EXISTS `key_val_tab` (
    `k` varchar(24) NOT NULL, 
    `v` varchar(24) NOT NULL, 
    KEY `kindex` (`k`) 
) ENGINE=MyISAM DEFAULT CHARSET=latin1; 

wersjach:

  • MySQL: 5.1.41
  • MongoDB: 1,8 .3
  • python: 2.6.5
  • pymongo: 2.0.1
  • Linux: Ubuntu 2.6.32 32-bitowego z PAE
  • Wyposażenie: Pulpit rdzeń i7 2,93 GHz

Wyniki (na 1 milion/wybiera wkładki):

MySQL insert elapse : 0:02:52.143803 
MySQL select elapse : 0:04:43.675914 
Mongodb insert elapse : 0:00:49.038416 -> mongodb much faster for insert 
Mongodb select elapse : 0:05:10.409025 -> ...but slower for quering (thought was the opposite) 
+3

Po pierwsze, MongoDB lubi architekturę 64-bitową. Nie postawiłbym zbyt wiele w benchmarku prowadzonym przez kogoś, kto nie jest bardzo doświadczony w testowaniu jednego z systemów. – ceejayoz

+0

dlatego poprosiłem o pomoc! – Eric

+9

@ceejayoz Jeśli musisz być bardzo doświadczony, aby przyspieszyć, będzie on powolny dla większości użytkowników. Powiedziałbym, że testy porównawcze wykonane przez niedoświadczonych użytkowników mogą być równie użyteczne ... –

Odpowiedz

6
MySQL insert elapse : 0:02:52.143803 
Mongodb insert elapse : 0:00:49.038416 -> mongodb much faster for insert 

Mongodb wstawia znacznie szybciej, ponieważ mongodb wstawia wszystkie dane do pamięci RAM, a następnie okresowo wypłukuje dane na dysk.

MySQL select elapse : 0:04:43.675914 
Mongodb select elapse : 0:05:10.409025 -> ...but slower for quering (thought was 

Możesz osiągnąć najlepszą wydajność z mongodb, kiedy będziesz osadzać/denormalizować swoje dane. W wielu sytuacjach mongody pozwalają nam uniknąć złączeń z powodu osadzania/denormalizacji.

A kiedy tylko wstawiasz dane do jednego zbioru/tabeli i odczytywanie przez index mongodb nie powinno być szybsze, prędkość odczytu powinna być taka sama, jeśli porównać z bazą danych sql.

BTW: W mongodb 2.0 indexes 25% szybciej, więc myślę, że 2.0 będzie działać szybciej niż mysql.

+6

wstawki są szybsze, ponieważ nie robi tego, co robi MySQL. safe = true inserty są nieco wolniejsze (bit ogólnie jeszcze szybszy niż MySQL), a replikowane zapisy lub zapisy fsync są wolniejsze. Innymi słowy porównania są wątpliwe. Robią szalenie różne rzeczy. –

+0

Zgadzam się z tobą, ale nie porównuję, właśnie powiedziałem dlaczego w swoim benchmark mongodb szybciej. Z powodu domyślnie safe = false i jest to średnie w kolorze na minutę. –

27

Westchnienie. Tego rodzaju testy porównawcze i luźno w tym przypadku używam tego terminu, zwykle rozpadają się od samego początku. MySQL nie jest "wolniejszą" bazą danych niż MongoDB. Jedna to relacyjna baza danych, a druga to magazyn dokumentów NoSQL. Będą/powinny być szybsze w obszarach funkcjonalnych, które zostały zaprojektowane do pokrycia. W przypadku MySQL (lub dowolnego RDBMS) i MongoDB to nakładanie się nie jest tak duże, jak wielu ludzi je zakłada. To porównanie łamanych jabłek i pomarańczy z dyskusjami Redis vs. MongoDB.

Jest tak wiele zmiennych (wymagania funkcjonalne aplikacji, zasoby sprzętowe, współbieżność, konfiguracja, skalowalność itp.), Aby wziąć pod uwagę, że każdy test porównawczy lub artykuł kończący się "MongoDB jest szybszy niż MySQL" lub na odwrót, generalizowanie wyników do punkt bezużyteczności.

Aby wykonać test porównawczy, najpierw należy zdefiniować ścisły zestaw wymagań funkcjonalnych i reguł biznesowych, a następnie wdrożyć je tak wydajnie, jak to możliwe, w obu rozwiązaniach trwałości. Rezultat będzie taki, że jeden będzie szybszy od drugiego, aw prawie wszystkich przypadkach szybsze podejście ma kilka istotnych wad, które mogą sprawić, że wolniejsze rozwiązanie stanie się bardziej opłacalne w zależności od wymagań.

Wszystko to ignoruje fakt, że powyższy wzorzec nie symuluje żadnego realnego scenariusza. Nie będzie wielu aplikacji wykonujących wstawki o maksymalnej przepustowości bez żadnego wątku/współbieżności (co znacząco wpływa na wydajność większości rozwiązań pamięci masowej).

Wreszcie porównywanie wstawek, takich jak ten, jest również trochę zepsute. MongoDB może osiągnąć niesamowitą przepustowość wkładu dzięki ogniowi i zapomnieć o wkładkach masowych lub może być wolniejsze o wolniejsze woluminy dzięki zsynchronizowanym, replikowanym zapisom. Rzecz w tym, że MongoDB oferuje wybór gdzie MySQL nie ma (lub mniej). Więc tutaj porównanie ma sens tylko z wymogami biznesowymi dotyczącymi ognia i zapominania o typie zapisu (Które sprowadzają się do "Mam nadzieję, że to zadziała, ale bez biggy, jeśli nie")

TL; DR przestań robić proste testy wydajności. Są prawie zawsze bezużyteczne.

+2

+1 za doskonałą odpowiedź, chciałem tylko dodać, że MySQL oferuje mnóstwo silników do przechowywania danych - jednym z nich jest TokuDB, który wykorzystuje fraktalne drzewa, aby uzyskać doskonałą prędkość wstawiania. –

+1

W interesie pełnego ujawnienia chciałbym dodać, że jestem wielkim fanem MongoDB. Ale nie jest to magiczny pocisk bazy danych na wszystko, ani też 10gen nie twierdzi, że tak jest. –

+1

Całkowicie się z Tobą zgadzam, jednak zazwyczaj brak wiedzy decyduje o popularności danego oprogramowania. Czyta się, że MongoDB [wstawia liczbę QPS] więcej niż [wstaw coś, co całkowicie funkcjonalnie nie ma związku z MongoDB], a wszystkie nagłe internety są zanieczyszczone "X jest lepsze niż Y", porównywane przez ludzi bez prawdziwego doświadczenia zawodowego. Właściwe narzędzie do właściwej pracy powinno być mantrą programisty. –

2

Nie należy patrzeć na czas wykonywania pythona i oszacować jakość bazy danych. Każdy wniosek składać się z co najmniej 3 części:

  • żądanie przygotowania (po stronie klienta),
  • wykonanie żądanie (serwer),
  • reakcja wytwarzania (po stronie klienta)

przez moich danych doświadczenia Konwersja dla MongoDB => python zajmuje znacznie więcej czasu niż dla MySQL => python.

Powinieneś także używać indeksów w obu bazach danych. MongoDB działa dobrze tylko wtedy, gdy masz indeksy na polach używanych do zapytań. Mówiąc o MySQL, myślę, że lepiej przetestować wydajność na innoDB, MyISAM nie obsługuje transakcji, kluczy obcych, wyzwalaczy i jak dla mnie jest trochę przestarzały.

+2

Ponieważ chcę używać Pythona, zależy mi na bazie danych + python, a nie tylko bazy danych. – Eric

Powiązane problemy