MySQL против MongoDB 1000 читает

Question

MySQL против MongoDB 1000 читает

231

Я очень волновался о MongoDb и тестировал его в последнее время. У меня была таблица с сообщениями в MySQL с примерно 20 миллионами записей, индексированных только в поле под названием "id".

Я хотел сравнить скорость с MongoDB, и я провел тест, который будет получать и печатать 15 записей случайным образом из наших огромных баз данных. Я запросил около 1000 раз каждый для mysql и MongoDB, и я удивлен, что не вижу большой разницы в скорости. Возможно, MongoDB в 1,1 раза быстрее. Это очень разочаровывает. Есть ли что-то, что я делаю неправильно? Я знаю, что мои тесты не идеальны, но MySQL наравне с MongoDb, когда дело доходит до чтения интенсивных обязанностей.

Примечание:

У меня есть двухъядерный + (2 потока) i7 cpu и 4GB ram
У меня есть 20 разделов на MySQL каждый из 1 миллиона записей

Пример кода, используемый для тестирования 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;
}
?>

Imran Omar Bukhsh 14 март 2012, в 11:46

Источник

0

какой у вас MySQL Query?
Moshe L 14 март 2012, в 13:12
9

Каковы фактические времена?
Abe Petrillo 14 март 2012, в 13:14
0

@Moshe L - This: Выбрать * из сообщений, в которых идентификатор (16,200007,4000004,235002,7567509,63451,19000022,5055501,456776,4564568,8542466,1876544,11237651,7000008,10000007,16000003)
Imran Omar Bukhsh 14 март 2012, в 13:14
22

Я не администратор баз данных, так что это комментарий, а не ответ, но скорость не должна быть основным фактором при выборе между MySQL и MongoDB. Такие вещи, как схема без схемы (т. Е. Как часто нужно менять схему данных) и масштабирование по размеру (т. Е. Насколько легко защитить данные, так что при обычном чтении требуются данные только с одного сервера), важнее для выбора как это.
rossdavidh 14 март 2012, в 13:15
0

Да, для комментария @ rossdavidh. Вы пытались улучшить производительность MySQL, например, разделить таблицу (sharding) и добавить немного логики, чтобы определить, к какой таблице получить доступ?
halfer 14 март 2012, в 13:19
0

@rossdavidh - у нас уже работает система, обслуживающая миллионы посетителей в месяц, сейчас я особенно интересуюсь скоростью чтения, это удивительно, так как я думал, что mongodb будет во много раз быстрее
Imran Omar Bukhsh 14 март 2012, в 13:22
0

@halfer - вопрос больше в том, почему Mongodb не быстрее и не наоборот
Imran Omar Bukhsh 14 март 2012, в 13:25
14

Как это может быть быстрее при чтении? Он читает с механического устройства. Так же, как MySQL. Это зависит от скорости самого устройства, вы не можете использовать какое-то странное волшебство с помощью кода, чтобы выйти за пределы аппаратного обеспечения.
N.B. 14 март 2012, в 13:26
0

Вы используете INNODB? какой у вас размер бассейна? почему не используете Memcache или подобное?
Moshe L 14 март 2012, в 13:38
1

@ ImranOmarBukhsh, действительно. Я пришел к выводу, что не рекомендую вносить изменения ради изменений и предлагать способ повышения производительности с помощью существующей технологии :)
halfer 14 март 2012, в 15:15
1

Вы действительно должны учитывать последовательную задержку на вашем испытательном стенде. Параллелизм является ключевым. Таким образом, если вы ждете, пока запрос вернется, а затем выполните свой следующий запрос, у вас будут накладные расходы на TCP / IP, замедляющие работу. Если вы действительно хотите протестировать производительность, вам нужно огромное количество параллельных вычислений для ОБА движков. В настоящее время я создаю систему поверх MongoDB ... для тестирования, проблема в том, что мы не настроили наш стек TCP и не имеем адекватных тестовых стендов. MongoDB быстрее, чем тот объем трафика, который мы можем в данный момент использовать. Планирование настроить ядро ОС для его обработки. MySQL segfaults.
pestilence669 06 март 2013, в 08:43
6

