Clickhouse, Elasticsearch и Manticore: время поискового запроса с 1,7 млрд поездок на такси в Нью-Йорке

Поездки на такси в Нью-Йорке (NYC), вероятно, являются наиболее часто используемым ориентиром в области анализа данных.

Все началось с того, что [Тодд В. Шнайдер] (https://toddwschneider.com/) решил подготовить коллекцию [впервые в 2015 году] (https://toddwschneider.com/posts/analyzing-1-1-billion-nyc- Taxi-and-uber-trips-with-a-vengeance/) для анализа 1,1 миллиарда поездок такси и Uber в Нью-Йорке. Затем [Марк Литвинчик] (https://tech.marksblogg.com/) продолжил тестирование [множества баз данных и поисковых систем] (https://tech.marksblogg.com/benchmarks.html), используя сбор данных.

Теперь мы в DB Benchmarks докеризованная подготовка сбора данных, чтобы упростить его использование, и сделать его доступным как часть наиболее прозрачного и [набора тестов баз данных с открытым исходным кодом] (https://github.com/db-benchmarks/db-benchmarks).

Сбор данных

Сбор данных охватывает 1,7 миллиарда поездок на такси и арендованных транспортных средствах (Uber, Lyft и т. д.) из Нью-Йорка с 2009 года. Большинство [необработанных данных] (https://www1.nyc.gov/site/tlc /about/tlc-trip-record-data.page) предоставлено Комиссией по такси и лимузинам Нью-Йорка.

Запись сбора данных включает множество различных атрибутов поездки на такси:

• Дата и время получения

• Координаты посадки и высадки

• Названия мест посадки и высадки

• Комиссия и сумма чаевых

• Скорость ветра, глубина снега

• И многие другие поля

Его можно использовать в основном для тестирования аналитических запросов, но он также включает в себя несколько полнотекстовых полей, которые можно использовать для тестирования возможностей свободного текста в базах данных.

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

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

"vendor_id": {"тип": "ключевое слово"},

"pickup_datetime": {"тип": "дата", "формат": "эпоха_секунда"},

"dropoff_datetime": {"тип": "дата", "формат": "эпоха_секунда"},

"store_and_fwd_flag": {"тип": "ключевое слово"},

"rate_code_id": {"тип": "целое число"},

"pickup_longitude": {"тип": "плавающий"},

"pickup_latitude": {"тип": "плавающий"},

"dropoff_longitude": {"тип": "плавающий"},

"dropoff_latitude": {"тип": "плавающий"},

"passenger_count": {"тип": "целое число"},

"trip_distance": {"тип": "плавающий"},

"fare_amount": {"тип": "плавающая"},

"дополнительно": {"тип": "плавающий"},

"mta_tax": {"тип": "плавающий"},

"tip_amount": {"тип": "плавающая"},

"tolls_amount": {"тип": "плавающая"},

"eail_fee": {"тип": "плавающий"},

"improvement_surcharge": {"тип": "плавающий"},

"total_amount": {"тип": "с плавающей запятой"},

"payment_type": {"тип": "ключевое слово"},

"trip_type": {"тип": "byte"},

"пикап": {"тип": "ключевое слово"},

"dropoff": {"тип": "ключевое слово"},

"cab_type": {"тип": "ключевое слово"},

"дождь": {"тип": "поплавок"},

"snow_depth": {"тип": "плавающий"},

"снегопад": {"тип": "поплавок"},

"max_temp": {"тип": "байт"},

"min_temp": {"тип": "байт"},

"ветер": {"тип": "поплавок"},

"pickup_nyct2010_gid": {"тип": "целое число"},

"pickup_ctlabel": {"тип": "ключевое слово"},

"pickup_borocode": {"тип": "байт"},

"pickup_boroname": {"тип": "ключевое слово"},

"pickup_ct2010": {"тип": "ключевое слово"},

"pickup_boroct2010": {"тип": "ключевое слово"},

"pickup_cdeligibil": {"тип": "ключевое слово"},

"pickup_ntacode": {"тип": "ключевое слово"},

"pickup_ntaname": {"тип": "текст", "поля": {"сырье": {"тип":"ключевое слово"}}},

"pickup_puma": {"тип": "ключевое слово"},

"dropoff_nyct2010_gid": {"тип": "целое число"},

"dropoff_ctlabel": {"тип": "ключевое слово"},

"dropoff_borocode": {"тип": "байт"},

"dropoff_boroname": {"тип": "ключевое слово"},

"dropoff_ct2010": {"тип": "ключевое слово"},

"dropoff_boroct2010": {"тип": "ключевое слово"},

"dropoff_cdeligibil": {"тип": "ключевое слово"},

"dropoff_ntacode": {"тип": "ключевое слово"},

"dropoff_ntaname": {"тип": "текст", "поля": {"сырье": {"тип":"ключевое слово"}}},

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

Базы данных

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

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

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

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

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

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

• Elasticsearch: здесь, чтобы было справедливо сравнить с другими базами данных, которые мы [должны были помочь Elasticsearch] (https://github.com/db-benchmarks/db-benchmarks/blob/main/tests/taxi/es/logstash_tuned/ template.json) по:

• позволить ему создать 32 осколка: ("number_of_shards": 32`), иначе он не сможет использовать ЦП с 32 ядрами на сервере, поскольку, как [сказано] (https://www.elastic.co/guide /en/elasticsearch/reference/current/size-your-shards.html#single-thread-per-shard) в официальном руководстве Elasticsearch «Каждый сегмент выполняет поиск в одном потоке ЦП».

• 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 также используется в виде [их собственного образа докера + предоставляемой ими библиотеки столбцов] (https://github.com/db-benchmarks/db-benchmarks/blob/main/docker-compose.yml):

• а также с Elasticsearch мы также используем 32 шарда в виде 32 простых индексы

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

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

• Кликхаус:

• 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 перед каждым новым запросом

Запросы

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

"ВЫБЕРИТЕ количество (*) ИЗ такси, где pickup_ntaname = '0'",

"SELECT pickup_ntaname, count(*) c FROM Taxi GROUP BY pickup_ntaname ORDER BY c desc limit 20",

"SELECT cab_type, count(*) c FROM Taxi GROUP BY cab_type заказать c desc LIMIT 20",

"ВЫБЕРИТЕ количество пассажиров, среднее (общее количество) ОТ такси СГРУППИРОВАТЬ ПО количеству пассажиров по заказу по описанию LIMIT 20",

"ВЫБЕРИТЕ количество (*) ОТ такси, ГДЕ tip_amount > 1,5",

"ВЫБРАТЬ avg(tip_amount) FROM Taxi WHERE tip_amount > 1.5 AND tip_amount < 5",

"SELECT rain, avg(trip_distance) a FROM Taxi GROUP BY rain order by desc LIMIT 20",

"manticoresearch": "ВЫБЕРИТЕ * ИЗ такси, где соответствует ('гарлемский восток') LIMIT 20",

"clickhouse": "ВЫБЕРИТЕ * ИЗ такси, где соответствует (dropoff_ntaname, '(?i)\WHarlem\WEast\W') или соответствует (pickup_ntaname, '(?i)\WHarlem\WEast\W' ) ПРЕДЕЛ 20",

"elasticsearch": "ВЫБЕРИТЕ * ИЗ такси, где запрос('гарлем восток') LIMIT 20"

"ВЫБЕРИТЕ среднее (общая_сумма) ОТ такси, ГДЕ trip_distance = 5",

"ВЫБЕРИТЕ среднее (общая_сумма), количество (*) ОТ такси, ГДЕ trip_distance > 0 И trip_distance < 5",

"ВЫБЕРИТЕ количество (*) ИЗ такси, где pickup_ntaname != '0'",

"выберитеpassage_count, count(*) c из группы такси по порядкуpassage_count по c desc limit 20",

"выбрать дождь, count(*) c из группы такси по порядку дождя по c desc limit 20",

"ВЫБЕРИТЕ количество (*) из такси, где pickup_ntaname = 'Верхний Вест-Сайд'",

"ВЫБРАТЬ * из лимита такси 5",

"ВЫБЕРИТЕ количество (*) ОТ такси, ГДЕ tip_amount = 5",

"ВЫБЕРИТЕ среднее (общая_сумма) ИЗ такси"

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

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

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

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

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

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

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

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

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

Все три конкурента одновременно

Clickhouse против Elasticsearch

Поиск Manticore и Elasticsearch

Поиск Мантикоры против Clickhouse

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

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

Также опубликовано здесь.