【问题标题】:Struggling between relational data modeling and document data modeling在关系数据建模和文档数据建模之间挣扎
【发布时间】:2016-08-20 08:13:47
【问题描述】:

我目前正在为数据建模而苦苦挣扎。有些表的记录超过100万条,通过GROUP BYCOUNT查询输出需要相当长的时间。所以我搬到了 Couchbase,因为它支持视图和索引,我发现在查询数据时速度更快。

MySQL 有一个很大的优势,我发现它非常有用。比如我在 users 表中有一个用户和一些与这个用户相关的文章,还有一些来自许多其他用户的与这篇文章相关的喜欢和 cmets。我通常会做一个 JOIN,所以输出会给我带有用户名和个人资料图像的文章。输出还附有其他用户的点赞和 cmets 详细信息。因此,如果用户上传了新的个人资料图片或更改了他的电子邮件地址,我只需要更新 users 表中的列。

在 Couchbase 中,我尝试在将数据存储在 MySQL 中时创建文档,例如文章文档的作者为 user_id,评论文档的作者为 commenter_idarticle_id。现在我发现在启用限制和排序的视图或索引中加入它们是非常困难的。所以我将用户的profile_imgfirst_namelast_name 复制到所有相关文档中。因此,当我加载文章文档时,它具有以下结构:

{ "article_id": 1234, "text": "A good article", "author_id": 1, "first_name": "John", "last_name": "Smith", "profile_img": "0bf34ee0a.jpg", "likes": [ { "user_id": 1, "first_name": "John", "last_name": "Smith", "profile_img": "0bf34ee0a.jpg" }, { "user_id": 2, "first_name": "Paul", "last_name": "Einstein", "profile_img": "1789ab00ef.jpg" } ] "comments": [ { "user_id": 1, "first_name": "John", "last_name": "Smith", "text": "This is my article", "profile_img": "0bf34ee0a.jpg" }, { "user_id": 2, "first_name": "Paul", "last_name": "Einstein", "text": "i like it", "profile_img": "1789ab00ef.jpg" } ] }

这无疑节省了我的查询时间。 (否则我必须先查询文章,从文章中提取用户id和likes和cmets,然后根据用户id查询用户附加用户详细信息到文章和likes和cmets)。但这给我带来了另一个问题,如果用户更新他的个人资料图片,我必须爬取所有文章以找到他的user_id 并更新profile_img 字段。

有人知道我应该走哪条路吗?

【问题讨论】:

  • 我不明白这里仅存储用户 ID、关键字、全文搜索或 solr 集成的复杂性。我看不出用索引很好地调整了数百万行的 mysql 解决方案如何不是一个非常快速的解决方案。特别是如果你避免斑点
  • 您不能只采用 SQL 建模并将其转换为任何 NoSQL/文档数据库解决方案。一个严肃的解决方案应该涉及重新考虑您的数据。这主要是因为这些平台倾向于解决不同的问题。

标签: mysql couchbase data-modeling


【解决方案1】:

阅读this blog post,看看这是否回答了您的一些问题,如果没有,我们继续讨论。

对于上面的对象模型,从长远来看,将 Likes 和 Comments 嵌入到用户文档中可能不是一个好主意。虽然是的,但您可以使用 sub-doc API 来读取/写入 JSON 的那一部分,您可以通过复制等方式在后端为此付费,但随着时间的推移,当涉及到文档大小时,您也可以这样做。您最好将每个用户的喜欢和 cmets 放入他们自己的文档中。即使这样,您也必须满足于该文档对于活跃用户的增长方式。

另一件事。 cmets 和 likes 应该与正在评论的内容相关还是与用户评论和喜欢相关?可能值得让每个评论在他们自己的对象中使用标准化的键模式来识别它,然后让另一个对象是对原始想法进行评论的所有对象 ID 的数组。喜欢的人也一样。你做什么取决于你将如何访问数据,特别是你对应用程序的性能和扩展需求。我的意思是,您为每秒只能执行 500 次操作的系统做出的架构设计决策可能与每秒执行 200,000 次操作的系统大不相同。与 RDBMS 相比,在 NoSQL 数据库中访问数据的主要区别在于,使用 NoSQL 更容易准确地对应用程序和用户如何使用数据进行建模,而在 RDBMS 中,您必须多次建模最适合数据库引擎以及它将如何存储和使用数据。

另外,请阅读 this postthis one。请记住,后一篇关于高写入率的文章是在 Couchbase 中的 N1QL 之前写的,但无论如何它都应该给你一些想法。

【讨论】:

    【解决方案2】:
    猜你喜欢
    • 1970-01-01
    • 2012-05-31
    • 2013-07-15
    • 2017-06-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-03-07
    相关资源
    最近更新 更多