OLAP OVER HTTP: как отдавать большие аналитические данные через API и не положить сервис
#ClickHouse #DotNet #HighLoad
✅
OLAP-базу не стоит ставить под каждый пользовательский HTTP-запрос — она захлёбывается на RPS, а не на объёме данных.
📈
Разнеси нагрузку по компонентам: hot storage для частых запросов к свежим данным, S3 для готовых отчётов, ClickHouse для тяжёлой аналитики.
🔹 ClickHouse на стенде (4 ГБ RAM, 6 ядер) держал ~60 RPS при ~80 ms, а на 80 RPS полностью захлёбывался — каждый запрос жрёт максимум ядер, отсюда Thread Contention и Noisy Neighbor.
🔹 Перенос горячих данных (99% запросов) в PostgreSQL дал ~240 RPS и 12 ms против 80 ms — за счёт Index Scan по 0,02% строк на селлера, а кеш отчётов в S3/MinIO вытянул ~750 RPS.
Читаем:
В статье разобраны конкретные подводные камни каждого подхода (пересоздание битого отчёта, 404 против генерации на лету, отсутствие пула соединений для ClickHouse) и расчёт, при каком числе запросов кеширование начинает выигрывать.
https://habr.com/ru/companies/ozontech/articles/1084762/
@aStateOfNet
#ClickHouse #DotNet #HighLoad
✅
OLAP-базу не стоит ставить под каждый пользовательский HTTP-запрос — она захлёбывается на RPS, а не на объёме данных.
📈
Разнеси нагрузку по компонентам: hot storage для частых запросов к свежим данным, S3 для готовых отчётов, ClickHouse для тяжёлой аналитики.
🔹 ClickHouse на стенде (4 ГБ RAM, 6 ядер) держал ~60 RPS при ~80 ms, а на 80 RPS полностью захлёбывался — каждый запрос жрёт максимум ядер, отсюда Thread Contention и Noisy Neighbor.
🔹 Перенос горячих данных (99% запросов) в PostgreSQL дал ~240 RPS и 12 ms против 80 ms — за счёт Index Scan по 0,02% строк на селлера, а кеш отчётов в S3/MinIO вытянул ~750 RPS.
Читаем:
В статье разобраны конкретные подводные камни каждого подхода (пересоздание битого отчёта, 404 против генерации на лету, отсутствие пула соединений для ClickHouse) и расчёт, при каком числе запросов кеширование начинает выигрывать.
https://habr.com/ru/companies/ozontech/articles/1084762/
@aStateOfNet