2016-09-15 28 views
1

我们有一个存储我们的数据按照文件分区的表格。 json中的一个文件是200MB到8GB - 但是很明显,这些文件很多。压缩原始数据会大大降低这一点。我摄取了约35 GB的json数据,只有一个节点的数据略多于800 MB。这可能是由于“写热点” - 但我们只写一次,只读。我们不更新数据。目前,我们每个文件都有一个分区。卡桑德拉范围查询中的一个较大的分区或几个较小但分布较多的分区?

通过使用二级索引,我们搜索数据库中包含特定地理位置(=第一个查询)的分区,然后将此查询的结果用于范围查询找到的分区(=第二个查询)的时间范围。 如果需要,这甚至可能是整个文件,但在95%的查询中,只有分区的块被查询。

我们在6节点群集上具有复制因子2。数据分布相当均匀,根据nodetool status *tablename*,每个节点拥有31.9%至35.7%(有效)的数据。

良好的阅读表现对我们至关重要。

我的问题:

  1. 多大太大的体积或行大小方面分区?这是否有一个经验法则?
  2. 对于范围查询性能:将我们的“大”分区分成更小的分区会更好吗?我们用“大”分区构建了我们的模式,因为我们认为当我们在分区上执行范围查询时,最好将它全部放在一个节点上,以便轻松获取数据。需要注意的是数据,也可在一个副本由于RF 2.

回答

1
  1. C *支持非常庞大的行,但并不意味着它是一个好主意,去到那个水平。 权限取决于具体的使用情况,但良好的球场值可能在10k到50k之间。当然,一切都是妥协,所以如果你有“巨大的”(以字节为单位)行,那么会严重限制每个分区中的行数。如果你有“小”(以字节为单位)行,你可以放松一点。这是因为一个分区的意思是一个节点只是由于你的RF = 1,所以你对某个特定分区的查询只会命中一个节点。
  2. 范围查询理想情况下应该只转到一个分区。范围查询意味着对获取查询的节点上的分区进行顺序扫描。但是,您将自己限制为该节点的吞吐量。如果你在多个节点之间分割你的范围查询(即你改变了你通过添加类似来划分数据的方式),你需要从不同节点获取数据,并执行并行查询,直接增加总吞吐量。当然,你会在不同的桶中丢失记录的顺序,所以如果分区中的顺序很重要,那么这是不可行的。
+0

对不起,我滥用单词复制因子。我们实际上有RF 2('CREATE KEYSPACE WITH WITH = {'class':'NetworkTopologyStrategy','dc1':'2'} AND durable_writes = true;')。我相应地编辑了这个问题。如果“主”节点已经处于压力下,将读取重定向到副本? – j9dy

+1

RF = 2仅表示在同一分区上的2个(读取)查询可能会遇到2个不同的节点。如果发生这种情况取决于您的C *驱动程序。但是,这不会使** **查询的吞吐量更好。 – xmas79

+0

谢谢澄清。我认为这非常适合我们的使用案例。我们的第一个查询(见上)通常会返回几个包含搜索字段的文件(=分区)。因为这些(理想情况下)位于不同的节点上,所以我们会在后续查询中找到几个节点。知道复制的驱动程序可以将查询重新路由到副本,而不是在另一个节点获得查询时执行。你知道datastax C *驱动程序是否是“可复制的”? – j9dy