Этот вопрос только напоминает мне об этом: mongodb-is-web-scale.com
oligofren 09 окт. 2014, в 08:27
0

вы вряд ли получите разумное заключение из такой минимальной системы (если это не ваша целевая платформа). обе базы данных связаны с процессором, поэтому большая часть вашего времени будет потрачена на ожидание выполнения запросов. большее количество процессоров / потоков, скорее всего, даст вам совершенно другой результат, что позволит вам лучше оценить сами базы данных, поскольку они менее ограничены системой. Также обратите внимание, что производительность диска также может стать проблемой. реальный сервер с массивом SSD-дисков может иметь большое значение в таких ситуациях, снова делая минимальную систему узким местом
JSON 29 дек. 2014, в 23:56
0

Делайте больше запросов, чем 1000. Каждая БД может нормально обрабатывать 1000. И запускайте MongoDB в облаке, а не на одной машине ... Так что MongoDB может читать с нескольких дисков, а не только с одного, иначе это будет медленно. Поскольку чтение диска медленное, если не объединено.
Jo Smo 29 янв. 2015, в 16:27
10

Люди ошибаются, что они чувствуют, что они пошли бы с тем или другим. Вам понадобится как микроволновая печь, так и духовка на вашей кухне. Вы просто не можете сказать, что я буду использовать только одно или другое. Варианты использования для обеих систем разные. Если вам требуется ACID для части вашего приложения, используйте RDBMS, если вам не нужны согласованность и ограничения, и ваши объекты могут храниться как все в одном (коллекции), тогда используйте MongoDB. В конечном итоге вы будете использовать гибридную систему, ключевым моментом будет решение, что и где хранить.
Teoman shipahi 04 март 2015, в 17:31

Показать ещё 13 комментариев

Теги:

mysql

mongodb

performance

7 ответов

44

У вас есть concurrency, т.е. одновременные пользователи? Если вы просто запустите запрос в 1000 раз прямо, только с одним потоком, разница почти не будет. Слишком легко для этих двигателей:)

НО Я настоятельно рекомендую вам построить настоящий сеанс тестирования нагрузки, что означает использование инжектора, такого как JMeter, с 10, 20 или 50 пользователями в одно и то же время, чтобы вы могли увидеть разницу (попробуйте встроить этот код внутри веб-страница, которую может запросить JMeter).

Я просто сделал это сегодня на одном сервере (и простой коллекции/таблице), и результаты довольно интересны и удивительны (MongoDb был действительно быстрее при записи и чтении, по сравнению с движком MyISAM и движком InnoDb).

Это действительно должно быть частью вашего теста: concurrency и движок MySQL. Затем, дизайн/приложение схемы и приложения требуют, конечно, огромных требований, не зависящих от времени ответа. Дайте мне знать, когда вы получите результаты, мне также нужны материалы об этом!

theAndroid 02 апр. 2012, в 19:55

38

Можете ли вы поделиться своими результатами?
Imran Omar Bukhsh 03 апр. 2012, в 15:28
1

Да, результаты по этому будут очень полезны
Vasil Popov 28 июнь 2013, в 12:26
2

Конечно, это было бы просто масштабироваться ... если бы это были «Яблоки с яблоками», как они говорили в оставшейся части этой темы. Так что если он на avg выполняет x, теперь симулируйте из нескольких источников, пожалуйста, объясните, почему mongo будет быстрее. т. е. для соглашения просто скажем, что mysql был на avg быстрее для одного запроса ... почему mongo теперь стал быстрее для нескольких? Я не считаю это очень научным. Я говорю, что тест действителен ... но не уверен, насколько велика будет разница, если вы сравниваете яблоки с яблоками, как объясняет остальная часть темы.
Seabizkit 26 фев. 2016, в 13:27

Показать ещё 1 комментарий

17

Источник: 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)

user2081518 16 сен. 2015, в 17:53

71

15 минут, чтобы вставить 10000 строк? Это очень анемичная база данных MySQL. По моему опыту, если такая операция длится 1 с, мой телефон загорается с жалобами. :)
Mordechai 15 нояб. 2015, в 12:31
0

