cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12245) initial view build can be parallel
Date Thu, 09 Nov 2017 01:34:00 GMT


Paulo Motta commented on CASSANDRA-12245:

Getting back to this after a while, sorry about the delay. We are really close now, I think
we can wrap up after this last round of review. See follow-up below:

bq. This makes a lot of sense. I'm worried about creating thousands of tasks for large datasets
if the number of tasks is relative to the amount of data. Instead, I think we could fix the
number of partitions to the higher reasonable number of parallel tasks, something like a multiple
of the number of available processors. This would provide the desired immediate performance
improvement if the user increases the number of concurrent view builders while keeping the
number of tasks limited, independently of the amount of data. What do you think? Does it make
any sense?

Awesome! One minor thing is that we should probably only split the view build tasks at all
if the base table is larger than a given size (let's say 500MB or so?), to avoid 4 * num_processor
flushes for base tables with negligible size, WDYT?

bq. One case that we hadn't considered is that if the token ranges change or are split in
a different way when resuming a build then the progress would be lost, because ViewBuildTask
won't found any entry for the new range at system.view_builds_in_progress. This would be specially
true if we split the ranges by their data size. So, independently of how we finally split
the ranges, I think it makes sense to load all the ranges with any progress from system.view_builds_in_progress
at ViewBuilder before splitting the local ranges, create a task for those of them that are
not already finish, and then split any remaining uncovered local range. It also has the advantage
of skipping the creation of tasks for already completed ranges. What do you think?

Good idea! This will prevent a node from computing new tasks for already built subranges if
a new node joins the ring during view build. I will add a dtest to verify that scenario on

bq. I have also removed the method SystemKeyspace.beginViewBuild because I don't see any need
of saving a range without progress. Indeed, if the view build is restarted it is probably
better to don't restore the task without progress and let their tokens to be processed by
the split logic. 


bq. The first wait does the opposite to _wait_for_view, it waits until there is some progress.
But we can use self._wait_for_view("ks", "t_by_v") here. Did you mean that?


bq. Makes sense. The new test for ViewBuilderTask is here, and I've extended ViewTest.testViewBuilderResume
to run with different number of concurrent view builders.

Awesome, this looks much better now, thanks!

I had a final skim through the patch and I think we covered everything and this looks much
more robust now. Three minor things before we can close this:
- I noticed we don't stop in-progess view builds when a view is removed, would you mind adding
- ViewBuildExecutor is being constructed with minThreads=1 and maxPoolSize=concurrent_materialized_view_builders,
but according to the {{DebuggableThreadPoolExecutor}}'s' [javadoc|],
this will actually make the executor with size 1 since maxPoolSize is not supported by {{DebuggableThreadPoolExecutor}}
- and even if it were, new threads would only be created after the queue of the initial threads
were full (which is quite unintuitive), but we actually want the pool to have concurrent_materialized_view_builders
concurrent threads at most, so we should use the {{threadCount}} constructor instead - at
some point we should actually remove the maximumPoolSize constructors from the TPE's since
it can be quite confusing.
- In the linked dtest branch results, {{base_replica_repair_with_contention_test}} is showing
the following error:
ERROR [InternalResponseStage:1] 2017-10-11 11:03:16,005 - Exception
in thread Thread[InternalResponseStage:1,5,main]
java.lang.RuntimeException: org.apache.cassandra.db:type=Tables,keyspace=ks,table=t
	at org.apache.cassandra.db.ColumnFamilyStore.<init>( ~[main/:na]
	at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(
	at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(
	at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(
	at org.apache.cassandra.db.Keyspace.initCf( ~[main/:na]
	at org.apache.cassandra.db.Keyspace.<init>( ~[main/:na]
	at ~[main/:na]
	at ~[main/:na]
	at org.apache.cassandra.service.StorageService.getRangesForEndpoint(
	at org.apache.cassandra.service.StorageService.getLocalRanges( ~[main/:na]
	at ~[main/:na]
	at org.apache.cassandra.db.view.ViewBuilder.loadStatusAndBuild( ~[main/:na]
	at org.apache.cassandra.db.view.ViewBuilder.<init>( ~[main/:na]
	at ~[main/:na]
	at org.apache.cassandra.db.view.ViewManager.reload( ~[main/:na]
	at org.apache.cassandra.db.Keyspace.<init>( ~[main/:na]
	at ~[main/:na]
	at ~[main/:na]
	at org.apache.cassandra.schema.Schema.createKeyspace( ~[main/:na]
	at java.util.HashMap$Values.forEach( ~[na:1.8.0_144]
	at java.util.Collections$UnmodifiableCollection.forEach( ~[na:1.8.0_144]
	at org.apache.cassandra.schema.Schema.merge( ~[main/:na]
	at org.apache.cassandra.schema.Schema.mergeAndAnnounceVersion( ~[main/:na]
	at org.apache.cassandra.schema.MigrationTask$1.response( ~[main/:na]
	at ~[main/:na]
	at ~[main/:na]
	at java.util.concurrent.Executors$ ~[na:1.8.0_144]
	at ~[na:1.8.0_144]
	at java.util.concurrent.ThreadPoolExecutor.runWorker( ~[na:1.8.0_144]
	at java.util.concurrent.ThreadPoolExecutor$ [na:1.8.0_144]
	at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(
	at ~[na:1.8.0_144]
Caused by: org.apache.cassandra.db:type=Tables,keyspace=ks,table=t
	at com.sun.jmx.mbeanserver.Repository.addMBean( ~[na:1.8.0_144]
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(
	at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean( ~[na:1.8.0_144]
	at org.apache.cassandra.db.ColumnFamilyStore.<init>( ~[main/:na]
	... 31 common frames omitted

I think we could take a {{buildAllViews}} parameter on reload, and set that to false during
Keyspace initialization, since views will be build during daemon initialization and keyspace
changes anyway, WDYT?

After these nits are addressed, feel free to rebase + squash and prepare for commit and submit
a final round of CI. Thanks!

> initial view build can be parallel
> ----------------------------------
>                 Key: CASSANDRA-12245
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Materialized Views
>            Reporter: Tom van der Woerdt
>            Assignee: Andrés de la Peña
>             Fix For: 4.x
> On a node with lots of data (~3TB) building a materialized view takes several weeks,
which is not ideal. It's doing this in a single thread.
> There are several potential ways this can be optimized :
>  * do vnodes in parallel, instead of going through the entire range in one thread
>  * just iterate through sstables, not worrying about duplicates, and include the timestamp
of the original write in the MV mutation. since this doesn't exclude duplicates it does increase
the amount of work and could temporarily surface ghost rows (yikes) but I guess that's why
they call it eventual consistency. doing it this way can avoid holding references to all tables
on disk, allows parallelization, and removes the need to check other sstables for existing
data. this is essentially the 'do a full repair' path

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message