本文探讨了Apache Cassandra中的数据分区，强调了主键定义、分区键的作用以及数据分区对集群性能的影响。文章提供了分区键设计的最佳实践，建议保持分区大小在100MB以下，避免无界分区和分区偏斜，以优化Cassandra集群的可伸缩性和性能。
cassandra 优化
Apache Cassandra是一个数据库。 但这不仅仅是任何数据库； 它是一个为可伸缩性，高可用性，低延迟和性能而设计和调整的复制数据库。 Cassandra可以帮助您的数据在区域中断，硬件故障以及许多管理员认为过多数据的情况下幸免。
掌握完备的数据分区命令可以使您实现出色的Cassandra集群设计，性能和可伸缩性。 在本文中，我将研究如何定义分区以及Cassandra如何使用它们，以及您应注意的最关键的最佳实践和已知问题。
Cassandra中的数据分区
Cassandra作为分布式系统运行，并遵守上述数据分区原则。 使用Cassandra，数据分区取决于在群集级别配置的算法和在表级别配置的分区键。
Cassandra查询语言（CQL）使用熟悉SQL表，行和列术语。 在上面的示例图中，表配置在其主键中包括分区键，其格式为：主键=分区键+ [群集列]。
Cassandra中的主键既代表唯一的数据分区，又代表分区内的数据排列。 数据排列信息由可选的群集列提供。 每个唯一的分区键代表服务器中管理的一组表行以及管理其副本的所有服务器。
在CQL中定义主键
以下四个示例演示了如何用CQL语法表示主键。 这些定义所产生的行集通常被视为分区。
定义1（分区键：log_hour，集群列：无）
CREATE
TABLE server_logs
(
log_hour
TIMESTAMP PRIMARYKEY
,
log_level text
,
message text
,
server text
)
在这里，所有共享log_hour的行都进入同一分区。
定义2（分区键：log_hour，集群列：log_level）
CREATE
TABLE server_logs
(
log_hour
TIMESTAMP
,
log_level text
,
message text
,
server text
,
PRIMARY
KEY
( log_hour
, log_level
)
)
此定义使用与定义1相同的分区键，但此处每个分区中的所有行均按log_level升序排列。
定义3（分区键：log_hour，服务器，集群列：无）
CREATE
TABLE server_logs
(
log_hour
TIMESTAMP
,
log_level text
,
message text
,
server text
,
PRIMARY
KEY
(
( log_hour
, server
)
)
)
在此定义中，所有行将每个不同的服务器共享一个log_hour作为一个分区。
定义4（分区键：log_hour，服务器，集群列：log_level）
CREATE
TABLE server_logs
(
log_hour
TIMESTAMP
,
log_level text
,
message text
,
server text
,
PRIMARY
KEY
(
( log_hour
, server
)
, log_level
)
)
WITH CLUSTERING
ORDER
BY
( column3
DESC
) ;
此定义使用与定义3相同的分区，但按log_level降序排列分区中的行。
Cassandra如何使用分区键
Cassandra依赖于分区键来确定在哪个节点上存储数据以及在需要时将数据放置在何处。 Cassandra通过查看表中的分区键并使用令牌（范围从-2 ^ 63到+ 2 ^ 63-1的长值）进行数据分配和索引来执行这些读取和写入操作。 这些令牌通过使用分区程序映射到分区键，该分区程序应用了分区功能，该功能将任何分区键转换为令牌。 通过这种令牌机制，Cassandra群集的每个节点都拥有一组数据分区。 然后，分区键将在每个节点上启用数据索引。
具有三个节点和基于令牌的所有权的Cassandra集群。 这是一个简单的表示：实际的实现使用Vnodes 。
数据分区对Cassandra集群的影响
仔细的分区键设计对于实现用例的理想分区大小至关重要。 正确设置它可以实现均匀的数据分发和强大的I / O性能。 分区大小对您需要注意的Cassandra群集有几个影响：
- 读取性能-为了在磁盘上的SSTables文件中查找分区，Cassandra使用的数据结构包括缓存，索引和索引摘要。 太大的分区会降低维护这些数据结构的效率，从而对性能产生负面影响。 Cassandra发行版在这方面取得了长足的进步：特别是，Cassandra引擎的3.6版及更高版本引入了存储方面的改进，这些改进可为大型分区提供更好的性能，并具有抵御内存问题和崩溃的弹性。
- 内存使用-大分区对JVM堆施加了更大的压力，增加了它的大小，同时也使垃圾回收机制的效率降低。
- Cassandra修复-大分区使Cassandra很难执行其修复维护操作，该操作通过比较跨副本的数据来保持数据的一致性。
- 驱逐墓碑-听起来并不那么卑鄙，Cassandra使用称为“墓碑”的独特标记来标记要删除的数据。 如果没有适当的数据删除模式和压缩策略，那么大的分区会使删除过程变得更加困难。
尽管这些影响可能会让您很想去简单地设计产生特别小的分区的分区键，但是数据访问模式也对理想的分区大小有很大的影响（有关更多信息，请阅读有关Cassandra数据建模的深入指南）。 可以将数据访问模式定义为如何查询表，包括表的所有选择查询。 理想情况下，CQL选择查询应该在where子句中只有一个分区键-也就是说，当查询可以从单个分区而不是许多较小的分区中获取所需数据时，Cassandra效率最高。
分区键设计的最佳做法
遵循分区键设计的最佳实践可帮助您达到理想的分区大小。 根据经验，Cassandra中的最大分区大小应保持在100MB以下。 理想情况下，它应小于10MB。 虽然Cassandra 3.6版和更高版本使更大的分区大小更可行，但必须对每个工作负载进行仔细的测试和基准测试，以确保分区键设计支持所需的群集性能。
具体来说，这些最佳做法应被视为任何分区键设计的一部分：
- 分区键的目标必须是将理想数量的数据放入每个分区中，以支持其访问模式的需求。
- 分区键应禁止无界分区：随着时间的推移，分区可能会无限增长。 例如，在上面的server_logs示例中，随着服务器日志数量的不断增加，使用server列作为分区键将创建无界的分区。 相反，使用log_hour将每个分区限制为一个小时的数据。
- 分区键还应避免产生分区偏斜，因为分区偏斜会导致分区增长不均匀，并且某些分区能够随时间增长而不受限制。 在server_logs示例中，在一个服务器生成比其他服务器多得多的日志的情况下使用server列会产生分区偏斜。 为避免这种情况，一种有用的技术是从表中引入另一个属性以强制均匀分布，即使必须创建一个哑列也是如此。
- 使用使用时间元素以及其他属性的分区键对时间序列数据进行分区很有帮助。 这可以防止不受限制的分区，允许访问模式在查询特定数据时使用时间属性，并允许删除有时间限制的数据。 上面的每个示例都使用log_hour time属性演示了这一点。
有几种工具可用来帮助测试，分析和监视Cassandra分区，以检查所选模式是否有效。 通过精心设计分区键以使其与手头解决方案的数据和需求很好地匹配，并遵循最佳实践来优化分区大小，您可以利用数据分区，从而更充分地发挥Cassandra部署的可伸缩性和性能潜力。
cassandra 优化
扫一扫
354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
