search

tango-controls-hdbpp / libhdbpp-cassandra

HDB++ library for Apache Cassandra backend. Moved to https://gitlab.com/tango-controls/hdbpp/libhdbpp-cassandra
http://www.tango-controls.org/community/projects/hdbplus
1 stars 1 forks source link

Consistency level #11

Closed johanfforsberg closed 6 years ago

johanfforsberg commented 7 years ago

The library currently has hardcoded the write consistency level to LOCAL_QUORUM. This means that in a three node DC, with replication factor 2, if one node is down it can't write. This hurts reliability, for a gain in consistency.

What do you think about defaulting to LOCAL_ONE instead? As far as I can see, the only drawback would be that it takes a little longer for the cluster to "agree" on the written data. But since there are never any changes to existing points, only new points added, there can't be any real inconsistencies. In the worst case, new data may seem missing for a short time. The gain would be higher performance, and handling node failures in small clusters better.

Of course, ideally, the consistency level should be configurable anyway :)

chedburgh commented 7 years ago

I think we have a to-do to make this configurable. Likely it will be added as a library configuration parameter.

I will take a look how much work it is, if it's straight forward I will add it parameter shortly. That way it can default to what ever we want :)

On Wed, 27 Sep 2017, 17:06 Johan Forsberg notifications@github.com wrote:

The library currently has hardcoded the write consistency level to LOCAL_QUORUM. This means that in a three node DC, with replication factor 2, if one node is down it can't write. This hurts reliability, for a gain in consistency.

What do you think about defaulting to LOCAL_ONE instead? As far as I can see, the only drawback would be that it takes a little longer for the cluster to "agree" on the written data. But since there are never any changes to existing points, only new points added, there can't be any real inconsistencies. In the worst case, new data may seem missing for a short time. The gain would be higher performance, and handling node failures in small clusters better.

Of course, ideally, the consistency level should be configurable anyway :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tango-controls/libhdbpp-cassandra/issues/11, or mute the thread https://github.com/notifications/unsubscribe-auth/AD7ySkyQtbOTPORkZXq_fn2qDyy-HuQDks5smmSKgaJpZM4Pl7Dm .

bourtemb commented 7 years ago

Indeed, there is a TODO to make this configurable. It should not be too complicated to make it configurable. Please note that RF = 2 is usually not recommended because you cannot get strong consistency with high availability with such a replication factor. RF = 3 is the minimum to get strong consistency and high availability. You can refer to this web page to find the best configuration for your needs: https://www.ecyrd.com/cassandracalculator/