0

假设我们有一个聚合 20 000 个用户的 Web 服务，每个用户都链接到 300 个包含任何内容的唯一用户数据实体。这是关于如何设计能够存储上述数据的示例关系数据库的简单方法：

  1. 为用户创建表。
  2. 为用户数据创建表。

因此，用户数据表包含 6 000 000 行。

查询具有数百万行的表很慢，尤其是因为我们必须处理分层数据并执行一些与SELECT * FROM userdata. 在任何给定的点上，我们只需要特定用户的数据，而不是全部——得到它很快——但我们必须在以后用它做一些奇怪的事情。多次。

我希望我们的网络服务速度快，所以我想到了以下方法：

  1. 优化查询，进行大量缓存等。这很好，但这些只是临时解决方法。当数据库进一步增长时，这些将停止工作。
  2. 重写我们的模型层以使用 NoSQL 技术。由于缺乏关系数据库功能，这是不可能的，即使我们想要这种方法，早期的测试也会使某些功能比现在更慢。

  3. 实现某种可扩展性。（你现在经常听到云计算。）这是最想要的选择。

    1. 实施一些手动解决方案。例如，我可以将所有名称以字母“A..M”开头的用户存储在服务器 1 上，而所有其他用户都属于服务器 2。这种方法的问题是我必须重新设计我们的架构很多我想避免这种情况。
    2. 理想情况下，我会有某种透明的解决方案，允许我查询看似统一的数据库服务器，而无需更改任何代码。数据库服务器会以一种智能的方式（很像数据库优化器）将其表数据分散到许多工作人员上，从而有效地加速一切。（这甚至可能吗？）

    在这两种情况下，实现互操作性似乎很麻烦……

  4. 从 SQLite 切换到 Postgres 或 Oracle 解决方案。这不会很便宜，所以我想在这样做之前进行某种确认。

我有哪些选择？我希望我的所有带有索引数据SELECT的 s 和JOINs 都是实时的，但是越大userdata，查询的开销就越大。

4

1 回答 1

3

如果你有这么多的数据，我认为你不应该默认使用 NoSQL。您期望它将解决哪种问题？

恕我直言，这取决于您的查询。你没有提到某种大规模的写作，所以到目前为止 SQL 仍然是合适的。

听起来您想使用JOINs 执行查询。即使使用适当的索引，这在非常大的数据上也可能会很慢。您可以做的是降低分解级别并仅复制数据（因此它们都在一个数据库行中并从硬盘驱动器一起获取）。如果您担心延迟，避免加入是一个好方法。但它仍然没有消除 SQL，因为即使在 SQL 中也可以复制数据。

对您的决策至关重要的应该是查询的结构。您只想SELECT查询中的几个字段 (SQL) 还是想要始终获取整个文档（例如 Mongo 和 Json）。

第二个重要标准是可伸缩性，因为 NoSQL 经常放宽通常的 SQL 事物（如最终一致性），因此它可以使用横向扩展提供更好的结果。

于 2013-09-08T14:33:54.737 回答