mysql - SQL 数据库列中的数组 - 或 - 一个键/值 noSQL 存储？

Question

提前感谢您抽出宝贵的时间。您的经验分享非常宝贵。

假设有 4 个用户可以提交帖子并对其他帖子进行投票。在数据库中，上述方法中哪种对于查询执行时间来说是最好的？是3列SQL吗数据库还是 2 列 NoSQL 键/值存储？

查询示例:获取post_3的upvoters。

谢谢

第一种方法(例如MySQL)

第二种方法

编辑(仅基于John Tseng的回答)

create table post (post_id int, author_id int); create table upvote (user_id int, post_id int).

我是否应该得出这样的结论:

2 个表(=3 次读取)比从 php 处理的一张表中读取长字符串更好？

我想指出，在实现项目之前优化速度(或至少学习如何操作)我觉得很重要。我不希望我的表将来变成 TB 并且性能缓慢，因为重新设计会有风险并且需要大量工作。我害怕将一大列从一张 table 移到另一张 table 上。这就是为什么我花费大量时间来寻找最适合我的数据库的设计，并从一开始就询问使用键/值存储是否合适。我是否误解了键值存储，它们在第一台机器上一开始就没有使用。

The way you store your data is very important, and you should make it logical before optimizing for speed.

为什么不创建一个逻辑设计，以便将来可以轻松优化速度？

从您宝贵的回答中，我是否需要明白，良好的 SQL 数据库设计是唯一的需要，之后键值存储的使用将变得很容易。

Answer 1

如果您要求这个查询的查询执行时间，那么它肯定是只需要一次读取的模式(第一种方法)。

但是，我认为这不是存储数据的好方法。如果有一天，您想要查询:用户 3 是否对用户 1 的任何帖子进行了投票？

我会制作两个表:

创建表post(post_id int,author_id int);创建表upvote (user_id int, post_id int);

这将使您的示例查询变慢，但我认为您不应该优化速度。存储数据的方式非常重要，在优化速度之前应该使其符合逻辑。您将拥有大量方法来提高数据库速度，而无需采用奇怪的方式存储数据。

当然，当您达到每秒数千个请求时，您会想要进行一些非规范化和 NoSQL，但我认为您应该在初始设计中远离这些类型的事情。

当人们说 NoSQL 无法扩展时，他们指的是 TB 级的数据库和每秒数千个请求。几年后，它们将意味着每秒数十 TB 和一万个请求。现在已经可以使用非常强大的机器使关系数据库处理数十 TB 和每秒一万个请求。几年后它的价格会更便宜一些。

总之，在关系数据库中进行初始设计，规范所有教科书风格。当您开始最大化 RAM(在其他关系数据库优化之后)时，您可以考虑这些问题。

编辑

对于这个查询，从表中读取一行确实更快。然而，一个好的数据库设计应该足够灵活，能够容纳多个查询，而不仅仅是一个查询。就您而言，一旦您拥有数千名追随者甚至数百万张赞成票，您就会遇到一些严重的问题。要修改单个赞成票，您将需要进行大量处理。要查找任何单独的更新，您需要解析整个字符串。

虽然我理解您一开始就希望优化速度的愿望，但许多人的经验表明，拥有逻辑代码比纯粹以性能指标为中心的代码要好得多。正如我们在这个简短的示例中所看到的，由于您加快了此查询的速度，因此大大减慢了其他查询的速度。

而且，理解 SQL 结构比理解 NoSQL 结构要容易得多。在学习 NoSQL 方式之前，您绝对应该先学习以 SQL 方式做事。原因之一是 NoSQL 是 SQL 之外的任何东西，并且有很多选择。

返回到这个特定的查询。使用正确的索引，查询将发出三个连续的读取，这将具有与单个读取非常相似的性能。我认为加速这个查询的正确方法不是以一种尴尬的方式将数据存储在数据库中，而是将尴尬的存储留给缓存层。您将在数据库中查询查询的正确答案，然后将其存储在缓存中。每次后续读取都会从缓存中获取数据。缓存将被非规范化，如下所示:

key: Post_3_upvotes value: [1, 3]

这与将所有数据存储在键/值存储中之间的区别在于，将对关系数据库进行修改，而关系数据库擅长修改。修改具有许多并发用户的键/值存储会给您带来比性能更大的问题。