External authentication options for C* (no DSE)

Hi, while for DSE versions of C* it's quite clear what external authentication options are available, I'm not sure about DSC or Apache versions. Can anyone point me to the right documentation on or provide a list of possibilities? Thank you in advance. giampaolo

Re: External authentication options for C* (no DSE)

Search a bit deeper in DSE docs, I've found this: http://www.datastax.com/wp-content/themes/datastax-2014-08/files/FF-DataStax-AdvancedSecurity.pdf . Pratically no external authentication is available for Apache Cassandra. giampaolo 2015-12-23 15:13 GMT+01:00 Giampaolo Trapasso <

RE: Cassandra 3.1 - Aggregation query failure

It shouldn’t be called an aggregate. That is more like a user defined function. If you are correct, the term “aggregate” will lead people to do “bad things” – just like secondary indexes. I think the dev team needs a naming expert. Sean Durity – Lead Cassandra Admin From: Robert Stupp

Re: Cassandra 3.1 - Aggregation query failure

Well, the usual access goal for queries in C* is “one partition per query” - maybe a handful partitions in some cases. That does not differ for aggregates since the read path is still the same. Aggregates in C* are meant to move some computation (for example on the data in a time-frame

RE: Cassandra 3.1 - Aggregation query failure

An aggregate only within a partition? That is rather useless and shouldn’t be called an aggregate. I am hoping the functionality can be used to support at least “normal” types of aggregates like count, sum, avg, etc. Sean Durity – Lead Cassandra Admin From: Jonathan Haddad

Re: Write/read heavy usecase in one cluster

I would personally classify both of those use cases as light, and I wouldn’t have any qualms about using a single cluster for both of those. On Dec 23, 2015, at 3:06 PM, cass savy wrote: > How do you determine if we can share cluster in prod for 2 different > applications

Re: Write/read heavy usecase in one cluster

While I would normally suggest splitting different systems to different hardware, you can easily get away with using 3 rather small machines for this workload. Just be sure to not use SimpleStrategy so you can split the keyspaces out to different clusters later if you need to. On Wed, Dec 23,

Re: Cassandra 3.1 - Aggregation query failure

Thanks for the pointer on internal paging Tyler, I missed this one. But then it raises some questions: 1. Is it possible to "tune" the page size or is it hard-coded internally ? 2. Is read-repair performed on EACH page or is it done on the whole requested rows once they are fetched ? Question 2.

Write/read heavy usecase in one cluster

How do you determine if we can share cluster in prod for 2 different applications 1. Has anybody shared cluster in prod a write heavy use case that captures user login info (few 100 rpm) and hardly performs few reads per day and Use case that is read heavy use case that is 92% read with 10k

Re: What is the ideal way to merge two Cassandra clusters with same keyspace into one?

Is there a way to keep writetime and ttl of each record as it is in new cluster? Thanks and Regards Noorul On Mon, Dec 21, 2015 at 5:46 PM, DuyHai Doan wrote: > For cross-cluster operation with the Spark/Cassandra connector, you can look > at this trick: >

Re: Cassandra 3.1 - Aggregation query failure

Even if aggregation that forces a full table scan across partitions is not recommended, the message/exception does seems unrelated to partitioning: cqlsh:flightdata> select late_flights(uniquecarrier, depdel15) from flightsbydate in ('2015-09-15', '2015-09-16', '2015-09-17',