четверг, 6 октября 2011 г.

Mongo vs MsSql часть третья - снова insert

Это третья по счету статья из серии серии, где я пытаюсь сравнить две СУБД Mongo DB и MS SQL. Вот предыдущие части: первая и вторая. Исходники по прежнему лежат на GitHub, а это прямая ссылка на тег с текущим экспериментом. Прошлый раз я забыл сказать, если кто захочет повторить эксперимент у себя, то нужно заменить строку подключения к базе сиквела в классе SqlServerBenchmark (да знаю для этого есть конфиги, но пофиг). База годится любая, но лучше завести чистую :) Все операции по подготовке базы (создание таблиц и их чистка) берет на себя dbullet. Так что для запуска достаточно прописать строку подключения.

Так же немного поменялась конфигурация машины на которой будут проходить эксперименты, теперь это Core2Quad Q6600, 4GB RAM софтверные составляющие не поменялись, и это по прежнему Windows 7 x64, MS SQL Server 2008R2 develop и Mongo DB 2.0.

На этот раз я буду добавлять в базу объекты более приближенные к реальным условиям, чем предыдущий раз:

То есть, объект состоит из кучи полей, как это обычно бывает в реальных приложениях. Количество записей для вставки по прежнему 1000, 5000, 10000, 75000 и 100000, а для Mongo еще и 1000000 в нагрузочку. Также немного переработан механизм запуска, теперь все тесты выполняются за один запуск.

Как и следовало ожидать на подобных объектах Mongo опять в пух и прах разнес сиквел. А вот следующий эксперимент оказался совсем не таким однозначным, как показалось сначала. Суть такова: берем большие объекты такой структуры

При вставке каждое из текстовых полей забивается четырьмя тысячам символов, это где-то 4000*4*2=32000 байт и вставляется как и раньше. Исходники как всегда на Гитхабе - ссылка на тег эксперимета Сначала все происходило как и ожидалось, то есть Mongo обгонял как и раньше. Но вот на миллионе записей Mongo начал вести себя несколько странновато - во первых он съел всю память, которую мог съесть (больше 2ГБ, своп отключен). А дальше стало происходить вообще странное - он забил почти весь диск, на которой лежали файлы базы, что-то около 26ГБ. Работал он долго, но не упал - все перемолол. Ну на самом деле как то так и получается 32000*1000000/1024/1024/1024 = 29,8ГБ. И эти почти тридцать гигов он перелопатил за 12 минут, молодец в общем (винт SSD).

Ну и в виде графиков

Не вписывающиеся в общую картину выпады вниз на втором графике со стороны Mongo объясняются малым количеством установленной памяти (а Бил когда то про 640КБ втирал...). Т.е. эксперименты запускались по порядку и скул не успел еще отпустить занятые им 1.5ГБ, но думаю общую картину это не исказило. Так же нехваткой памяти объясняется и резкий скачок вверх на вставке миллиона записей.

На мой взгляд, эксперимент получился достаточно интересным. Таким образом, любые объекты и в любом количестве Mongo добавляет значительно быстрее сиквела, и чем больше база дынных, тем значительнее преимущество Mongo. Так что подтвердился вывод по возможным областям применения этой СУБД из предыдущего поста.

Разумеется, это не последний эксперимент по сравнению этих двух замечательных СУБД, в следующий раз наверно сравню производительность обновления данных

1 комментарий:

Unknown комментирует...

Срочно добавить поддержку Oracle!

Для своей работы Mongo требует объемы RAM, пропорциональные объемам данных.

Когда уже в кластере будешь тестить? :)