MySQL vs MongoDB 1000 odsłon
Byłem bardzo podekscytowany MongoDb i testowałem go ostatnio. Miałem tabelę o nazwie posts w MySQL z około 20 milionów rekordów indeksowanych tylko w polu o nazwie 'id'.
Chciałem porównać szybkość z MongoDB i przeprowadziłem test, który pobierał i drukował 15 rekordów losowo z naszych ogromnych baz danych. Uruchomiłem zapytanie około 1000 razy dla mysql i MongoDB i jestem zaskoczony, że nie zauważam dużej różnicy w prędkości. Może MongoDB jest 1,1 razy szybszy. To bardzo rozczarowujące. Czy jest coś, co robię źle? Wiem, że moje testy nie są idealne, ale czy MySQL jest na równi z MongoDb, jeśli chodzi o czytanie intensywnych prac.
Uwaga:
- mam dual core + (2 wątki ) procesor i7 i 4GB ram
- mam 20 partycji na MySQL każda po 1 milion rekordów
Przykładowy Kod Używany Do Testowania 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;
}
?>
Przykładowy Kod Do Testowania 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;
}
?>
7 answers
MongoDB nie jest magicznie szybszy. Jeśli przechowujesz te same dane, zorganizowane w zasadzie w ten sam sposób I uzyskujesz do nich dostęp dokładnie w ten sam sposób, naprawdę nie powinieneś oczekiwać, że Twoje wyniki będą szalenie różne. W końcu MySQL i MongoDB są zarówno GPL, więc jeśli Mongo miał magicznie lepszy kod IO, to zespół MySQL mógłby go po prostu włączyć do swojej bazy kodowej.
Ludzie widzą rzeczywistą wydajność MongoDB głównie dlatego, że MongoDB pozwala na zapytanie w innym sposób, który jest bardziej rozsądny dla Twojego obciążenia pracą.
Na przykład rozważ projekt, który przetrwał wiele informacji o skomplikowanej jednostce w znormalizowany sposób. Może to z łatwością wykorzystać dziesiątki tabel w MySQL (lub dowolny relacyjny db) do przechowywania danych w normalnej formie, z wieloma indeksami potrzebnymi do zapewnienia relacyjnej integralności między tabelami.
Rozważmy teraz ten sam projekt z Magazynem dokumentów. Jeśli wszystkie z tych powiązanych tabel są podporządkowane tabeli głównej (i często są), wtedy możesz być w stanie modelować dane tak, aby cały obiekt był przechowywany w jednym dokumencie. W MongoDB można go przechowywać jako pojedynczy dokument, w jednej kolekcji. W tym miejscu MongoDB zaczyna zapewniać najwyższą wydajność.
W MongoDB, aby odzyskać całą istotę, musisz wykonać:
- jedno wyszukiwanie indeksu w kolekcji (zakładając, że encja jest pobierana przez id)
- pobranie zawartości jednej strony bazy danych (aktualnego binarnego json dokument)
Więc Przeglądanie drzewa b i odczyt strony binarnej. Log (n) + 1 IOs. Jeśli indeksy mogą znajdować się w całości w pamięci, to 1 IO.
W MySQL z 20 tabelami musisz wykonać:
- jedno wyszukiwanie indeksu w głównej tabeli (ponownie, zakładając, że encja jest pobierana przez id)
- z indeksem klastrowym możemy założyć, że wartości dla wiersza głównego znajdują się w indeksie
- 20 + szukanie zakresu (miejmy nadzieję na indeks) dla pk podmiotu wartość
- prawdopodobnie nie są to indeksy klastrowe, więc te same 20 + wyszukuje dane, gdy dowiemy się, jakie są odpowiednie wiersze potomne.
Więc suma dla mysql, nawet zakładając, że wszystkie indeksy są w pamięci (co jest trudniejsze, ponieważ jest ich 20 razy więcej) wynosi około 20 przeszukiwań zakresu.
Te przeszukiwania zakresu prawdopodobnie składają się z losowych IO - różne tabele na pewno będą znajdować się w różnych miejscach na dysku i możliwe jest, że różne wiersze w tym samym zakres w tej samej tabeli dla jednostki może nie być przyległy (w zależności od tego, jak jednostka została zaktualizowana, itd.).
Więc dla tego przykładu, ostateczny wynik jest około 20 razy więcej IO z MySQL na dostęp logiczny, w porównaniu do MongoDB.
W ten sposób MongoDB może zwiększyć wydajność W niektórych przypadkach użycia .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-02-11 01:09:58
Czy masz współbieżność, czyli jednoczesnych użytkowników ? Jeśli po prostu uruchomisz 1000 razy zapytanie prosto, z tylko jednym wątkiem, nie będzie prawie żadnej różnicy. Za łatwe dla tych silników:)
Ale zdecydowanie sugeruję, aby zbudować prawdziwą sesję testowania obciążenia, co oznacza użycie wtryskiwacza, takiego jak JMeter z 10, 20 lub 50 użytkownikami w tym samym czasie, aby naprawdę zobaczyć różnicę(spróbuj osadzić ten kod wewnątrz strony internetowej JMeter może zapyta).
Zrobiłem to dzisiaj na singlu serwer (i prosta kolekcja / tabela ) i wyniki są dość ciekawe i zaskakujące (MongoDb był naprawdę szybszy na pisze & czyta, w porównaniu do MyISAM engine i InnoDb engine).
To naprawdę powinno być częścią twojego testu: concurrency & MySQL engine. Następnie, dane / Schematy projekt i potrzeby aplikacji są oczywiście ogromne wymagania, poza czasem reakcji. Daj mi znać, gdy otrzymasz wyniki, ja również Potrzebuję informacji na ten temat!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-02 19:07:10
Źródło: https://github.com/webcaetano/mongo-mysql
10 wierszy
mysql insert: 1702ms
mysql select: 11ms
mongo insert: 47ms
mongo select: 12ms
100 wierszy
mysql insert: 8171ms
mysql select: 10ms
mongo insert: 167ms
mongo select: 60ms
1000 wierszy
mysql insert: 94813ms (1.58 minutes)
mysql select: 13ms
mongo insert: 1013ms
mongo select: 677ms
10.000 wierszy
mysql insert: 924695ms (15.41 minutes)
mysql select: 144ms
mongo insert: 9956ms (9.95 seconds)
mongo select: 4539ms (4.539 seconds)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-16 10:41:33
Człowieku,, odpowiedź jest taka, że w zasadzie testujesz PHP, a nie bazę danych.
Nie przejmuj się iteracją wyników, niezależnie od tego, czy komentujesz druk, czy nie. jest kawał czasu.
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;
}
Wtedy jest duża różnica B / w implode i in.
I wreszcie, co się tu dzieje. wygląda na tworzenie połączenia za każdym razem, a więc jego testowanie czasu połączenia plus zapytanie czas.
$m = new Mongo();
Vs
$db = new AQLDatabase();
Więc twoje 101% szybsze może okazać się 1000% szybsze dla podstawowego zapytania.
Urghhh.Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-01-02 08:13:09
Https://github.com/reoxey/benchmark
Benchmark
Porównanie prędkości MySQL & MongoDB w GOLANG1. 6 i PHP5
System używany do testów porównawczych: DELL cpu i5 4th gen 1.70 Ghz * 4 ram 4GB GPU ram 2GB
Porównanie prędkości RDBMS vs NoSQL dla INSERT, SELECT, UPDATE, DELETE wykonując inną liczbę wierszy 10,100,1000,10000,100000,1000000
Język używany do wykonania to: PHP5 & Google fastest language 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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-06 09:54:29
Oto małe badania, które zbadały RDBMS vs NoSQL za pomocą MySQL vs Mongo, wnioski były zgodne z odpowiedzią @Sean Reilly. Krótko mówiąc, korzyści wynikają z projektu, a nie z jakiejś surowej różnicy prędkości. Wniosek na stronie 35-36:
RDBMS vs NoSQL: porównanie wydajności i skalowania
Projekt przetestował, przeanalizował i porównał wydajność i skalowalność dwóch typów baz danych. Przeprowadzone eksperymenty obejmowały bieganie inaczej Liczby i rodzaje zapytań, niektóre bardziej złożone niż innych, w celu analizy sposobu skalowania baz danych ze zwiększoną ładuj. Najważniejszym czynnikiem w tym przypadku był zastosowany typ zapytania ponieważ MongoDB mógł szybciej obsługiwać bardziej złożone zapytania, głównie ze względu na jego prostszy schemat przy poświęceniu duplikacji danych, co oznacza, że Baza danych NoSQL może zawierać duże ilości duplikatów danych. Chociaż można by użyć schematu bezpośrednio migrowanego z RDBMS wyeliminuj zaletą podstawowej reprezentacji danych MongoDB jest subdokumentów, co pozwoliło na wykorzystanie mniejszej ilości zapytań do bazy danych jako tabele zostały połączone. pomimo przyrostu wydajności, który MongoDB miał nad MySQL w tych złożonych zapytaniach, gdy benchmark modelował zapytanie MySQL podobnie jak złożone zapytanie MongoDB przez korzystanie z zagnieżdżonych wybiera MySQL najlepiej, chociaż przy większych liczbach z połączeń oba zachowywały się podobnie. ostatni typ zapytania benchmarked czyli złożone zapytanie zawierające dwa łączniki oraz subquery pokazały przewagę MongoDB nad MySQL ze względu na wykorzystanie subdokumenty. Ta zaleta wiąże się z kosztem powielania danych co powoduje zwiększenie rozmiaru bazy danych. Jeśli takie zapytania są typowe w aplikacji wtedy ważne jest, aby wziąć pod uwagę NoSQL bazy danych jako alternatywy podczas przyjmowania obliczyć koszt w pamięci i wielkość pamięci wynikającą z większego rozmiar bazy danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-11 17:43:46
Na pojedynczym serwerze MongoDb nie byłby szybszy od mysql MyISAM zarówno przy odczycie jak i zapisie, podana tabela / doc
rozmiary są małe od 1 GB do 20 GB.
MonoDB będzie szybszy na równoległym Reduce na klastrach Wielowęzłowych, gdzie Mysql nie może skalować poziomo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-03 20:21:42