ClickHouse ці TimescaleDB: адзін графік перамог насуперак агульнаму бенчмарку

У параўнанні Арада Сурэша на адным хосце з 10 млн згенераваных паказанняў сціснуты TimescaleDB прачытаў шэраг адной пазнакі за 57 мс супраць 77 мс у ClickHouse, а агрэгацыю па ўсіх пазнаках ClickHouse выканаў за 167 мс супраць 1955 мс у сціснутым TimescaleDB. ClickHouse таксама хутчэй загрузіў аднолькавы файл. Замеры паказваюць перавагу розных сістэм у розных задачах, а не агульнага пераможцу.

Калі асноўная праца — загружаць паток і падлічваць паказчыкі па многіх датчыках, ClickHouse варта разглядаць першым. Калі часцей адкрываюць асобны шэраг, выпраўляюць старыя запісы і злучаюць вымярэнні з бізнес-табліцамі PostgreSQL, моцны кандыдат — TimescaleDB. Рашэнне залежыць ад прапорцыі гэтых запытаў і ад таго, як арганізаваны даныя ў кожнай базе.

Чаму вузкі шэраг мяняе парадак

Графік асобнага датчыка адбірае паказанні па адной пазнацы і абмежаваным інтэрвале часу. Шырокая агрэгацыя праходзіць па многіх пазнаках і групуе значна больш значэнняў. Таму вынік для агульнай панэлі не прадказвае, як хутка адкрыецца графік канкрэтнага датчыка, хоць абодва запыты звяртаюцца да тых самых паказанняў.

У згаданым тэсце вымяралі найлепшыя запускі з прагрэтым кэшам. Гэта дапамагае параўнаць формы запытаў у адной канфігурацыі, але не апісвае затрымку пры халодным кэшы, паралельнай працы карыстальнікаў або іншым размеркаванні паказанняў. Згенераваныя пазнакі таксама не гарантуюць такой самай лакальнасці даных, як рэальныя датчыкі ці фінансавыя інструменты.

Чытанне шэрагу адной пазнакі трэба адрозніваць ад пошуку апошняга значэння для кожнай пазнакі. У першым выпадку фільтр звужае набор загадзя; у другім база павінна знайсці свежы радок у кожнай групе. Сцісканне ў гэтым тэсце дапамагло вузкаму чытанню TimescaleDB, але запыт апошніх значэнняў па ўсіх пазнаках застаўся хутчэйшым у ClickHouse.

Як схема ўплывае на затрымку

ClickHouse чытае калонкі, патрэбныя для запыту, таму добра адпавядае падліку па вялікім наборы радкоў. Афіцыйны разбор часовых шэрагаў ClickHouse паказвае, як ключ сартавання, тыпы даных, кодэкі і матэрыялізаваныя прадстаўленні ўплываюць на запыты. Калі часты фільтр задае датчык і час, размяшчэнне гэтых палёў у ключы можа скараціць чытанне; для паўтаральнай агрэгацыі можна загадзя захоўваць яе вынік.

TimescaleDB выкарыстоўвае PostgreSQL-гіпертэбліцу, падзеленую на часавыя чанкі. Апісанне Hypercore ад Tiger Data тлумачыць пераход ад радковага захоўвання новых запісаў да сціснутага калонкавага захоўвання старэйшых чанкаў, сегментацыю ўнутры іх і змяненне даных з транзакцыйнай семантыкай PostgreSQL. Для вузкага запыту важна, ці супадае поле датчыка з полем сегментацыі; само сцісканне хуткасці не гарантуе.

Для фінансавых шэрагаў ролю датчыка можа выконваць сімвал інструмента, для метрык — ідэнтыфікатар сэрвісу. Калі частыя запыты фільтруюць па гэтым полі, яно ўплывае на карысць ад сартавання ў ClickHouse і сегментацыі ў TimescaleDB. Калі запыт праходзіць па ўсіх сутнасцях, перавага такой арганізацыі можа быць меншай.

Матрыца пяці нагрузак