Xtreme Biker взгляните на ссылку. Я отправил тест от других людей с другими настройками.
user2081518 16 нояб. 2015, в 16:05
12

Несколько моментов: 1) Mysql должен быть оптимизирован и правильно настроен, существует множество различных способов вставки больших объемов данных, и при правильном выполнении это может занять 0,1% от 15 минут, см. Эту страницу, например. 2) MongoDB не сразу записывает данные на диск, поэтому он «выглядит» быстрее, но если ваш компьютер дает сбой, данные теряются. 3) Чтение намного быстрее в MySQL
elipoultorak 27 нояб. 2015, в 08:58
0

user3576887 чтение намного быстрее, потому что MySQL может связывать таблицы в одном запросе.
user2081518 27 нояб. 2015, в 10:05
1

@ user3576887 Я думаю, что есть журналы во избежание потери данных ...
mcont 26 март 2016, в 16:39
55

15 минут на 10.000 строк? Вы набрали каждый ряд? знак равно
Iurie Manea 09 янв. 2017, в 23:14
0

@IurieManea это с открытым исходным кодом. Попробуйте сами, lmk ваши результаты. :))
user2081518 07 фев. 2017, в 18:03
1

Для 10000 строк - удалить индексы, вставить, переиндексировать
mbalsam 10 апр. 2017, в 15:40
0

Я знаю, что это старый поток, но несколько лет назад у меня был скрипт, который импортировал 300 000 строк с процессами шифрования в MySQL на рабочем столе - это заняло около 5 минут. Я бы предположил, что этот набор результатов имеет недостатки.
WizPip 17 май 2017, в 15:12
0

Важно отметить, что запросы в этом репо не эквивалентны. Например, запрос поиска для mongo будет запрашивать базу данных для каждого игрока, однако запрос mysql отправит один запрос. Чтобы сделать его более корректным, запрос на монго должен использовать один запрос db.team.find({$in: teamIds}) , где teamIds могут быть teamIds простым отображением: const teamIds = data.map((player) => player.team) .
Andrej Burcev 14 июнь 2017, в 11:39
0

@AndrejBurcev Вы правы, моя цель в этом тесте - проверить перекрестные данные между таблицами.
user2081518 14 июнь 2017, в 17:36
1

Были ли эти INSERTs ?
Rick James 14 авг. 2017, в 16:49
0

Это действительно так медленно? 10K вставить с 15 мин?
Xin Wang 02 нояб. 2017, в 10:51
0

Глядя на источник, я думаю, что нашел источник проблемы. Это полный переход от 1 INSERT к серверу mysql для каждого из 15K, что очень наивно для автора. У меня никогда не было такой вещи, кроме как на лучших стажировках.
Andre Figueiredo 05 март 2018, в 18:27
1

@AndreFigueiredo в реальном мире вы бы пакетировали, если бы у вас были все данные, но для целей профилирования по одному лучше имитировать, как несколько пользователей делают небольшие вставки. Но, двигатель и индексы имеют огромное значение.
Garr Godfrey 08 март 2018, в 18:37
0

Вероятно, используя myisam против innodb, innodb довольно медленно вставляет параметры по умолчанию
WoodyDRN 09 апр. 2018, в 16:53
0

Любой, кто считает, что для вставки десяти строк в mysql требуется 1,7 секунды, заслуживает боль, которую они получают от Монго.
John Haugeland 20 март 2019, в 21:19

Показать ещё 15 комментариев

14

man,, ответ заключается в том, что вы в основном тестируете PHP, а не базу данных.

не утруждайте себя повторением результатов, будь то комментирование печати или нет. там кусок времени.

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

в то время как другой кусок тратится на кучу rand-чисел.

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

    }
    return $numbers;
}

то theres основное различие b/w implode и in.

и, наконец, что здесь происходит. выглядит как создание соединения каждый раз, поэтому его тестирование времени соединения и времени запроса.

$m = new Mongo();

vs

$db = new AQLDatabase();

