cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Svihla (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8754) Required consistency level
Date Fri, 06 Feb 2015 17:39:35 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ryan Svihla updated CASSANDRA-8754:
-----------------------------------
    Description: 
Idea is to prevent a query based on a consistency level not being met. For example we can
specify that all queries should be at least CL LOCAL_QUORUM.


Lots of customers struggle with getting all their dev teams on board with consistency levels
and all the ramifications. The normal solution for this has traditionally to build a service
in front of Cassandra that the entire dev team accesses. However, this has proven challenging
for some organizations to do correctly, and I think an easier approach would be to require
a given consistency level as a matter of enforced policy in the database. 

I'm open for where this belongs. The most flexible approach is at a table level, however I'm
concerned this is potentially error prone and labor intensive. It could be a table attribute
similar to compaction strategy.

The simplest administratively is a cluster level, in say the cassandra.yaml

The middle ground is at they keyspace level, the only downside I could foresee is keyspace
explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication
strategy.

  was:
Idea is to prevent a query based on a consistency level not being met.

Lots of customers struggle with getting all their dev teams on board with consistency levels
and all the ramifications. The normal solution for this has traditionally to build a service
in front of Cassandra that the entire dev team accesses. However, this has proven challenging
for some organizations to do correctly, and I think an easier approach would be to require
a given consistency level as a matter of enforced policy in the database. 

I'm open for where this belongs. The most flexible approach is at a table level, however I'm
concerned this is potentially error prone and labor intensive. It could be a table attribute
similar to compaction strategy.

The simplest administratively is a cluster level, in say the cassandra.yaml

The middle ground is at they keyspace level, the only downside I could foresee is keyspace
explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication
strategy.


> Required consistency level
> --------------------------
>
>                 Key: CASSANDRA-8754
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8754
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Ryan Svihla
>
> Idea is to prevent a query based on a consistency level not being met. For example we
can specify that all queries should be at least CL LOCAL_QUORUM.
> Lots of customers struggle with getting all their dev teams on board with consistency
levels and all the ramifications. The normal solution for this has traditionally to build
a service in front of Cassandra that the entire dev team accesses. However, this has proven
challenging for some organizations to do correctly, and I think an easier approach would be
to require a given consistency level as a matter of enforced policy in the database. 
> I'm open for where this belongs. The most flexible approach is at a table level, however
I'm concerned this is potentially error prone and labor intensive. It could be a table attribute
similar to compaction strategy.
> The simplest administratively is a cluster level, in say the cassandra.yaml
> The middle ground is at they keyspace level, the only downside I could foresee is keyspace
explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication
strategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message