假设我们有一个聚合 20 000 个用户的 Web 服务，每个用户都链接到 300 个包含任何内容的唯一用户数据实体。这是关于如何设计能够存储上述数据的示例关系数据库的简单方法：
- 为用户创建表。
- 为用户数据创建表。
因此，用户数据表包含 6 000 000 行。
查询具有数百万行的表很慢，尤其是因为我们必须处理分层数据并执行一些与SELECT * FROM userdata. 在任何给定的点上，我们只需要特定用户的数据，而不是全部——得到它很快——但我们必须在以后用它做一些奇怪的事情。多次。
我希望我们的网络服务速度快，所以我想到了以下方法：
- 优化查询，进行大量缓存等。这很好，但这些只是临时解决方法。当数据库进一步增长时，这些将停止工作。
- 重写我们的模型层以使用 NoSQL 技术。由于缺乏关系数据库功能，这是不可能的，即使我们想要这种方法，早期的测试也会使某些功能比现在更慢。
实现某种可扩展性。（你现在经常听到云计算。）这是最想要的选择。
- 实施一些手动解决方案。例如，我可以将所有名称以字母“A..M”开头的用户存储在服务器 1 上，而所有其他用户都属于服务器 2。这种方法的问题是我必须重新设计我们的架构很多我想避免这种情况。
- 理想情况下，我会有某种透明的解决方案，允许我查询看似统一的数据库服务器，而无需更改任何代码。数据库服务器会以一种智能的方式（很像数据库优化器）将其表数据分散到许多工作人员上，从而有效地加速一切。（这甚至可能吗？）
在这两种情况下，实现互操作性似乎很麻烦……
- 从 SQLite 切换到 Postgres 或 Oracle 解决方案。这不会很便宜，所以我想在这样做之前进行某种确认。
我有哪些选择？我希望我的所有带有索引数据SELECT的 s 和JOINs 都是实时的，但是越大userdata，查询的开销就越大。