<p>We have a Cassandra Cluster with 3 pods, in Google Cloud Kubernetes.
Our Cassandra version is 3.9 we are using the Google images.</p>

<p>I got a problem when I tried to create a Materialized View from a table.</p>

<p>The schema of the table is like:</p>

<pre><code>CREATE TABLE environmental_data (
    block_id int,
    timestamp timestamp,
    device_id int,
    sensor_id int,
    .
    .
    .
    PRIMARY KEY (block_id, timestamp, device_id, sensor_id)
</code></pre>

<p>I want to create a view with the device_id as cluster key, I tried to do this:</p>

<pre><code>CREATE MATERIALIZED VIEW environmental_data_by_device AS
       SELECT block_id, timestamp, device_id, sensor_id,... FROM environmental_data
       WHERE block_id is not null
       and timestamp is not null
       and device_id is not null
       and sensor_id is not null
       PRIMARY KEY ((device_id), timestamp, sensor_id, block_id)
       WITH CLUSTERING ORDER BY (timestamp DESC);
</code></pre>

<p>In local with a very small amount of data, everything went well.
But in production with 80 million lines, 2 pods crashed,
and Cassandra looped on this error:</p>

<blockquote>
  <p>Unknown exception caught while attempting to update MaterializedView! environmental_data</p>
  
  <p>java.lang.IllegalArgumentException: Mutation of XXXX bytes is too large for the maximum size of XXXX</p>
</blockquote>

<p><strong>There was also many</strong> <code>java.lang.OutOfMemoryError: Java heap space</code></p>

<p>What can I do to be sure the next try will be successful?
To put down the production Cassandra a second time is not really conceivable.</p>

<p>I already succeed to create a view base on a table but it was not that big.</p>

<p>According to <a href="https://www.datastax.com/dev/blog/understanding-materialized-views" rel="nofollow noreferrer">docs</a>, Cassandra considers updates within the same partition as a single mutation. In your case, I suppose, this means that every new insert with the same device id may result in transferring all the data that was previously written into that partition.
To avoid it, you should consider splitting the data in the mat. view into smaller pieces using the partition key. For example you may introduce minute or hour wide timebuckets depending on the measurement frequency.</p>