поэтому ваш 101% быстрее может оказаться на 1000% быстрее для базового запроса, лишенного джаза.

urghhh.

Gabe Rainbow 02 янв. 2014, в 09:09

4

Естественно, практика кодирования может иметь большое значение в любой ситуации, но это не характерно для любого типа языка, API или расширения. генерация случайных чисел перед запуском таймера будет иметь значение, но большую часть времени в этом процессе, несомненно, составляют транзакции базы данных. генерация случайных чисел тривиальна, а базы данных SQL и NoSQL - нет.
JSON 30 дек. 2014, в 00:10
1

не выбирайте номер ранда. очевидно, вы пропустили создание соединения каждый раз. все проблемы сводятся к тестированию чего-то другого, чем предполагалось.
Gabe Rainbow 30 дек. 2014, в 06:10
2

Нет, не пропустил это. MySQL не будет закрывать соединение, пока сценарий не завершится, если не будет вызвана mysqli_close (). В противном случае повторные вызовы mysqli_connect () будут только извлекать существующий ресурс mysql из текущей таблицы ресурсов, а не фиксировать новую процедуру подключения. Я не совсем уверен, что такое объект AQLDatabase, но если он использует библиотеку mysql (что, скорее всего, и делает), он будет вести себя так же. Расширение MongoDB использует пул соединений, поэтому при создании mongodb «соединения» в сценарии происходит то же самое.
JSON 31 дек. 2014, в 23:06
0

Я согласен, что его тест мог быть сделан по-другому, но он отражает те же основные результаты, что и другие тесты MySQL против Mongo, которые я видел. Mongo обычно быстрее при вставке (намного быстрее для более простых вставок), а MySQL обычно быстрее при выборе.
JSON 31 дек. 2014, в 23:24
0

по общему признанию, я был слишком уныл; именно эта строка конкатенации html «<br>» действительно «вызвала» меня. вам не нужна красивая печать в тестах. даже повторение похоже на тест php, а не тест базы данных. в целом, тот момент AQLDatabase «возможно / возможно» ... больше ингредиентов означает больше неизвестных.
Gabe Rainbow 09 янв. 2015, в 00:34

Показать ещё 3 комментария

4

https://github.com/reoxey/benchmark

тест

сравнение скорости MySQL и MongoDB в GOLANG1.6 и PHP5

используемая для эталона: DELL cpu i5 4th gen 1.70Ghz * 4 ram 4GB GPU-RAM 2GB

Сравнение скорости RDBMS vs NoSQL для INSERT, SELECT, UPDATE, DELETE, выполняющих различное количество строк. 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

Reoxey 06 июнь 2016, в 11:43

0

myisam не innodb, а также какая версия mongodb и механизм хранения?
user2312578 19 март 2017, в 12:28
0

важно указать версии MySQL и MongoDB.
Miron 14 авг. 2017, в 06:57
1

Не используйте MyISAM. Используйте пакетные вставки!
Rick James 14 авг. 2017, в 16:48

Показать ещё 1 комментарий

2

Вот небольшое исследование, которое изучало RDBMS vs NoSQL с использованием MySQL против Mongo, выводы были встроены в ответ @Sean Reilly. Короче говоря, преимущество исходит от дизайна, а не от некоторой разницы в скорости. Вывод на стр. 35-36:

RDBMS vs NoSQL: сравнение производительности и масштабирования

Проект тестировал, анализировал и сравнивал производительность и масштабируемость двух типов баз данных. Проведенные эксперименты включали запуская разные числа и типы запросов, некоторые более сложные, чем другие, с тем чтобы проанализировать, как нагрузки. Наиболее важным фактором в этом случае был тип запроса поскольку MongoDB может обрабатывать более сложные запросы быстрее из-за более простая схема при жертве дублирования данных, означающая, что База данных NoSQL может содержать большое количество дубликатов данных. Несмотря на то что можно было бы использовать схему, непосредственно перенесенную из СУБД. исключить преимущество базовых представлений данных MongoDB поддокументы, позволяющие использовать меньше запросов к база данных как таблицы были объединены. Несмотря на увеличение производительности, которое MongoDB имел над MySQL в этих сложных запросах, когда эталон смоделировал запрос MySQL аналогично сложному запросу MongoDB используя вложенные SELECTs MySQL выполнил наилучшее, хотя при более высоких числах соединений, которые оба ведут себя аналогично. Последний тип запроса который был сложным запросом, содержащим два JOINS, и Подзапрос показал преимущество MongoDB над MySQL из-за его использования. вложенные документы Это преимущество достигается за счет дублирования данных что приводит к увеличению размера базы данных. Если такие запросы типичный в приложении, тогда важно рассмотреть NoSQL базы данных как альтернативы при принятии учитывайте стоимость хранения и размер памяти в результате увеличения размер базы данных.

