Сравниваем MongoDB с MySql как Key-Value

Уговорили меня включить MongoDB в сравнение баз данных для Key-Value (смотрите PostgreSQL, MySql and MariaDB as Key-Value storage).

Оказалось, что MongoDB использует для хранения данных отображение памяти в файлы, поэтому для баз больше 2G, надо использовать 64-bit архитектуру.
После того как узнал это, надо было сразу выкинуть MongoDB, но все таки решил проложить. Поставил FreeBSD 9.0 amd64 и для чистоты эксперимента прогнал некоторые тесты для MySql и PostgreSql.

Решил тестировать только на коротких ключах (подробности смотрите тут BerkeleyDB и TokyoCabinet).

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

Результаты:
Чтение где-то в 2 раза медленней, чем у MySql.
Вставка также медленней, но периодически скорость вставки настолько замедляется, что даже не удается вставить запись в течении 30 секунд!

Поиск информации интернете показал, что это проблеме не связана с FreeBSD и наблюдается и под Linux.
А может это такой Perl модуль? Но ведь автор его является также разработчиком ядра MongoDB!

Некоторые значения полей отличаются после извлечения из базы. Может MongoDB чудит, считая, что это utf8.

Выводы.
MongoDB, с диском надо работать как с диском, а не как с памятью!
MySql и PostgreSql - фавориты. А в PostgreSql 9.2 появился index only scan, - так что PostgreSql еще повысил свою привлекательность.

Как люди работают с MongoDB? Или у них базы маленьких относительно оперативной памяти?

PostgreSQL, MySql and MariaDB as Key-Value storage

После сравнения BerkeleyDB и TokyoCabinet настало время посмотреть на PostgreSQL, MySql и MariaDB как на хранилища ключ-значения.

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

PostgreSQL


postgresql-server v9.1.2

SET synchronous_commit TO OFF
commit_delay = 1

Во всех вариантах PostgreSQL заметно быстрей чем BerkeleyDB и TokyoCabinet! Разумеется это, когда объем базы превышал размер оперативной памяти.

С ростом базы замечено существенное снижение производительности, когда используется btree индекс.
Поэтому для очень больших баз и когда этого достаточно, стоит использовать hash индекс.


MySql and MariaDB


Для perl модуля DBD::mysql используется патч https://rt.cpan.org/Public/Bug/Display.html?id=76462,
чтобы при mysql_server_prepare не было утечки памяти.

mysql-server-5.1.61
mariadb-server-5.2.10

У сравнении участвовали:
MyISAM
ARIA
XtraDB (Innodb_flush_log_at_trx_commit=0)

HandlerSocket не использовался.

На маленьких базах и длинных ключах TokyoCabinet hash (не btree) быстрей в 3-5 раз чем MyISAM, ARIA и XtraDB.
На коротких ключах MyISAM быстрей в 5 раз.

Когда базы большие, то MySql and MariaDB вырываются вперед, даже XtraDB быстрей, чем TokyoCabinet.

Как и у PostgreSQL, с ростом базы замечено существенное снижение производительности, когда используется btree индекс.
Преимущества hash индекса (XtraDB) не сказалось, в отличие от PostgreSQL.


Выводы


Когда базы маленькие можно использовать TokyoCabinet или BerkeleyDB.
Когда данных больше, то стоить посмотреть в сторону MyISAM, ARIA (MariaDB) или PostgreSQL.
Когда базы огромные, то лучше использовать PostgreSQL с HASH индексами.