我是Cassandra的新手，仍然试图围绕内部工作进行思考。
我正在考虑在一个只有少量节点（少于10个，最常见的是3个）的应用程序中使用Cassandra。理想情况下，我的集群中的每个节点都将拥有所有应用程序数据的完整副本。所以，我正在考虑将复制因子设置为簇大小。添加其他节点时，我会更改键空间以增加复制因子设置（nodetool修复以确保它获取必要的数据）。
我将使用NetworkTopologyStrategy进行复制，以利用有关数据中心的知识。
在这种情况下，分区实际上如何工作？我已经读过在Cassandra中形成环的节点和分区键的组合。如果我的所有节点都对每个数据“负责”而不管分区器计算的哈希值，我是否只有一个分区键的环？
这种类型的Cassandra部署是否有巨大的挫折？我猜测会在后台进行大量的异步复制，因为数据会传播到每个节点，但这是设计目标之一，所以我没关系。
读取的一致性级别通常可能是“一个”或“local_one”。
写入时的一致性级别通常为“2”。
答案 0 :(得分：5)
我实际上是否有一个分区的环，其中包含所有可能的值 由分区程序生成的转到一个分区？
每个节点都被认为对每行数据都“负责”吗？
如果我的所有节点都对每条数据“负责”，无论如何 分区器计算出的哈希值，我只有一个响铃 一个分区键？
不完全是，C *节点仍然具有令牌范围，而c *仍然将主要副本分配给“负责”节点。但是所有节点也将具有RF = N的复制品（其中N是节点数）。所以本质上暗示与你描述的一致。
这种类型的Cassandra部署是否有巨大的挫折？ 我不知道这个战略还有其他垮台吗？
不是我能想到的，我猜你可能比不平均数据更容易受到影响，所以使用C *的反熵机制来解决这个问题（修复，读修复，提示切换）。
一致性级别法定人数或所有会开始变得昂贵，但我发现您不打算使用它们。
复制因子==簇大小是常见的（甚至是合理的） 部署策略除了一个群集的明显情况之外？
这种情况并不常见，我猜您正在寻找超高可用性，并且所有数据都适合放在一个盒子上。我认为我从来没有见过使用RF＆gt;的c *部署。 5.远射和宽射频= 3。
如果我使用“一”的写一致性，Cassandra总是如此 将数据写入客户端联系的节点？
这取决于驱动程序的负载平衡策略。通常我们选择令牌感知策略（假设您正在使用其中一个Datastax驱动程序），在这种情况下，请求会自动路由到主副本。您可以在您的情况下使用循环法并具有相同的效果。
答案 1 :(得分：0)
当您添加节点时，主要的垮台将增加协调员级别的写入成本。写入I的最大副本数大约为8（其他数据中心为5，本地副本为3）。
实际上，这意味着在执行大写或批量写入（大于1mb）或每个节点写入TPS较低时稳定性会降低。
主要优点是你可以做很多通常很糟糕且不可能完成的事情。想要使用二级索引？可能会运行得相当好（假设基数和分区大小不会成为你的瓶颈）。想要添加一个可以进行GroupBy的自定义UDF，或者使用非常大的IN查询，它可能会起作用。
正如@Phact提到的不是常见的使用模式，我主要看到它与DSE Search一起用于低写入吞吐量用例，这些用例需要单个节点＆＃39;来自Solr的功能，但对于纯Cassandra的相同用例，您可以在读取方面获得一些好处，并且能够执行在更分散的群集中通常无法进行的昂贵查询。