Jason Hitchings 11 апр. 2017, в 19:38

-4

На одном сервере MongoDb не будет быстрее, чем mysql MyISAM для чтения и записи, учитывая таблицу/документ размеры от 1 ГБ до 20 ГБ.
MonoDB будет быстрее на кластерах Parallel Reduce on Multi- Node, где Mysql не может масштабироваться горизонтально.

zhuomin chen 03 окт. 2013, в 20:38

5

Можете ли вы предоставить некоторые доказательства или более подробную информацию, подтверждающую это?
Steven Westbrook 03 окт. 2013, в 20:39
0

Не может масштабироваться по горизонтали? Как насчет NDB? DRBD поддержал MySQL?
Ernestas 11 март 2014, в 19:15
0

Это неправда. MongoDB имеет ограничение в 16MD документов. Mysql может иметь гораздо больше, если хотите
user3480828 31 март 2014, в 11:10

Показать ещё 1 комментарий

Ещё вопросы

@Moshe L - This: Выбрать * из сообщений, в которых идентификатор (16,200007,4000004,235002,7567509,63451,19000022,5055501,456776,4564568,8542466,1876544,11237651,7000008,10000007,16000003)
Я не администратор баз данных, так что это комментарий, а не ответ, но скорость не должна быть основным фактором при выборе между MySQL и MongoDB. Такие вещи, как схема без схемы (т. Е. Как часто нужно менять схему данных) и масштабирование по размеру (т. Е. Насколько легко защитить данные, так что при обычном чтении требуются данные только с одного сервера), важнее для выбора как это.
Да, для комментария @ rossdavidh. Вы пытались улучшить производительность MySQL, например, разделить таблицу (sharding) и добавить немного логики, чтобы определить, к какой таблице получить доступ?
@rossdavidh - у нас уже работает система, обслуживающая миллионы посетителей в месяц, сейчас я особенно интересуюсь скоростью чтения, это удивительно, так как я думал, что mongodb будет во много раз быстрее
@halfer - вопрос больше в том, почему Mongodb не быстрее и не наоборот
Как это может быть быстрее при чтении? Он читает с механического устройства. Так же, как MySQL. Это зависит от скорости самого устройства, вы не можете использовать какое-то странное волшебство с помощью кода, чтобы выйти за пределы аппаратного обеспечения.
Вы используете INNODB? какой у вас размер бассейна? почему не используете Memcache или подобное?
@ ImranOmarBukhsh, действительно. Я пришел к выводу, что не рекомендую вносить изменения ради изменений и предлагать способ повышения производительности с помощью существующей технологии :)
Вы действительно должны учитывать последовательную задержку на вашем испытательном стенде. Параллелизм является ключевым. Таким образом, если вы ждете, пока запрос вернется, а затем выполните свой следующий запрос, у вас будут накладные расходы на TCP / IP, замедляющие работу. Если вы действительно хотите протестировать производительность, вам нужно огромное количество параллельных вычислений для ОБА движков. В настоящее время я создаю систему поверх MongoDB ... для тестирования, проблема в том, что мы не настроили наш стек TCP и не имеем адекватных тестовых стендов. MongoDB быстрее, чем тот объем трафика, который мы можем в данный момент использовать. Планирование настроить ядро ОС для его обработки. MySQL segfaults.
Этот вопрос только напоминает мне об этом: mongodb-is-web-scale.com
вы вряд ли получите разумное заключение из такой минимальной системы (если это не ваша целевая платформа). обе базы данных связаны с процессором, поэтому большая часть вашего времени будет потрачена на ожидание выполнения запросов. большее количество процессоров / потоков, скорее всего, даст вам совершенно другой результат, что позволит вам лучше оценить сами базы данных, поскольку они менее ограничены системой. Также обратите внимание, что производительность диска также может стать проблемой. реальный сервер с массивом SSD-дисков может иметь большое значение в таких ситуациях, снова делая минимальную систему узким местом
Делайте больше запросов, чем 1000. Каждая БД может нормально обрабатывать 1000. И запускайте MongoDB в облаке, а не на одной машине ... Так что MongoDB может читать с нескольких дисков, а не только с одного, иначе это будет медленно. Поскольку чтение диска медленное, если не объединено.
Люди ошибаются, что они чувствуют, что они пошли бы с тем или другим. Вам понадобится как микроволновая печь, так и духовка на вашей кухне. Вы просто не можете сказать, что я буду использовать только одно или другое. Варианты использования для обеих систем разные. Если вам требуется ACID для части вашего приложения, используйте RDBMS, если вам не нужны согласованность и ограничения, и ваши объекты могут храниться как все в одном (коллекции), тогда используйте MongoDB. В конечном итоге вы будете использовать гибридную систему, ключевым моментом будет решение, что и где хранить.
Можете ли вы поделиться своими результатами?
Да, результаты по этому будут очень полезны
Конечно, это было бы просто масштабироваться ... если бы это были «Яблоки с яблоками», как они говорили в оставшейся части этой темы. Так что если он на avg выполняет x, теперь симулируйте из нескольких источников, пожалуйста, объясните, почему mongo будет быстрее. т. е. для соглашения просто скажем, что mysql был на avg быстрее для одного запроса ... почему mongo теперь стал быстрее для нескольких? Я не считаю это очень научным. Я говорю, что тест действителен ... но не уверен, насколько велика будет разница, если вы сравниваете яблоки с яблоками, как объясняет остальная часть темы.
15 минут, чтобы вставить 10000 строк? Это очень анемичная база данных MySQL. По моему опыту, если такая операция длится 1 с, мой телефон загорается с жалобами. :)
Xtreme Biker взгляните на ссылку. Я отправил тест от других людей с другими настройками.
Несколько моментов: 1) Mysql должен быть оптимизирован и правильно настроен, существует множество различных способов вставки больших объемов данных, и при правильном выполнении это может занять 0,1% от 15 минут, см. Эту страницу, например. 2) MongoDB не сразу записывает данные на диск, поэтому он «выглядит» быстрее, но если ваш компьютер дает сбой, данные теряются. 3) Чтение намного быстрее в MySQL
user3576887 чтение намного быстрее, потому что MySQL может связывать таблицы в одном запросе.
@ user3576887 Я думаю, что есть журналы во избежание потери данных ...
15 минут на 10.000 строк? Вы набрали каждый ряд? знак равно
@IurieManea это с открытым исходным кодом. Попробуйте сами, lmk ваши результаты. :))
Для 10000 строк - удалить индексы, вставить, переиндексировать
Я знаю, что это старый поток, но несколько лет назад у меня был скрипт, который импортировал 300 000 строк с процессами шифрования в MySQL на рабочем столе - это заняло около 5 минут. Я бы предположил, что этот набор результатов имеет недостатки.
Важно отметить, что запросы в этом репо не эквивалентны. Например, запрос поиска для mongo будет запрашивать базу данных для каждого игрока, однако запрос mysql отправит один запрос. Чтобы сделать его более корректным, запрос на монго должен использовать один запрос db.team.find({$in: teamIds}) , где teamIds могут быть teamIds простым отображением: const teamIds = data.map((player) => player.team) .
@AndrejBurcev Вы правы, моя цель в этом тесте - проверить перекрестные данные между таблицами.
Это действительно так медленно? 10K вставить с 15 мин?
Глядя на источник, я думаю, что нашел источник проблемы. Это полный переход от 1 INSERT к серверу mysql для каждого из 15K, что очень наивно для автора. У меня никогда не было такой вещи, кроме как на лучших стажировках.
@AndreFigueiredo в реальном мире вы бы пакетировали, если бы у вас были все данные, но для целей профилирования по одному лучше имитировать, как несколько пользователей делают небольшие вставки. Но, двигатель и индексы имеют огромное значение.
Вероятно, используя myisam против innodb, innodb довольно медленно вставляет параметры по умолчанию
Любой, кто считает, что для вставки десяти строк в mysql требуется 1,7 секунды, заслуживает боль, которую они получают от Монго.
Естественно, практика кодирования может иметь большое значение в любой ситуации, но это не характерно для любого типа языка, API или расширения. генерация случайных чисел перед запуском таймера будет иметь значение, но большую часть времени в этом процессе, несомненно, составляют транзакции базы данных. генерация случайных чисел тривиальна, а базы данных SQL и NoSQL - нет.
не выбирайте номер ранда. очевидно, вы пропустили создание соединения каждый раз. все проблемы сводятся к тестированию чего-то другого, чем предполагалось.
Нет, не пропустил это. MySQL не будет закрывать соединение, пока сценарий не завершится, если не будет вызвана mysqli_close (). В противном случае повторные вызовы mysqli_connect () будут только извлекать существующий ресурс mysql из текущей таблицы ресурсов, а не фиксировать новую процедуру подключения. Я не совсем уверен, что такое объект AQLDatabase, но если он использует библиотеку mysql (что, скорее всего, и делает), он будет вести себя так же. Расширение MongoDB использует пул соединений, поэтому при создании mongodb «соединения» в сценарии происходит то же самое.
Я согласен, что его тест мог быть сделан по-другому, но он отражает те же основные результаты, что и другие тесты MySQL против Mongo, которые я видел. Mongo обычно быстрее при вставке (намного быстрее для более простых вставок), а MySQL обычно быстрее при выборе.
по общему признанию, я был слишком уныл; именно эта строка конкатенации html «<br>» действительно «вызвала» меня. вам не нужна красивая печать в тестах. даже повторение похоже на тест php, а не тест базы данных. в целом, тот момент AQLDatabase «возможно / возможно» ... больше ингредиентов означает больше неизвестных.
myisam не innodb, а также какая версия mongodb и механизм хранения?
Не используйте MyISAM. Используйте пакетные вставки!
Можете ли вы предоставить некоторые доказательства или более подробную информацию, подтверждающую это?
Не может масштабироваться по горизонтали? Как насчет NDB? DRBD поддержал MySQL?
Это неправда. MongoDB имеет ограничение в 16MD документов. Mysql может иметь гораздо больше, если хотите

