【问题标题】:Cassandra modeling issuesCassandra 建模问题
【发布时间】:2018-12-18 02:35:01
【问题描述】:

首先非常抱歉这么长的帖子,请多多包涵。

我是 cassandra 的新手,需要有人检查我的数据模型。我的目标是为社交媒体帖子表建模一个数据库。我计划有以下两个表来有效地存储和获取帖子。

  1. 张贴表
  2. posts_by_user 表

所有帖子都将存储在第一个表中,即帖子,这是结构

CREATE TABLE myapp_keyspace.posts ( id timeuuid, createdat bigint, city text, topFourComments list<frozen<comment>>, commentscount bigint, content text, contenttype text, country text, county text, createdon bigint, deletedon bigint, iscreator boolean, isdeleted boolean, likescount bigint, latitude double, longitude double, medias list<frozen<media>>, mediatype text, postcreatedby timeuuid, posttype text, postusername text, postuserprofilepic text, sharecount bigint, state text, status int, tags list<frozen<tag>>, timezone text, title text, updatedon bigint, PRIMARY KEY (id, createdat))

下面是一个不同的表格,其中数据被复制到时间轴屏幕。时间轴屏幕还具有以下过滤器(全部、图像、视频、文本、朋友、组),这是结构。

CREATE TABLE myapp_keyspace .posts_by_user ( postcreatedby timeuuid, contenttype text, mediatype text, posttype text, createdat bigint, comments list<frozen<comment>>, commentscount bigint, content text, createdon bigint, deletedon bigint, id timeuuid, iscreator boolean, isdeleted boolean, likescount bigint, medias list<frozen<media>>, sharecount bigint, status int, tags list<frozen<tag>>, title text, updatedon bigint, PRIMARY KEY (postcreatedby, contenttype, mediatype, posttype, createdat)

以下是我的两个问题
1. 正如 cassandra 所说,为每个查询计划一个单独的表。考虑到时间轴屏幕上的所有过滤器,为所有过滤器编写单个查询是好还是我计划为每个过滤器单独编写。 (全部、图片、视频、文字、好友、群组)
2.我应该如何存储朋友的帖子。我正在考虑在 post_by_user 表中复制所有朋友的帖子。例如:如果我有 10 个朋友并且我正在发帖。所以单个帖子将被存储 10 次,posts_by_user 表中的每个朋友一个。

由于这是我在 cassandra 中的第一个项目,我希望在设计数据库时格外小心,以避免将来出现任何问题。

欢迎提出任何建议。

【问题讨论】:

    标签: database cassandra data-modeling cassandra-3.0


    【解决方案1】:

    Cassandra 中的数据建模非常困难。不要因为挣扎而感到难过,尤其是刚开始的时候。对我来说效果很好并且与其他数据库(尤其是 SQL)完全不同的一件事是先写出查询,而不是表。使用 Cassandra,select 语句就是问题所在。

    我建议您实际上写出您需要的每个select,记住您需要哪些信息才能进行查询。这很关键,因为它将决定您如何形成主键。另一个重要的功能是compound keys。这有助于对结果进行排序,并且可能与您的情况相关。

    对于您的第一个表,您确定要同时使用 idcreatedat 吗?创建时间可以从timeuuid 类型导出。或者,也许您需要更细粒度的时间?考虑一下,因为查询表需要两者。

    正如您所猜测的那样,您的posts_by_user 表是真正的问题所在。从左到右想想你的钥匙。所以对于你的posts_by_user,如果你想留下createdat 通配符,你必须限制前面的所有列。我怀疑这是你想做的。例如,您不能只限制 mediatype

    像这样的任意过滤在 Cassandra 中可能很难做到。考虑您的 UI/应用程序需要什么。这就是为什么先对查询建模而不是表建模如此有用的原因。

    希望这会有所帮助 - 祝你好运!

    【讨论】:

    • 谢谢马特,我们对第二点有点困惑。我的简单查询足以从单个表中获取所有过滤器的数据。如果我这样做,我需要创建大约 5 个字段作为主键。我担心的是复杂性,拥有这样的密钥是一种好习惯吗?
    • 拥有长而复杂的键是很常见的。您的主键结构是支持查询的唯一方法,因此它将涉及您的查询涉及的所有字段是有道理的。根据我的经验,您的大部分设计工作都涉及到主键的结构。
    猜你喜欢
    • 2019-06-29
    • 2017-10-13
    • 1970-01-01
    • 1970-01-01
    • 2011-06-08
    • 2017-03-24
    • 2016-12-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多