Для выбару базы важныя самастойныя віды працы. Перавага ў матрыцы азначае кандыдата для пілота, а не абяцанне хуткасці на любой схеме.

• Масавая ўстаўка. Для вялікага патоку запісаў, якія пераважна дадаюцца, першым кандыдатам будзе ClickHouse: у разгляданым тэсце ён хутчэй загрузіў файл. Пачатковая загрузка, аднак, адрозніваецца ад бесперапыннага паступлення невялікіх пакетаў разам з чытаннямі. Калі такая сумесь характэрная для сістэмы, вымяраць трэба яе.
• Шырокая агрэгацыя. Падлік па ўсіх датчыках або інструментах схіляе выбар да ClickHouse, асабліва калі панэль часта скануе сырыя паказанні за доўгі перыяд. Калі вынік падрыхтоўваюць загадзя, у параўнанне ўваходзіць і кошт яго абнаўлення пасля новых або запозненых запісаў.
• Апошняе значэнне. Адзін датчык і ўсе датчыкі — розныя запыты. Хуткі графік асобнага шэрагу ў TimescaleDB не азначае, што ён гэтак жа хутка верне свежы радок для кожнай групы. Тут істотныя форма SQL, індэксы, ключ сартавання і тое, ці захоўваецца дапаможны вынік.
• Выпраўленне старых радкоў. Калі паказанні ўдакладняюць пасля запісу, TimescaleDB дае знаёмую мадэль абнаўленняў PostgreSQL, у тым ліку для даных у калонкавым сховішчы. Перавагу варта ацэньваць разам з коштам выпраўленняў і наступных чытанняў: у бенчмарку загрузкі без такіх змен гэтая частка нагрузкі не вымяраецца.
• JOIN з бізнес-табліцамі. Калі вымярэнні рэгулярна злучаюцца з табліцамі прылад, кліентаў або правоў доступу, TimescaleDB дазваляе працаваць з імі ў PostgreSQL. ClickHouse таксама можа выконваць JOIN, але пры асобным аналітычным сховішчы трэба ўлічыць дастаўку і актуальнасць бізнес-даных у ім.

Уласны A/B-пілот

Пілот павінен паўтарыць сумесь запытаў, якая сапраўды нагружае сістэму. Акадэмічны бенчмарк SciTS даследуе загрузку і затрымку пяці практычных запытаў для чатырох рухавікоў, сярод якіх ClickHouse і TimescaleDB. Яго падыход карысны тым, што разглядае некалькі формаў працы, а не адзін зводны час.

1. Загрузіце ў абедзве базы аднолькавы фрагмент рэальных даных. Захавайце ў ім звычайныя і рэдкія шэрагі, пропускі і запозненыя паказанні. Зафіксуйце схемы, ключы, індэксы, правілы сціскання і даступныя рэсурсы, каб было зразумела, што менавіта параўноўваецца.
2. Выкарыстоўвайце запыты для ўсіх работ з матрыцы. Для апошняга значэння падрыхтуйце асобныя запыты па адной сутнасці і па ўсіх; для JOIN вазьміце тую бізнес-табліцу, з якой сістэма злучае паказанні ў звычайнай працы.
3. Пускайце ўстаўку і чытанне адначасова ў прапорцыях, блізкіх да вытворчых. Вымярайце павольныя адказы разам з тыповай затрымкай, а таксама выкарыстанне працэсара, памяці і дыска. Асобна праверце вынік з прагрэтым і халодным кэшам.
4. Пасля позняга запісу і выпраўлення старога значэння параўнайце не толькі час, але і правільнасць адказаў. Выніковае рашэнне прывязвайце да запыту, затрымка якога важная карыстальніку, і да кошту падтрымкі дадатковай базы, калі яна спатрэбіцца.

Чытайце таксама:

• Cursor ці GitHub Copilot: тып задачы важнейшы за агульны рэйтынг
• PostgreSQL ці MySQL: адзін бенчмарк не выбірае базу на гады
• Штомесячны ліст інвестару: просьба аб дапамозе важнейшая за доўгі пералік перамог