Cassandra 非规范化与规范化答案

【问题标题】：Cassandra denormalization vs normalizationCassandra 非规范化与规范化
【发布时间】：2016-05-13 00:53:08
【问题描述】：

非规范化现实

在我的数据库中，我有一个非常适合我的用例的非规范化表，而且我接收数据的速度非常快......

CREATE TABLE IF NOT EXISTS lp_webmap.link (
    drank int,
    prank int,
    title text,
    nofollow boolean,
    created timestamp,
    updated timestamp,  
    dst_ssl boolean,
    dst_www boolean,
    src_ssl boolean,
    src_www boolean,
    dst_domain_name1st text,
    dst_domain_name2nd text,
    dst_domain_name3rd text,
    src_domain_name1st text,
    src_domain_name2nd text,
    src_domain_name3rd text,
    dst_page text,
    src_page text,
    dst_page_title text,
    src_page_title text,
    src_domain_ownerreg text,
    PRIMARY KEY (
        (
            dst_domain_name1st, 
            dst_domain_name2nd, 
            dst_domain_name3rd 
        ), 
        created, 
        dst_page,
        src_page,
        src_domain_name1st,
        src_domain_name2nd,
        src_domain_name3rd
    )
);

但是，此表中有数十亿行，这对我们的硬件来说是个问题。因此，链接表设计中的每个备用字节对我们都有很大的好处。

归一化解？

应用程序中链接表的平均选择包含十分之一/数百行。在最坏的情况下，选择包含数千行。因此，使用此表规范化问题可能是（恕我直言）明智的...

CREATE TABLE IF NOT EXISTS lp_webmap.page (
   domain_name1st text,
   domain_name2nd text,
   domain_name3rd text,
   location text,
   title text,
   rank int,
   www boolean,
   update_interval smallint,
   updated timestamp,
   PRIMARY KEY (
      (domain_name1st, domain_name2nd, domain_name3rd, location),
      updated, rank, update_interval
   )
);

问题

如果我使用规范化的链接和页表，我需要将它们加入应用程序。这不是问题，但是如何有效地从页表中选择相应的行呢？我觉得遍历链接表中的每一行结果并一一选择相应的页面行是无效的。

【问题讨论】：

我不太确定我是否理解您的问题。但是，如果您关心的是跨分区的逻辑行重复数据，那么static columns 可以帮助您，而无需更改您的整体表布局？
@Ralf：就是这样！顺便说一下，这是一篇关于静态列的解释性文章：blogs.infosupport.com/…。非常感谢。

标签： database-design cassandra database-normalization cassandra-2.2 nosql

【解决方案1】：

确实，JOIN 效率不高，尤其是其中一张表非常大。一种可能的解决方案是构建一个额外的物化视图，或某种索引以快速搜索特定列。这将使存储翻倍，但没有办法同时实现：减少空间消耗并提高 JOIN 查询性能。

也许您需要额外的硬盘驱动程序来获取新视图或索引。

必须注意的一点是，当我们构建额外的视图或索引时，更新某些列会花费额外的时间（资源）。例如，我们有两个表：orders 和 users，我们通过 JOIN 搜索用户“jack”的所有订单。这是一个标准化的版本。在物化视图中，用户“jack”，他的所有列都合并到他的订单中以便快速访问：

primary_key, order_id, order_product, order_payment, user_name, user_age, user_favorite_color

1,       1,       iphone,       1000,       jack,       25,       blue,  
2,       3,       book,         30,         jack,       25,       blue,  
3,       6,       car,          10000,      jack,       25,       blue,

其中user_age、user_favorite_color 是从用户表中提取的冗余信息。当杰克改变他最喜欢的颜色时，所有这些记录都必须改变它们对应的列。通常，数据库系统会启动后端程序来执行此更新工作，但这仍然是一个耗时的过程，映像杰克有数千个订单。

【讨论】：