0

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

假设有 4 个用户可以提交帖子并为其他帖子点赞。在数据库中，上述方法中哪一种在查询执行时间方面是最好的？是 3 列 SQL 数据库还是 2 列 NoSQL 键/值存储？

查询示例：获取 post_3 的支持者。

谢谢

第一种方法（例如 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 并且执行缓慢，因为重新设计会有风险并且需要大量工作。我害怕将一大列从一张桌子移到另一张。这就是为什么我花费大量时间为我的数据库寻找最佳设计并从一开始就询问使用键/值存储是否好。我是否误解了键值存储，它们不是在第一台机器上开始使用的。

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

为什么不创建一个可以在未来轻松优化速度的逻辑设计呢？

从您宝贵的答案中，我是否需要了解 SQL 数据库的良好设计是唯一需要，并且之后使用 Key-Value 存储将很容易。

4

1 回答 1

2

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

但是，我认为这不是存储数据的好方法。如果有一天，您想查询：用户 3 是否支持用户 1 的任何帖子？

我会做两张桌子：

创建表帖子（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]

这与将所有数据存储在键/值存储中的区别在于，将对关系数据库进行修改，这将擅长修改。修改具有许多同时用户的键/值存储将使您遇到比性能更大的问题。

于 2013-07-25T04:15:55.770 回答