Sean Reilly · Accepted Answer · 2012-03-14T14-57-00.000Z

MongoDB не магически быстрее. Если вы сохраняете одни и те же данные, организованные в основном тем же способом, и получите доступ к нему точно так же, то вам действительно не следует ожидать, что ваши результаты будут совершенно разными. В конце концов, MySQL и MongoDB являются GPL, поэтому, если у Mongo был какой-то волшебный код ввода-вывода, команда MySQL могла бы просто включить его в свою базу кода.

Люди видят работу MongoDB реального мира в значительной степени из-за того, что MongoDB позволяет вам запрашивать другой способ, более разумный для вашей рабочей нагрузки.

Например, рассмотрите дизайн, который сохранял много информации о сложной сущности нормализованным образом. Это может легко использовать десятки таблиц в MySQL (или любой реляционной db) для хранения данных в нормальной форме, с множеством индексов, необходимых для обеспечения реляционной целостности между таблицами.

Теперь рассмотрим тот же дизайн с хранилищем документов. Если все эти связанные таблицы подчинены основной таблице (и они часто бывают), то вы можете смоделировать данные таким образом, чтобы весь объект хранился в одном документе. В MongoDB вы можете хранить это как отдельный документ в одной коллекции. Именно здесь MongoDB начинает обеспечивать превосходную производительность.

