1
我们有一个存储我们的数据按照文件分区的表格。 json中的一个文件是200MB到8GB - 但是很明显,这些文件很多。压缩原始数据会大大降低这一点。我摄取了约35 GB的json数据,只有一个节点的数据略多于800 MB。这可能是由于“写热点” - 但我们只写一次,只读。我们不更新数据。目前,我们每个文件都有一个分区。卡桑德拉范围查询中的一个较大的分区或几个较小但分布较多的分区?
通过使用二级索引,我们搜索数据库中包含特定地理位置(=第一个查询)的分区,然后将此查询的结果用于范围查询找到的分区(=第二个查询)的时间范围。 如果需要,这甚至可能是整个文件,但在95%的查询中,只有分区的块被查询。
我们在6节点群集上具有复制因子2。数据分布相当均匀,根据nodetool status *tablename*
,每个节点拥有31.9%至35.7%(有效)的数据。
良好的阅读表现对我们至关重要。
我的问题:
- 多大太大的体积或行大小方面分区?这是否有一个经验法则?
- 对于范围查询性能:将我们的“大”分区分成更小的分区会更好吗?我们用“大”分区构建了我们的模式,因为我们认为当我们在分区上执行范围查询时,最好将它全部放在一个节点上,以便轻松获取数据。需要注意的是数据,也可在一个副本由于RF 2.
对不起,我滥用单词复制因子。我们实际上有RF 2('CREATE KEYSPACE WITH WITH = {'class':'NetworkTopologyStrategy','dc1':'2'} AND durable_writes = true;')。我相应地编辑了这个问题。如果“主”节点已经处于压力下,将读取重定向到副本? – j9dy
RF = 2仅表示在同一分区上的2个(读取)查询可能会遇到2个不同的节点。如果发生这种情况取决于您的C *驱动程序。但是,这不会使** **查询的吞吐量更好。 – xmas79
谢谢澄清。我认为这非常适合我们的使用案例。我们的第一个查询(见上)通常会返回几个包含搜索字段的文件(=分区)。因为这些(理想情况下)位于不同的节点上,所以我们会在后续查询中找到几个节点。知道复制的驱动程序可以将查询重新路由到副本,而不是在另一个节点获得查询时执行。你知道datastax C *驱动程序是否是“可复制的”? – j9dy