Sometimes you can get away with just adding this column to the existing table, but this time as the table is also used to query the order directly, using the whole primary key, this would not be possible with this new version. This table was similar to the table, but just had the timestamp column added. PRIMARY KEY ((location_id, calculation_date), timestamp ,order_id) So a new strategy was devised.įirstly a new table was created: CREATE TABLE location_orders2 ( The team did not want to use counters due to some of the edge cases and not being able to guarantee accuracy. In the example I was looking at, this would have up to 40,000 rows in the partition, and with this query being repeated across locations, it was causing significant pressure on the heap, with too much time spent in garbage collection. Every clustered row within the partition needs to be loaded into memory to be counted. With the query being used something like this: select count(*) from location_orders where location_id = 1 and calculation_date = '' Įven though this is ‘only’ counting within one partition, there is still no quick way for the node to count this data. PRIMARY KEY ((location_id, calculation_date), order_id) The table collected daily orders at a location, and was something like this, but with some additional data columns missing for simplicity: CREATE TABLE location_orders ( This was quite easy to spot as it was a Datastax cluster and the queries were showing up in the node_slow_table. Recently I was looking at the performance of a cluster, and discovered the development team were performing a lot of count(*) additional on a specific table.

Tableplus cassandra