Hi folks :wave: We're currently using StarRocks fo...
# questions-and-troubleshooting
a
Hi folks 👋 We're currently using StarRocks for both ingestion and analytical workloads. However, we've observed that during periods of heavy read queries, write operations become delayed or compromised. This is becoming a bottleneck for our pipeline. We're exploring strategies to decouple ingestion and analytical use cases to mitigate this issue. One idea is to maintain two separate StarRocks clusters — an ETL (ingestion) cluster and an Analytical (read-only) cluster. Before we go further down this path, we wanted to ask: • Is there a recommended best practice within the StarRocks community for isolating ingestion from analytical workloads? • Does StarRocks natively support or provide guidance on decoupling reads and writes? • Are there any known production-ready patterns or tools the community uses to achieve this kind of workload isolation? Any guidance, experience, or suggestions would be greatly appreciated! Thanks in advance for your help.
n
I've been attempting a similar setup on a single large node. What has helped me so far was to make use of the resource group functionality to isolate cpu/mem resources based on select, insert, and MV refreshing, the default resource group has no such restriction which may be part of your problem. I have found this alone to significantly improve simultaneous write/read operations. If you are doing heavy upsert/delete on PK tables, this can eat CPU cycles and starve other transactions of resources. You can adjust transaction_apply_worker_count BE config to fix this. By default this maxes out, and is not affected by resource group limitations. It's in the PK table documentation but not the BE config, harder to find: https://docs.starrocks.io/docs/best_practices/primarykey_table/
🙌 2
j
you can try multi-warehouse on shared data mode