如何存储大数据？

Question

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

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

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

查询具有数百万行的表格很慢，特别是因为我们必须处理分层数据并执行与SELECT * FROM userdata大不相同的一些不常见的计算。在任何给定的点上，我们只需要特定用户的数据，而不是整个事情 - 让它快速 - 但我们必须在以后做一些奇怪的事情。多次。

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

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

3. 实现某种可伸缩性。 （你现在听到很多云计算。）这是最想要的选择。

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

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

   3. 从SQLite切换到Postgres或Oracle解决方案。这不会便宜，所以在做这件事之前我想要一些确认。

   我有什么选择？我希望所有带有索引数据的SELECT和JOIN都是实时的，但userdata越大，查询就越便宜。

Answer 1

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

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

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

您决策的重要性应该是您的查询结构。您想要SELECT查询中只有少数字段（SQL），或者您希望始终获取整个文档（例如Mongo＆amp; Json）。

第二个重要标准是可扩展性，因为NoSQL经常放松通常的SQL事物（比如最终的一致性），所以它可以通过扩展来提供更好的结果。