Фактически, сейчас был запощен топик "
", в каком указывалось, что MongoDB превосходит по производительности MySQL в разы. Хех, когда подобное пишут — я сходу лезу испытывать и колебаться. Я полез в исходники необычного теста (благодарю за публикацию). И как оказывается создатель оригинального топика ошибся в 3 знака и в самом деле не все так:
В оригинале: MongoDB быстрее MySQL строчит в 1.пятого раза (Правда, хотя около меня в три раза)
В оригинале: MongoDB быстрее MySQL читает в 10 раз (Недостает, на самом деле — MongoDB приблизительно на равновеликих плюс-минус 10-30
Сопоставление тут выходит лишь как key-value сторидж (запись-чтение по 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 сторидж» (храним по primary key + value, избираем по primary key, читаем value).
Правда, круглый, правда, в вакууме.
Да, снутри теста вслед за тем есть призывы assert и str. Очевидно они отжирают часть производительности, но для обоих исследований — их равное число. А нам же элементарно Поспорить продуктивность надобно.
Более итогов: Core2duo / WinXP SP3 .
Больше 10000 записей тестировал — соответствие хранится. И вроде буква Mongo, ни MyISAM не сдуваются по быстроты.
Я не сообщу, что сто% прав (сможет и я в нежели ошибся), так что проверяйте меня также.
P.S. Да, у меня подборка была поочередная, но если все таки перевести ее на неожиданную ((раз)добывать всякий раз вещество со неожиданным номером) — ситуация обменивается, но не кардинально, размещение мощи все то же. Удостовериться возможно сменив в SELECTах
i1 = str(random.randint(1,cnt-1)+1)
.
В комментах все под Linux + InnoDB_Plugin. Соответствие сил — примерно то же, но глаже:
Linux + InnoDB_Plugin «Core i7 920, 2GB RAM, Fedora 12 x64, mysql 5.1.44 + InnoDB 1.0.6 скомпонованные icc, mongodb 1.2.4 x64, sata диск обыкновенный.»
На запись MongoDB быстрее, если употреблять как key-value сторидж;
Обе системы — достаточно пристойные, никто не обветшал, ни один человек никого не уничтожил, открытого проигрывающего недостает
.
И энтузиазма для присоединена Cassandra + pycassa (под win32) — сразу произнесу — с ней у меня ни малейшего эксперимента и множество малопонятного (.remove() не устраняет записи, а только чистит их, самочки они остаются… + eventual consistency — оооооооочень нелегко испытывать!) — целое прыганье с бубном в темноте, так что считайте просто
веселительным тестом .
import pycassa
client = pycassa.connect()
cf = pycassa.ColumnFamily(client, 'Keyspace1', 'Standard1')

# CASSANDRA INSERT
start_time = time.clock()
for i in xrange(cnt):
i1 = str(i+1)
cf.insert(i1, {'value': i1})
report('Cassandra INSERTs')

list(cf.get_range())

# CASSANDRA SELECT
start_time = time.clock()
for i in xrange(cnt):
i1 = str(i+1)
obj = cf.get(i1)['value']
assert(obj == i1)
report('Cassandra SELECTs')
Йои Хаджи,