МongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ

Веб разработка - Работа с БД

Собственно, сегодня был запощен топик Сравниваем производительность MongoDB и MySQL на простом примере , в котором указывалось, что MongoDB превышает по производительности MySQL в разы. Хех, когда такое пишут — я сразу лезу проверять и сомневаться. Я полез в исходники оригинального теста (спасибо за публикацию). И как оказалось автор оригинального топика сделал ошибку в три символа и на самом деле не все так:

Сравнение здесь происходит только как key-value storage (запись-чтение по primary key).


На графике — число операций в секунду, (больше — лучше), шкала логарифмическая.
Последняя строка — то, что тестировал автор оригинального топика (неправильное, не в критику — все мы ошибаемся и учимся).

А теперь подробнее об ошибке...

Итак, ошибка оригинала была в том, что он делал SELECT так:

test.find({'_id':random.randrange(1, 999999)})

что возвращало Cursor(!), но не сам объект. То есть обращение к базе не происходит (или по крайней мере чтения данных не происходит). А вот что надо было:

test.find({'_id':random.randrange(1, 999999)})[0]

Если бы автор проверял бы, что сохраненное значение (INSERT) равняется вытащенному (SELECT) — такой ошибки не было бы.

В своем тесте я добавил assert, проверяющий что то, что сохранили — то же, что и читаем. И добавил сравнение с InnoDB (в комментах многие спорили, что может быть намного лучше). Настройки InnoDB дефолтовые.

Сам тест: по сути оба в качестве «key-value storage» (сохраняем по primary key + value, выбираем по primary key, читаем value). Да, сферический, да, в вакууме.

Да, внутри теста там есть вызовы assert и str. Разумеется они отжирают часть производительности, но для обоих тестов — их одинаковое число. А нам же просто СРАВНИТЬ производительность надо.