В MongoDB для извлечения всего объекта вам необходимо выполнить:

Один индексный поиск в коллекции (при условии, что объект извлекается с помощью id)
Получить содержимое одной страницы базы данных (фактический двоичный json-документ)

Итак, поиск в b-tree и чтение двоичной страницы. Log (n) + 1 IO. Если индексы могут полностью находиться в памяти, тогда 1 IO.

В MySQL с 20 таблицами вы должны выполнить:

Один индексный поиск в корневой таблице (опять же, предполагая, что объект извлекается id)
С кластерным индексом мы можем предположить, что значения для корневой строки находятся в индексе
20 + поиск диапазона (надеюсь, по индексу) для объекта pk value
Они, вероятно, не являются кластеризованными индексами, поэтому те же 20 + поиск данных, когда мы выясним, что представляют собой соответствующие дочерние строки.

Таким образом, общая сумма для mysql, даже если предположить, что все индексы находятся в памяти (что сложнее, чем в 20 раз больше), это около 20 запросов диапазона.

Эти поисковые запросы диапазона, вероятно, состоят из случайных IO - разные таблицы, безусловно, будут находиться в разных местах на диске, и возможно, что разные строки в одном и том же диапазоне в одной таблице для объекта могут не быть смежными (в зависимости от того, как объект обновлен и т.д.).

