假设有一个表，其结构如下：
create table cities (
root text,
name text,
primary key(root,name)
) with clustering order by (name asc); -- for getting them sorted
insert into cities(root,name) values('.','Moscow');
insert into cities(root,name) values('.','Tokio');
insert into cities(root,name) values('.','London');
select * from cities where root='.'; -- get'em sorted asc
当为键空间指定复制因子 3 并使用 RandomPartitioner 时，每行将在 3 个节点上有 3 个副本：由行的哈希确定用于存储的主节点和 2 个下一个节点。为什么要有热点？从所有副本读取负载不平衡？
定义这样一个表的分区键是root while name是一个聚类键。
顾名思义，分区负责分区——分区是如何工作的？
假设您有 4 个节点的集群 - 我们有一个仅生成 8 个键的哈希函数（A、B、C、D、E、F、G、H） - 这是哈希值在集群中的分布方式
节点 1 - (A,B)
节点 2 - (C,D)
节点 3 - (E,F)
节点 4 - (G,H)
每个节点将使用以下 2 个副本作为副本，因此节点 1 的副本为 (2,3)，节点 2 的副本为 (3,4)，节点 3 的副本为 (4,1)，最后节点 4 的副本为(1,2)。
比如说我们的函数hash(root)，当根值为.回报B属于节点 1——节点 1 将存储信息，节点 (2,3) 将存储副本。节点 4 是NEVER参与cities表，由于修复分区键，它不会包含与该表相关的任何数据（不属于该概念的提示情况除外）。在此示例中，您使用了大约 75% 的集群，这可能看起来是可以接受的情况……假设您的应用程序某一时刻因涉及的 3 个节点无法处理读/写请求而受到影响。现在，您可以向集群添加任意数量的节点，但使用此数据模型您将无法水平扩展，因为没有其他节点会参与城市表。在这种情况下，我认为解决您的问题的唯一方法是通过添加更多内存、更强大的 CPU 和 I/O 来增加这 3 个节点的功率（垂直扩展）。创建不允许水平缩放的模式是一种反模式
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
