Is ClickHouse suitable for billing system?

[caram...@gmail.com]

Hi all, I'm considering using ClickHouse for billing system, and it looks like an almost perfect match: big volumes, data only added to DB (no updates or deletes), and lots of queries with aggregations.

However there is one thing that worries me - typical request requires joining other tables, and there could be complex joins, as different customers can have different rates for different services for different time periods. AFAIK ClickHouse doesn't handle joins well, and denormalising data in my situation is problematic, because correct rate not always known by the time service is consumed, therefore any changes to rates result in potentially massive DB updates.

So, my question is: should I use JOIN, or I better store rate data in other DBMS as external dictionary with composite key (account/service/date), or ClickHouse isn't really suitable for my task?

External dictionary looks like a way to go, but in my case it won't be just single table, it may require 5-6 joined tables to find out effective rate for usage record. However, I think I can denormalise rate data in DBMS and flatten it to just one big table (10M+ records), if required.

[Denis Zhuravlev]

>Hi all, I'm considering using ClickHouse for billing system

You should not. CH is not an ACID RDBMS.

[caram...@gmail.com]

>Hi all, I'm considering using ClickHouse for billing system
You should not. CH is not an ACID RDBMS.

I have stream of resource consumption data (after the resource was consumed) that I need to analyse, and calculate the amount due, why would I need ACID for this?