Мой фривольный перевод этой статьи
Моя команда сейчас работает над проектом, где мы будем использовать MongoDB в качестве хранилища. Для оценки мы протестировали произвидительность записи в RavenDB и MongoDB, и сравнили результаты, которые мы нашли очень интересными.
Но перед тем, как я поделюсь ими, я бы хотел подчеркнуть, что это не обязательный критерий для основания выбора технологии, это просто результаты, которые мы находим интересными, технология выбора должна основываться на большем, чем на производительности...
Сейчас мы имеем продукт, основанный на SQLServer, котрый получает финансовые данные из фида. Этот фид - xml файл, размером около 400 Мб, который мы получаем ежедневно и содержит данные, состоящие из 45 тыс. фондов. Мы парсим этот файл и строим объектную модель, которая выглядит так:
Такой же тест был проделан с RavenDB (single instance) на рабочей машине с одним четырехядерным процессором, восемью гигабайтами ОЗУ с обычным SSD диском ))
Лучше оригинал:
We modelled this entire graph as a single document and saved them in batches of 200 which we found to be the optimum batch size after many runs.
Время сохранения этих документов составило 2 минуты и 37 секунд, впечатляет!
Raven & Mongo разные звери со своими способами хранения/извлечения данных, которые нужно понимать до принятия решения об их примении.
Моя команда сейчас работает над проектом, где мы будем использовать MongoDB в качестве хранилища. Для оценки мы протестировали произвидительность записи в RavenDB и MongoDB, и сравнили результаты, которые мы нашли очень интересными.
Но перед тем, как я поделюсь ими, я бы хотел подчеркнуть, что это не обязательный критерий для основания выбора технологии, это просто результаты, которые мы находим интересными, технология выбора должна основываться на большем, чем на производительности...
Сейчас мы имеем продукт, основанный на SQLServer, котрый получает финансовые данные из фида. Этот фид - xml файл, размером около 400 Мб, который мы получаем ежедневно и содержит данные, состоящие из 45 тыс. фондов. Мы парсим этот файл и строим объектную модель, которая выглядит так:
SQLSERVER
В SQL каждый из этих объектов связан с другой таблицей, как и следовало ожидать.
Наше средство импорта парсит файл, строит связи и сохраняет структуру для каждого найденного фонда в фиде. Это занимает около 25 минут. Добавлю к этому, что там есть еще несколько других неописанных вещей, так что 25 минут не является подлинным отражением времени.
Профилирование проходило на продакшн-серверах, снабженных восемью четырехядерными CPU с 32 Гб ОЗУ на борту, с хорошо настроенной сетью хранения данных
Наше средство импорта парсит файл, строит связи и сохраняет структуру для каждого найденного фонда в фиде. Это занимает около 25 минут. Добавлю к этому, что там есть еще несколько других неописанных вещей, так что 25 минут не является подлинным отражением времени.
Профилирование проходило на продакшн-серверах, снабженных восемью четырехядерными CPU с 32 Гб ОЗУ на борту, с хорошо настроенной сетью хранения данных
RAVENDB
Такой же тест был проделан с RavenDB (single instance) на рабочей машине с одним четырехядерным процессором, восемью гигабайтами ОЗУ с обычным SSD диском ))
Лучше оригинал:
We modelled this entire graph as a single document and saved them in batches of 200 which we found to be the optimum batch size after many runs.
Время сохранения этих документов составило 2 минуты и 37 секунд, впечатляет!
MONGODB
Тест был модифицирован для MongoDB (single instance) and запущен на той же машине что и RavenDB. Мы включили SafeMode и ждали подтверждения записи документа.
Время сохранения этих документов составило 14 секунд….Wow!
Время сохранения этих документов составило 14 секунд….Wow!
Итого
Raven & Mongo разные звери со своими способами хранения/извлечения данных, которые нужно понимать до принятия решения об их примении.
P.S.: Сорри за корявый перевод, инглишем владею скудно
Комментариев нет:
Отправить комментарий
Можете оставить свой комментарий