Failing tests 2016-08-05 [cassandra-3.9]

[Joel Knighton]

testall:
  All good!

=

dtest:
  bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
CASSANDRA-12393. Assigned for triage. This looks like
a test issue. Failing on multiple branches.

  materialized_views_test.TestMaterializedViews
  .add_dc_after_mv_network_replication_test
CASSANDRA-12140. Known failure that periodically appears
in a variety of materialized view tests. Assignee
Carl Yeksigian, still being investigated.

=

novnode_dtest:
  bootstrap_test.TestBootstrap.local_quorum_bootstrap_test
Same as above.

  repair_tests.repair_test.TestRepair.test_multiple_concurrent_repairs
CASSANDRA-12395. The failure was due to a test refactor.
Fixed today.

=

dtest_upgrade:
  49 failures were present in today's run, which is an improvement.
  Multiple fixes are in flight; recent runs have improved due
  to the driver fix as well as the merge of CASSANDRA-12236. Several
  test and environmental problems are being investigated.

=

Unit tests are looking very good. We're working through the long
tail of flaky dtest failures and dealing with some amount of regular
churn. Upgrade tests are improving but still a problem area.

Re: Support Multi-Tenant in Cassandra

[jason zhao yang]

We consider splitting by Keypspace or tables before, but Cassandra's table
is a costly structure(more cpu, flush, memory..).

In our use case, it's expected to have more than 50 tenants on same cluster.

> As it was already mentioned in the ticket itself, filtering is a highly 
> inefficient
operation.
I totally agree, but it's to good to have data filtered on server sider,
rather than client side..

How about adding a logical tenant concept in Cassandra?  all logical
tenants will share the same table schemas, but queries/storage are
separated?


Oleksandr Petrov 于2016年7月15日周五 下午4:28写道：

> There's a ticket on filtering (#11031), although I would not count on
> filtering in production.
>
> As it was already mentioned in the ticket itself, filtering is a highly
> inefficient operation. it was thought as aid for people who're exploring
> data and/or can structure query in such a way that it will at least be
> local (for example, with IN or EQ query on the partition key and filtering
> out results from the small partition). However, filtering on the Partition
> Key assumes that _every_ replica has to be queried for the results, as we
> do not know which partitions are going to be holding the data. Having every
> query in your system to rely on filtering, big amount of data and high load
> will eventually have substantial negative impact on performance.
>
> I'm not sure what's the amount of tenants you're working with, although
> I've seen setups where tenancy was solved by using multiple keyspaces,
> which helps to completely isolate the data, avoid filtering. Given that
> you've tried splitting sstables on tenant_id, that might be solved by using
> multiple keyspaces. This will also help with server resource isolation and
> most of the issues you've raised.
>
>
> On Fri, Jul 15, 2016 at 10:10 AM Romain Hardouin
>  wrote:
>
> > I don't use C* in such a context but out of curiosity did you set
> > the request_scheduler to RoundRobin or did you implement your own
> scheduler?
> > Romain
> > Le Vendredi 15 juillet 2016 8h39, jason zhao yang <
> > zhaoyangsingap...@gmail.com> a écrit :
> >
> >
> >  Hi,
> >
> > May I ask is there any plan of extending functionalities related to
> > Multi-Tenant?
> >
> > Our current approach is to define an extra PartitionKey called
> "tenant_id".
> > In my use cases, all tenants will have the same table schemas.
> >
> > * For security isolation: we customized GRANT statement to be able to
> > restrict user query based on the "tenant_id" partition.
> >
> > * For getting all data of single tenant, we customized SELECT statement
> to
> > support allow filtering on "tenant_id" partition key.
> >
> > * For server resource isolation, I have no idea how to.
> >
> > * For per-tenant backup restore, I was trying a
> > tenant_base_compaction_strategy to split sstables based on tenant_id. it
> > turned out to be very inefficient.
> >
> > What's community's opinion about submitting those patches to Cassandra?
> It
> > will be great if you guys can share the ideal Multi-Tenant architecture
> for
> > Cassandra?
> >
> > jasonstack
> >
> >
> >
>
> --
> Alex Petrov
>