Статьи

Гибридные итоги NoSQL: MarkLogic как магазин KV, часть 2

Мне удалось изменить код Redis-Benchmark, чтобы получить реальные результаты на моем компьютере для последнего сравнения MarkLogic. Читайте дальше для окончательных результатов! Проверьте предыдущий пост здесь.

Я раздвоил код Redis и пропатчил src / redis-benchmark.c, чтобы добавить поддержку команд HSET и HMSET! На самом деле все оказалось намного проще, чем ожидалось, благодаря тому, как хорошо написано использование эталонного теста для поддержки случайных имен ключей и тестовых данных.

Ниже приведены результаты для HSET — установка одного случайного поля для именованного хэша: —

adamfowbookwork:src adamfowler$ ./redis-benchmark -h 192.168.123.4 -n 100000 -r 100000 -t hset -c 50
====== HSET ======
 100000 requests completed in 4.60 seconds
 50 parallel clients
 3 bytes payload
 keep alive: 1

0.00% <= 1 milliseconds
8.01% <= 2 milliseconds
98.28% <= 3 milliseconds
99.69% <= 4 milliseconds
99.81% <= 5 milliseconds
99.89% <= 6 milliseconds
100.00% <= 6 milliseconds
21739.13 requests per second

Ниже приведены результаты для HMSET, устанавливающие 10 полей за один вызов для случайных полей в именованном хеше:

adamfowbookwork:src adamfowler$ ./redis-benchmark -h 192.168.123.4 -n 100000 -r 100000 -t hmset -c 50
====== HMSET (10 keys) ======
 100000 requests completed in 5.85 seconds
 50 parallel clients
 3 bytes payload
 keep alive: 1

0.00% <= 1 milliseconds
0.28% <= 2 milliseconds
71.92% <= 3 milliseconds
97.45% <= 4 milliseconds
99.31% <= 5 milliseconds
99.51% <= 6 milliseconds
99.58% <= 7 milliseconds
99.60% <= 8 milliseconds
99.67% <= 9 milliseconds
99.70% <= 11 milliseconds
99.78% <= 12 milliseconds
99.84% <= 13 milliseconds
99.88% <= 14 milliseconds
99.88% <= 17 milliseconds
99.90% <= 19 milliseconds
99.90% <= 20 milliseconds
99.92% <= 22 milliseconds
99.92% <= 25 milliseconds
99.95% <= 64 milliseconds
99.99% <= 65 milliseconds
100.00% <= 65 milliseconds
17094.02 requests per second

Похоже, что HMSET работает медленнее, но если вы подумаете об этом, вы на самом деле сохраняете 10 частей данных на запрос, так что это чертовски эффективно! 10-кратный объем данных для увеличения производительности примерно на 20%. Неплохо.

Я ожидал, что скорость сохранения документов MarkLogic с 10 полями (элементы XML) будет примерно в 3,5–5 раз выше…

Наши вчерашние результаты по сохранению 100000 10-элементных документов в MarkLogic: 3225,80 в секунду.

Это означает, что для простых агрегатов хэши Redis только в 5,3 раза быстрее, чем MarkLogic. Так что мое предположение не было далеко. Я думаю, ребята из Redis и некоторые ребята сделали некоторую настройку производительности со времени публикации в блоге, на которой я основывал свои факторы производительности!

Другой клиент MarkLogic

MarkLogic Content Pump (MLCP) имеет накладные расходы и, вероятно, не так хорошо настроен, как Redis-Benchmark. Я также скачал и протестировал приложение xmlsh с расширением MarkLogic для xmlsh .

Я все еще читаю файлы с диска, поэтому существует значительный штраф ввода-вывода, от которого не страдает Redis-Benchmark.

Вот файл ingest.sh: —

#!/bin/sh
export XMLSH=./
export MLCONNECT=xcc://admin:admin@192.168.123.4:7777/Documents
export XMODPATH=./ext
date
./unix/xmlsh ./ingest.xh
date

И XMLSH-файл ingest.xh: —

import module ml=marklogic
ml:put -baseuri /test/ -uri "doc{seq}.xml" -x -repair none -maxthreads 20 -maxfiles 30 -r aggregates

Теперь это занимает 28 секунд, что означает общую пропускную способность 3571,43 документов в секунду. Возможно, это можно улучшить, но этого достаточно для моих тестов сегодня.