Итак, для этого примера конечная оценка составляет примерно 20 раз больше ввода-вывода с MySQL для каждого логического доступа по сравнению с MongoDB.

Именно так MongoDB может повысить производительность в некоторых случаях использования.

что если мы просто поместим одну главную таблицу в mysql?
@ariso: это оптимизация путем денормализации. Это может обеспечить повышение производительности. Однако, если вы сделаете это, вы отбросите свой чистый дизайн и всю мощь (не говоря уже о большинстве возможностей) реляционной базы данных. И это действительно работает, пока вы не достигнете предела столбца.
@SeanReilly Ваш пример с сущностями (должен быть отредактирован с объектами, нет объектно-ориентированного программирования :)) неверен. Как сказал Ariso, вы можете сериализовать объект и сохранить его в БД и десериализовать при необходимости (любая форма сериализации). Истинная сила сохраняющихся объектов хранится в odbms, а не в системах documnet db. Но я согласен, что у каждого есть своя собственная цель и сильные стороны (но ваш пример больше запутывает видение и актуальность этой темы).
@GeoC .: Уместно использовать термин «сущность» - это термин из книги «Дизайн, управляемый доменом» Эрика Эванса. en.wikipedia.org/wiki/...
@SeanReilly Я знаю, что вы подразумеваете под «сущностью», просто использование этого термина неуместно в этом контексте. Сущность связана с контекстом более высокого уровня, над объектами. Вы можете сказать, что объект имеет тип Object, поэтому объект будет суперклассом. Сущность - это просто форма Объекта. Я надеюсь, что я понял себя.
Я бы сказал, что 20 объединений - это, вероятно, не самый лучший запрос в наилучшей схеме базы данных.
@SeanReilly Я нашел ваш пример очень полезным. Вы можете создать специальный интерфейс для MySQL, который автоматически сериализует и десериализует объекты в таблицы и ведет себя так, как это делает mongodb. Но тогда почему бы просто не использовать что-то специально разработанное для такого использования? Также ваше использование «сущности» имеет смысл. Дело в том, что вы организуете данные как документы, а не как поля в таблице. Является ли документ объектом, составленным на языке ОО, или нет, это не имеет значения для примера.
@Geo C Это правда, но это сделало бы почти невозможным поиск объектов без сохранения дублированных столбцов, сопоставленных с объектом ... например, если бы группа пользователей хранилась как сериализованный json в реляционном БД, и я хотел быть возможность поиска по электронной почте, имени, возрасту и т. д. Мне понадобится одна или несколько дополнительных таблиц с информацией о дублировании для поиска. Во-вторых, ваши json-объекты были бы наполовину «неизменяемыми» в том смысле, что вам пришлось бы заменить весь объект просто для обновления одного атрибута ... (deserialize-> change-> serialize-> store)