当复制因子 == 集群大小时，Cassandra 分区如何工作？
How does Cassandra partitioning work when replication factor == cluster size?
背景：
我是 Cassandra 的新手，仍在努力了解内部工作原理。
我正在考虑在只有有限数量的节点（少于 10 个，最常见的是 3 个）的应用程序中使用 Cassandra。理想情况下，我的集群中的每个节点都将拥有所有应用程序数据的完整副本。所以，我正在考虑将复制因子设置为集群大小。添加其他节点时，我会更改键空间以增加复制因子设置（nodetool 修复以确保它获得必要的数据）。
我会使用 NetworkTopologyStrategy 进行复制，以利用有关数据中心的知识。
在这种情况下，分区实际上是如何工作的？我读过有关在 Cassandra 中形成环的节点和分区键的组合。如果我的所有节点对于每条数据都是 "responsible" 而不管分区程序计算的哈希值，我是否只有一个分区键的环？
这种类型的 Cassandra 部署是否存在巨大的失败？我猜当数据传播到每个节点时，后台会进行大量异步复制，但这是设计目标之一，所以我同意。
读取的一致性级别通常可能是 "one" 或 "local_one"。
写入的一致性级别通常为 "two"。
要回答的实际问题：
- 复制因子 == 集群大小是否是一种常见的（甚至是合理的）部署策略，除了一个集群的明显情况？
- 我真的有一个分区环，其中分区程序生成的所有可能值都转到一个分区吗？
- 每行数据是否考虑每个节点"responsible"？
- 如果我使用 "one" 的写入一致性，Cassandra 是否总是将数据写入客户端联系的节点？[=34=]
- 这个策略还有其他我不知道的缺点吗？
Do I actually have a ring of one partition where all possible values
generated by the partitioner go to the one partition?
Is each node considered "responsible" for every row of data?
If all of my nodes are "responsible" for each piece of data regardless
of the hash value calculated by the partitioner, do I just have a ring
of one partition key?
不完全是，C* 节点仍然有令牌范围，并且 c* 仍然将主副本分配给“负责”节点。但是所有节点也将有一个 RF = N 的副本（其中 N 是节点数）。所以本质上和你描述的一样。
Are there tremendous downfalls to this type of Cassandra deployment?
Are there other downfalls to this strategy that I don't know about?
我想不到，我猜你可能比一般人更容易受到不一致数据的影响，所以使用 C* 的反熵机制来解决这个问题（修复、读取修复、提示切换）。
一致性级别法定人数或全部将开始变得昂贵，但我看到您不打算使用它们。
Is replication factor == cluster size a common (or even a reasonable)
deployment strategy aside from the obvious case of a cluster of one?
这不常见，我猜您正在寻找超高可用性并且所有数据都适合一个盒子。我认为我从未见过 RF > 5 的 c* 部署。广泛的 RF = 3.
If I were to use a write consistency of "one" does Cassandra always
write the data to the node contacted by the client?
这取决于驱动程序的负载平衡策略。通常我们 select 令牌感知策略（假设您使用的是 Datastax 驱动程序之一），在这种情况下，请求会自动路由到主副本。你可以在你的情况下使用循环法并具有相同的效果。
主要缺点是添加节点时协调器级别的写入成本会增加。我见过的最大写入副本数约为 8（其他数据中心 5 个，本地副本 3 个）。
实际上，这意味着在执行大型或批量写入（大于 1mb）时稳定性会降低，或者每个节点的写入 TPS 会降低。
主要优点是您可以做很多通常很糟糕且不可能做的事情。想使用二级索引？可能会工作得相当好（假设基数和分区大小不会成为你的瓶颈）。想要添加执行 GroupBy 的自定义 UDF 或使用非常大的 IN 查询，它可能会起作用。
正如@Phact 提到的，这不是一种常见的使用模式，我主要看到它与 DSE 搜索一起用于低写入吞吐量用例，这些用例需要 Solr 的 'single node' 功能，但对于那些相同的用例使用纯 Cassandra，您将在读取方面获得一些好处，并且能够执行在更分布式的集群中通常不可能执行的昂贵查询。
背景：
我是 Cassandra 的新手，仍在努力了解内部工作原理。
我正在考虑在只有有限数量的节点（少于 10 个，最常见的是 3 个）的应用程序中使用 Cassandra。理想情况下，我的集群中的每个节点都将拥有所有应用程序数据的完整副本。所以，我正在考虑将复制因子设置为集群大小。添加其他节点时，我会更改键空间以增加复制因子设置（nodetool 修复以确保它获得必要的数据）。
我会使用 NetworkTopologyStrategy 进行复制，以利用有关数据中心的知识。
在这种情况下，分区实际上是如何工作的？我读过有关在 Cassandra 中形成环的节点和分区键的组合。如果我的所有节点对于每条数据都是 "responsible" 而不管分区程序计算的哈希值，我是否只有一个分区键的环？
这种类型的 Cassandra 部署是否存在巨大的失败？我猜当数据传播到每个节点时，后台会进行大量异步复制，但这是设计目标之一，所以我同意。
读取的一致性级别通常可能是 "one" 或 "local_one"。
写入的一致性级别通常为 "two"。
要回答的实际问题：
- 复制因子 == 集群大小是否是一种常见的（甚至是合理的）部署策略，除了一个集群的明显情况？
- 我真的有一个分区环，其中分区程序生成的所有可能值都转到一个分区吗？
- 每行数据是否考虑每个节点"responsible"？
- 如果我使用 "one" 的写入一致性，Cassandra 是否总是将数据写入客户端联系的节点？[=34=]
- 这个策略还有其他我不知道的缺点吗？
Do I actually have a ring of one partition where all possible values generated by the partitioner go to the one partition?
Is each node considered "responsible" for every row of data?
If all of my nodes are "responsible" for each piece of data regardless of the hash value calculated by the partitioner, do I just have a ring of one partition key?
不完全是，C* 节点仍然有令牌范围，并且 c* 仍然将主副本分配给“负责”节点。但是所有节点也将有一个 RF = N 的副本（其中 N 是节点数）。所以本质上和你描述的一样。
Are there tremendous downfalls to this type of Cassandra deployment? Are there other downfalls to this strategy that I don't know about?
我想不到，我猜你可能比一般人更容易受到不一致数据的影响，所以使用 C* 的反熵机制来解决这个问题（修复、读取修复、提示切换）。
一致性级别法定人数或全部将开始变得昂贵，但我看到您不打算使用它们。
Is replication factor == cluster size a common (or even a reasonable) deployment strategy aside from the obvious case of a cluster of one?
这不常见，我猜您正在寻找超高可用性并且所有数据都适合一个盒子。我认为我从未见过 RF > 5 的 c* 部署。广泛的 RF = 3.
If I were to use a write consistency of "one" does Cassandra always write the data to the node contacted by the client?
这取决于驱动程序的负载平衡策略。通常我们 select 令牌感知策略（假设您使用的是 Datastax 驱动程序之一），在这种情况下，请求会自动路由到主副本。你可以在你的情况下使用循环法并具有相同的效果。
主要缺点是添加节点时协调器级别的写入成本会增加。我见过的最大写入副本数约为 8（其他数据中心 5 个，本地副本 3 个）。
实际上，这意味着在执行大型或批量写入（大于 1mb）时稳定性会降低，或者每个节点的写入 TPS 会降低。
主要优点是您可以做很多通常很糟糕且不可能做的事情。想使用二级索引？可能会工作得相当好（假设基数和分区大小不会成为你的瓶颈）。想要添加执行 GroupBy 的自定义 UDF 或使用非常大的 IN 查询，它可能会起作用。
正如@Phact 提到的，这不是一种常见的使用模式，我主要看到它与 DSE 搜索一起用于低写入吞吐量用例，这些用例需要 Solr 的 'single node' 功能，但对于那些相同的用例使用纯 Cassandra，您将在读取方面获得一些好处，并且能够执行在更分布式的集群中通常不可能执行的昂贵查询。