与Cassandra数据模型的交易

时间:2011-09-04 03:49:14

标签: cassandra consistency eventual-consistency

根据CAP理论,Cassandra最终只能具有一致性。更糟糕的是,如果我们在一次请求中有多次读写而没有正确处理,我们甚至可能失去逻辑一致性。换句话说,如果我们快速做事,我们可能做错了。

同时,为Cassandra设计数据模型的最佳做法是考虑我们将要拥有的查询,然后添加一个CF.通过这种方式,添加/更新一个实体意味着在许多情况下更新许多视图/ CF.没有原子事务功能,很难做到正确。但有了它,我们又失去了A和P部分。

我不认为这涉及很多人,因此我想知道为什么。

  • 这是因为我们总能找到一种方法来设计我们的数据模型,以避免在一个会话中进行多次读写吗?
  • 这是因为我们可以忽略'正确'部分吗?
  • 在实际操作中,我们是否总是在中间某处有ACID功能?我的意思是可能在应用层实现或添加中间件来处理它?<​​/ li>

1 个答案:

答案 0 :(得分:2)

它确实引起了人们的关注,但可能是您正在使用cassandra,因为单个数据库服务器由于扩展或可靠性问题而无法满足您的需求。因此,您不得不解决分布式系统的局限性。

  

在实际操作中,我们是否总是在某处拥有ACID功能   中间?我的意思是可能在应用层实现或添加一个   中间件来处理它?<​​/ p>

不,你通常在其他地方没有酸,因为可能在其他地方也必须分布在多台机器上。相反,您可以围绕分布式系统的限制来设计应用程序。

如果要更新多个列以满足查询,可以查看此演示文稿中的eventually atomic部分,了解有关如何执行此操作的建议。基本上,在写作之前,你已经写了足够的有关cassandra更新的信息。这样,如果写入失败,您可以稍后重试。

如果你能以这种方式构建你的应用程序,那么使用像Zookeeper或cages这样的协调服务可能会很有用。