Использование RamDisk вместо вращающегося диска

После некоторой настройки я создал RamDisk на своем Mac вместо вращающегося жесткого диска и изменил ingest.xh следующим образом:

ml:put -baseuri /test/ -uri "doc{seq}.xml" -x -repair none -maxthreads 20 -maxfiles 30 -r aggregates

Это дало окончательное выполнение через 27 секунд многократно, обеспечивая пропускную способность 3703,70 документов / секунду.

Это означает, что Redis хранит эти очень простые агрегаты в 4,61 раза быстрее, чем MarkLogic.

Примечание: я также назначил 6 ядер (3 ядра — 6 потоков) для образа vmware, чтобы посмотреть, помогло ли это … это не помогло!

Настройка кэшей памяти для минимизации записи на диск

MarkLogic добавляет данные в ячейки памяти и журналы на диск. Это ограничено 16 МБ. Моя загрузка данных составляет около 35 МБ. Изменив размер кэша списка и дерева на 64 МБ, я должен избегать дополнительных штрафов на диск.

Повторный запуск того же теста дает 39 секунд — так медленнее! Это, вероятно, означает, что я нахожусь в пределах погрешности между тестами.

Настройка двух лесов вместо одного

Мои тесты показывают, что я ограничен ЦП, а не IO на MarkLogic Server. Это связано с тем, что потоки сервера приложений блокируются, пока не завершится управляющий поток Forest (shard). Вероятно, идеально подходит для тестирования диска и сети VMWare, поскольку это не узкие места.

Я настрою 2 леса вместо 1 по умолчанию, чтобы сбалансировать эту проблему. Небольшой обман, поскольку Redis работал только на 1 ядре, и это эквивалентно запуску 2 ядер (2 экземпляра Redis), но, тем не менее, интересно.

Я также изменил образ vmware обратно на потоки 4 hw (2 физических ядра), чтобы снова сравнить яблоки с яблоками.

Результаты были … еще 28 секунд. Похоже, что я все еще связан с процессором, и именно в этом заключается проблема моего тестирования.

Что это значит?

Ожидается, что хранилище Key-Value, как правило, будет в 50 раз быстрее, чем хранилище документов, из-за того, как оно работает — мы видим только разницу в производительности до 4,6х. Это в десять раз быстрее (технический термин!). Мы показали, что чем сложнее становятся агрегатные операции, и особенно чем более параноидально вы относитесь к согласованности и долговечности данных, тем ближе производительность двух баз данных.

Это не удивительно. Redis создан для невероятно быстрых запросов на чтение. MarkLogic создан для быстрой, но сложной загрузки запросов — поэтому у них разные характеристики производительности на стороне записи.

Практически это показывает, что хранилище документов, такое как MarkLogic, принципиально не ущемлено в чистой производительности записи. Таким образом, если у вас сложная загрузка запросов или модели данных, используйте MarkLogic, если нет, то смело используйте Redis.

Как улучшить тесты?

Мне бы очень хотелось потратить время на изменение Redis-Benchmark, чтобы можно было рандомизировать как хэш, имена списков и полей, так и значения, чтобы вы могли протестировать обновление и создать рабочие нагрузки. Я сделал это для HMSET, используя случайные имена хешей и полей.

Я также подозреваю, что чем больше агрегаты (больше полей / элементов), тем ближе MarkLogic попадет в Redis. Попытка 100 элементов на хеш / документ может быть полезным тестом. Как будут вложенные хэши, если действительно Redis их поддерживает?

Я также хотел бы, чтобы приложение для сравнительного анализа было написано на C или C ++ для REST API MarkLogic, а не на Java против API XCC — так как это дало бы лучшую производительность клиента и протестировало бы часть сервера, которую будет использовать большинство приложений (REST).

Я подозреваю, что производительность MarkLogic была бы значительно ближе к Redis, если бы использовался лучший клиент — или просто генерировал XML из переменной, а не считывал данные с файловой системы / диска RAM. Тем временем я поищу альтернативу MLCP (Content Pump) и XMLSH.

На самом деле, я сначала добавлю код теста Redis, так как я уверен, что вы захотите поиграть с этими тестами !!! Вот запрос на получение изменений.  Наслаждайтесь!