Журналы Nginx — справедливые тесты базы данных

Вступление

В этой статье мы рассмотрим еще один тест, добавленный в db-benchmarks — 10+ миллионов стандартных HTTP-логов, собранных Nginx на сайте электронной коммерции zanbil.ir.

Сбор данных

Мы нашли набор данных на https://www.kaggle.com/datasets/eliasdabbas/web-server-access-logs и сочли его очень интересным для тестирования, поскольку набор данных представляет собой очень стандартный журнал доступа Nginx HTTP. Вот пример:

``` ударить

54.36.149.41 - - [22/янв/2019:03:56:14 +0330] "GET /filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C %DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85% DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (совместимый; AhrefsBot/6.1; + http://ahrefs.com/robot/)" "-"

31.56.96.51 - - [22/янв/2019:03:56:16 +0330] "GET /image/60844/productModel/200x200 HTTP/1.1" 200 5667 "https://www.zanbil.ir/m/filter /b113" "Mozilla/5.0 (Linux; Android 6.0; сборка ALE-L21/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36" "-"

31.56.96.51 - - [22/янв/2019:03:56:16 +0330] "GET /image/61474/productModel/200x200 HTTP/1.1" 200 5379 "https://www.zanbil.ir/m/filter /b113" "Mozilla/5.0 (Linux; Android 6.0; сборка ALE-L21/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36" "-"

40.77.167.129 - - [22/янв/2019:03:56:17 +0330] "GET /image/14925/productModel/100x100 HTTP/1.1" 200 1696 "-" "Mozilla/5.0 (совместимый; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

91.99.72.15 - - [22/янв/2019:03:56:17 +0330] "GET /product/31893/62100/%D8%B3%D8%B4%D9%88%D8%A7%D8%B1- %D8%AE%D8%A7%D9%86%DA%AF%DB%8C-%D9%BE%D8%B1%D9%86%D8%B3%D9%84%DB%8C-%D9%85 %D8%AF%D9%84-PR257AT HTTP/1.1" 200 41483 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:16.0)Gecko/16.0 Firefox/16.0" "-"

40.77.167.129 - - [22/янв/2019:03:56:17 +0330] "GET /image/23488/productModel/150x150 HTTP/1.1" 200 2654 "-" "Mozilla/5.0 (совместимо; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

40.77.167.129 - - [22/янв/2019:03:56:18 +0330] "GET /image/45437/productModel/150x150 HTTP/1.1" 200 3688 "-" "Mozilla/5.0 (совместимо; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

40.77.167.129 - - [22/янв/2019:03:56:18 +0330] "GET /image/576/article/100x100 HTTP/1.1" 200 14776 "-" "Mozilla/5.0 (совместимый; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

66.249.66.194 - - [22/янв/2019:03:56:18 +0330] "GET /filter/b41,b665,c150%7C%D8%A8%D8%AE%D8%A7%D8%B1%D9 %BE%D8%B2,p56 HTTP/1.1" 200 34277 "-" "Mozilla/5.0 (совместимый; Googlebot/2.1; +http://www.google.com/bot.html)" "-"

40.77.167.129 - - [22/янв/2019:03:56:18 +0330] "GET /image/57710/productModel/100x100 HTTP/1.1" 200 1695 "-" "Mozilla/5.0 (совместимый; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

207.46.13.136 - - [22/янв/2019:03:56:18 +0330] "GET /product/10214 HTTP/1.1" 200 39677 "-" "Mozilla/5.0 (совместимо; bingbot/2.0; +http:/ /www.bing.com/bingbot.htm)" "-"

40.77.167.129 - - [22/янв/2019:03:56:19 +0330] "GET /image/578/article/100x100 HTTP/1.1" 200 9831 "-" "Mozilla/5.0 (совместимый; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

Большинство веб-сайтов в Интернете, вероятно, имеют аналогичный журнал. Многие администраторы веб-сайтов и DevOps хотят иметь возможность обрабатывать журналы, подобные этому, для фильтрации и аналитики.

После парсинга с помощью framework в логе 11 полей:

• 7 строковых полей

• 4 целочисленных поля

Полный список полей и их типов данных:

"характеристики": {

"remote_addr": {"тип": "текст"},

"remote_user": {"тип": "текст"},

"время выполнения": {"тип": "длинный"},

"time_local": {"тип": "длинный"},

"тип_запроса": {"тип": "текст"},

"путь_запроса": {

"тип": "текст",

"поля": {

"сырой": {

"тип": "ключевое слово"

"запрос_протокол": {"тип": "текст"},

"статус": {"тип": "длинный"},

"размер": {"тип": "длинный"},

"реферер": {"тип": "текст"},

"usearagent": {"тип": "текст"}

Мы предварительно конвертируем необработанный лог в CSV, чтобы его было проще загружать в разные базы данных и поисковики.

Базы данных

На данный момент мы сделали этот тест доступным для 3 баз данных:

• Clickhouse — мощная база данных OLAP,

• Elasticsearch — «движок поиска и аналитики» общего назначения,

• Manticore Search — «база данных для поиска», альтернатива Elasticsearch.

Мы постарались внести как можно меньше изменений в настройки базы данных по умолчанию, чтобы не дать ни одному из них несправедливого преимущества:

• Clickhouse: [без настройки] (https://github.com/db-benchmarks/db-benchmarks/blob/main/tests/logs10m/ch/init), просто CREATE TABLE... ENGINE = MergeTree() ORDER BY id и стандартный образ докера clickhouse-server.

• Elasticsearch: тестируем в 2-х режимах:

• с [без настройки] (https://github.com/db-benchmarks/db-benchmarks/blob/main/tests/logs10m/es/logstash/template.json), что, вероятно, делает большинство пользователей

• с количеством осколков, равным количеству ядер ЦП на сервере , поэтому Elasticsearch может более эффективно использовать ЦП для более низкого времени отклика, поскольку, как сказал в официальном руководстве Elasticsearch «Каждый сегмент выполняет поиск в одном потоке ЦП». Размер набора данных составляет всего 3,5 ГБ, поэтому неясно, нужен он или нет, но именно поэтому мы его тестируем.

• bootstrap.memory_lock=true, поскольку, как сказано в https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#_disable_swapping, это необходимо для повышения производительности.

• образ докера [стандартный] (https://github.com/db-benchmarks/db-benchmarks/blob/main/docker-compose.yml)

• Manticore Search используется в виде [их официального образа докера + предоставляемой ими библиотеки столбцов] (https://github.com/db-benchmarks/db-benchmarks/blob/main/docker-compose.yml):

• мы тестируем построчное хранилище Manticore по умолчанию

• и столбцовое хранилище, поскольку Elasticsearch и Clickhouse не предоставляют хранилища, ориентированные на строки, и, возможно, будет более справедливо сравнить с Manticore, работающей в этом режиме.

• мы добавили secondary_indexes = 1 в конфигурацию, которая включает вторичные индексы при фильтрации (при загрузке данных, которые все равно построены). Поскольку Elasticsearch по умолчанию использует вторичные индексы, и их довольно легко включить в Manticore, имеет смысл это сделать. К сожалению, в Clickhouse пользователю пришлось бы приложить немало усилий, чтобы сделать то же самое, поэтому это не делается, поскольку тогда это будет считаться тяжелой настройкой, которая потребует дальнейшей настройки других баз данных, что сделает все слишком сложным и несправедливым.

Мы также настроили базы данных так, чтобы они не использовали внутренние кеши:

• Кликхаус:

• SYSTEM DROP MARK CACHE, SYSTEM DROP UNCOMPRESSED CACHE, SYSTEM DROP COMPILED EXPRESSION CACHE [после каждого запроса] (https://github.com/db-benchmarks/db-benchmarks/blob/main/plugins/ кликхаус.php).

• Эластичный поиск:

• "index.queries.cache.enabled": false в его конфигурации

• /_cache/clear?request=true&query=true&fielddata=true после каждого запроса.

• Для Manticore Search в конфигурационном файле:

• qcache_max_bytes = 0

• docstore_cache_size = 0

• Операционная система:

• делаем echo 3 > /proc/sys/vm/drop_caches; sync перед каждым новым запросом

Запросы

Запросы в основном аналитические, которые выполняют фильтрацию, сортировку и группировку, но мы также включили один полнотекстовый запрос, который выполняет поиск по URL-адресу запроса:

"выбрать avg(size) avg_size, статус из группы logs10m по порядку статусов по avg_size desc limit 20",

"manticoresearch": "выберите count(*) как cnt, avg(runtime), avg(size) из logs10m, где match('@request_path settings logo') порядок по cnt desc limit 20",

"elasticsearch": "выберите count(*) как cnt, avg(runtime), avg(size) из logs10m, где query('request_path settings logo') упорядочивает по cnt desc limit 20",

"clickhouse": "выберите count(*) как cnt, avg(runtime), avg(size) из logs10m, где (match(request_path, '(?i)(\W|\A)settings\Wlogo(\ \W|\z)') или match(request_path, '(?i)(\W|\A)logo\Wsettings(\W|\z)')) limit 20 FORMAT JSON"

"выбрать количество (*) из logs10m",

"выберите количество (*), среднее (время выполнения) из группы logs10m по ограничению статуса 20",

"выбрать количество (различный путь_запроса) cnt_distinct, статус из группы logs10m по порядку статуса по cnt_distinct desc limit 20",

"выберите min(size) min_size, статус из группы logs10m по порядку статусов по min_size desc, лимит описания статуса 20",

"выберите путь_запроса, время выполнения, статус, размер из logs10m, где размер > 0, порядок по описанию времени выполнения, ограничение размера по возрастанию 20",

"выберите request_path, runtime, status, size, time_local из logs10m в порядке времени выполнения, size desc, time_local desc limit 20",

"выберите статус, количество () из группы logs10m по порядку статуса по количеству () desc limit 20",

"выберите статус, сумму (время выполнения) из группы logs10m по порядку статуса по количеству (*) desc limit 20",

"выбрать count(*) как cnt, request_path, avg(runtime), avg(size) из группы logs10m по порядку request_path по cnt desc limit 20",

"выбрать request_path, count(*), avg(runtime) runtime_avg, avg(size) из группы logs10m по порядку request_path по runtime_avg desc limit 20"

Полученные результаты

Вы можете найти все результаты на странице результатов, выбрав «Тест: logs10m».

Помните, что единственной качественной метрикой является «Fast avg», поскольку она гарантирует низкий [коэффициент вариации] (https://en.wikipedia.org/wiki/Coefficient_of_variation) и большое количество запросов, выполняемых для каждого запроса. Остальные 2 («Самый быстрый» и «Самый медленный») предоставляются без гарантии, поскольку:

• Самый медленный - результат одной попытки, в большинстве случаев самый первый самый холодный запрос. Несмотря на то, что мы очищаем кеш ОС перед каждым холодным запросом, его нельзя считать стабильным. Таким образом, он может использоваться в информационных целях и выделен серым цветом в приведенном ниже резюме.

• Fastest — просто самый быстрый результат, в большинстве случаев он должен быть похож на метрику «Fast avg», но может быть более изменчивым от запуска к запуску.

Помните, что тесты, включая результаты, на 100% прозрачны, как и все в этом проекте, поэтому:

• вы можете использовать [тестовую среду] (https://github.com/db-benchmarks/db-benchmarks), чтобы узнать, как они были созданы

• и найдите необработанные результаты тестов в каталоге results.

В отличие от других менее прозрачных и менее объективных бенчмарков, мы не делаем никаких выводов, мы просто оставляем скриншоты результатов здесь:

3 конкурента сразу без тюнинга

К сожалению, время ожидания Elasticsearch для 2 запросов истекло, поэтому они были исключены из окончательного расчета.

Elasticsearch без настройки по сравнению с поиском Manticore (построчное хранилище по умолчанию)

К сожалению, время ожидания Elasticsearch для 2 запросов истекло, поэтому они были исключены из окончательного расчета.

Elasticsearch без настройки по сравнению с настроенной

К сожалению, время ожидания Elasticsearch для 2 запросов истекло, поэтому они были исключены из окончательного расчета.

Elasticsearch настроен по сравнению с поиском Manticore (построчное хранилище по умолчанию)

К сожалению, время ожидания Elasticsearch для 2 запросов истекло, поэтому они были исключены из окончательного расчета.

Elasticsearch настроен по сравнению с поиском Manticore (столбцовое хранилище)

К сожалению, время ожидания Elasticsearch для 2 запросов истекло, поэтому они были исключены из окончательного расчета.

Clickhouse vs Manticore Search (столбцовое хранилище)

Поиск Manticore по строкам и по столбцам

Отказ от ответственности

Автор этого теста и тестовой среды является членом основной группы Manticore Search, и тест изначально был сделан для сравнения поиска Manticore с Elasticsearch, но, как показано выше, его можно проверить. в открытом исходном коде и самостоятельно запустив тот же тест Manticore Search не получил несправедливого преимущества, поэтому тест можно считать непредвзятым. Однако, если что-то отсутствует или неправильно (т. е. необъективно) в тесте, не стесняйтесь делать запрос на вытягивание или проблему на [Github] (https://github.com/db-benchmarks/db-benchmarks). Ваше мнение оценено! Спасибо, что потратили свое время на чтение этого!

Эта статья была впервые опубликована [здесь] (https://db-benchmarks.com/test-logs10m/)