OK, so in the end I elected to go for option (c), which makes my table
definition look like this:
create table tenanted_foo_table (
tenant ascii,
application_key bigint,
timestamp timestamp,
other non-key columns
PRIMARY KEY ((tenant, application_key), timestamp)
)
such t
Astyanax and/or the DS Java client depending on your use case. (Emphasis on
the "and" - really no reason you can't use both - even on the same schema -
depending on what you are doing as they both have their strengths and
weaknesses).
To be clear, Hector is not going away. We are still accepting p
Nate,
(slightly OT), what client API/library is recommended now that Hector is
sunsetting? Thanks.
Regards,
Shahab
On Wed, Nov 13, 2013 at 9:28 AM, Nate McCall wrote:
> You basically want option (c). Option (d) might work, but you would be
> bending the paradigm a bit, IMO. Certainly do not u
You basically want option (c). Option (d) might work, but you would be
bending the paradigm a bit, IMO. Certainly do not use dedicated column
families or keyspaces per tennant. That never works. The list history will
show that with a few google searches and we've seen it fail badly with
several cli
Hi,
I've just received a requirement to make a Cassandra app
multi-tenanted, where we'll have up to 100 tenants.
Most of the tables are timestamped wide row tables with a natural
application key for the partitioning key and a timestamp key as a
cluster key.
So I was considering the options:
(a)
