如何存储大数据？答案

【问题标题】：How to store big data?如何存储大数据？
【发布时间】：2013-09-06 14:52:40
【问题描述】：

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

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

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

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

优化查询，进行大量缓存等。这很好，但这些只是临时解决方法。当数据库进一步增长时，这些将停止工作。
重写我们的模型层以使用 NoSQL 技术。由于缺乏关系数据库功能，这是不可能的，即使我们想要这种方法，早期的测试也会使某些功能比现在更慢。
实现某种可扩展性。（您现在经常听到云计算。）这是最想要的选择。
1. 实施一些手动解决方案。例如，我可以将所有名称以字母“A..M”开头的用户存储在服务器 1 上，而所有其他用户将属于服务器 2。这种方法的问题是我必须重新设计我们的架构很多我想避免这种情况。
2. 理想情况下，我应该有某种透明的解决方案，可以让我查询看似统一的数据库服务器，而无需更改任何代码。数据库服务器会以一种智能的方式（很像数据库优化器）将其表数据分散到许多工作人员上，从而有效地加速一切。（这甚至可能吗？）
在这两种情况下，实现互操作性似乎很麻烦......
从 SQLite 切换到 Postgres 或 Oracle 解决方案。这不会很便宜，所以我想在做这件事之前先确认一下。

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

【问题讨论】：

这不是大数据。如果您需要免费的数据库，请使用适当的数据库，如 Postgres 或 MySQL...（当然，从长远来看，可能需要 DBA）这种数据量远不需要云等等...
SELECT * FROM UserData WHERE UserID = x 在适当的索引下应该很快。哪些查询很慢？
我的查询会在睡眠中运行超过 600 万行。即使是 6 亿行也不会让我表现出任何严重的担忧。
这样的查询很快，但我们也使用 CREATE TEMPORARY TABLE x; INSERT INTO x SELECT * FROM UserData WHERE UserID = ? AND something = ?; SELECT * FROM SomethingElse INNER JOIN x 等查询（我们正在尝试基于协同过滤显示推荐）。
如果您的索引设置正确，则连接速度很快。你给出的例子对于这么多的数据不会很慢。

【解决方案1】：

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

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

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

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

第二个重要标准是可扩展性，因为 NoSQL 通常会放宽通常的 SQL 内容（如最终一致性），因此它可以通过横向扩展提供更好的结果。

【讨论】：