我注册只是为了帮助解决这个问题。过去，我从 Stackoverflow 找到了对我的问题有用的答案——谢谢社区——所以我认为尝试用这个问题回馈一些东西是公平的（也许公平是轻描淡写），因为它落在我的小巷里.
简而言之，在考虑问题中所述的所有因素时，表存储可能是最佳选择 - 如果您可以正确估计每月的交易：关于此的一篇不错的文章。您可以通过拆分（纯文本方法或序列化）文档/html/数据来解决您提到的两个限制，行和列限制。从存储在 Table Storage 中的 40 GB 以上数据的经验来看，我们的应用程序经常在每次访问页面时以毫秒为单位检索超过 10 行 - 这里没有争议！如果您有时需要 50 多行，您正在查看较低的个位数秒数，或者您可以并行执行它们（并进一步通过将数据拆分到不同的分区中），或者以某种异步方式。或者，阅读下面建议的多级缓存。
更详细一点。我尝试使用 SQL Azure、Blob（页和块）和表存储。我不能代表 Mongo DB，部分原因是这里已经提到，我不想走那条路。
- 表存储速度快；在使用分区和行键查询时，在 20-50 毫秒的范围内，有时甚至更快（取决于，例如在同一个数据中心，我看到它低至 10 毫秒）。您还可以根据您的数据和您对它的了解以某种方式进一步拥有多个分区。
- 就 GB 而不是事务而言，它可以更好地扩展
- 您提到的行和列限制是一种负担，同意，但不是阻碍。我已经编写了我自己的拆分实体的解决方案，你可以很容易，或者你可以看到这个已经编写好的解决方案（不能解决整个问题，但它是一个好的开始）：https ://code.google.com/ p/lokad-cloud/wiki/FatEntities
- 还需要记住，将数据上传到表存储非常耗时，即使由于其他限制（即请求大小小于 4 MB、上传带宽等）而对实体进行批处理也是如此。
但仅使用 TableStorage 可能不是最好的解决方案（考虑增长和经济）。我们最终实施的最佳解决方案使用了多级缓存/存储，从静态类、Azure 基于角色的缓存、表存储和块 Blob 开始。为了便于阅读，我们分别称其为 1A、1B、2 和 3 级。使用这种方法，我们使用的是中型单实例（2 个 CPU 内核和 3.5 GB 内存——我的笔记本电脑有更好的性能），并且能够在几秒钟内处理/查询/排序 100GB 以上的数据（95% 的案例在 1 秒内）。我相信这是相当令人印象深刻的，因为我们检查了所有显示之前的“文章”（4+ 百万“文章”）。首先，这很棘手，在您的情况下可能会也可能不会。我对数据及其查询/处理用法没有足够的了解，但如果你能找到一种方法来很好地组织数据，这可能是理想的。我会做一个假设：听起来你正在尝试搜索并找到相关文章，给出一些关于用户和一些标签的信息（也许是新闻聚合器的变体，只是对此有预感）。这个假设是为了说明这个建议，所以即使不正确，我希望它能帮助你或引发关于如何采用它的新想法。
1A 级数据。
在静态类中识别和添加关键实体或其属性（定期，取决于您如何预见更新）。假设我们识别用户偏好（例如，人口统计和兴趣等）和标签（技术、政治、体育等）。这将用于快速检索用户是谁、他/她的偏好和任何标签。将这些视为键/值对；例如 key 是一个标签，它的 value 是一个文章 ID 的列表，或者它的一个范围。这解决了一个小问题，那就是：给定一组键（用户首选项、标签等）我们对哪些文章感兴趣！如果组织得当，这些数据应该很小（例如，您只能存储一个数字，而不是存储文章路径）。*注意：静态类中数据持久性的问题是 Azure 中的应用程序池默认情况下每 20 分钟左右不活动时重置一次，因此静态类中的数据不再持久 - 也跨实例共享它们（如果你有超过 1) 可以成为一个负担。欢迎 1B 级救援。
Leval 1B 数据
我们使用的一个解决方案是将 1A 层数据保存在 Azure 缓存中，其唯一目的是在需要时重新填充静态实体。1B 级数据解决了这个问题。此外，如果您遇到应用程序池重置时间问题，您可以通过编程方式进行更改。所以级别 1A 和 1B 具有相同的数据，但一个比另一个快（足够接近的类比：CPU 缓存和 RAM）。
稍微讨论 1A 和 1B 级别
有人可能会指出，使用静态类和缓存是一种过度杀伤力，因为它使用更多内存。但是，我们在实践中发现的问题是，首先静态速度更快。其次，在缓存中存在一些限制（即，每个对象 8 MB）。对于大数据，这是一个很小的限制。通过将数据保存在静态类中，可以拥有大于 8 MB 的对象，并通过拆分它们将它们存储在缓存中（即，目前我们有超过 40 个拆分）。顺便说一句，请投票以在 azure 的下一个版本中增加此限制，谢谢！这是链接：www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/3223557-azure-preview-cache-increase-max-item-size
2 级数据
一旦我们从键/值实体（1A 级）获得值，我们就使用该值来检索表存储中的数据。该值应该告诉您您需要什么分区和行键。这里要解决的问题：您只查询与用户/搜索上下文相关的那些行。正如您现在所看到的，拥有 1A 级数据是为了最大限度地减少从表存储中查询行。
3 级数据
表存储数据可以包含您的文章的摘要、第一段或类似性质的内容。当需要显示整篇文章时，您将从 Blob 获得。表存储，还应该有一列唯一标识blob中的整篇文章。在 blob 中，您可以按以下方式组织数据：
- 将每篇文章拆分为单独的文件。
- 将 n 篇文章分组到一个文件中。
- 将所有文章分组到一个文件中（不推荐，尽管没有第一印象那么糟糕）。
对于第一个选项，您将在表存储中存储文章的路径，然后直接从 Blob 中获取它。由于上述级别，您应该只需要在这里阅读几篇完整的文章。
对于第 2 和第 3 选项，您将使用 seek 在表存储中存储文件的路径以及从何处读取和停止读取的开始和结束位置。
这是 C# 中的示例代码：
YourBlobClientWithReferenceToTheFile.Seek(TableStorageData.start, SeekOrigin.Begin);
int numBytesToRead = (int)TableStorageData.end - (int)TableStorageData.start;
int numBytesRead = 0;
while (numBytesToRead > 0)
{
int n = YourBlobClientWithReferenceToTheFile.Read(bytes,numBytesRead,numBytesToRead);
if (n == 0)
break;
numBytesRead += n;
numBytesToRead -= n;
}
我希望这没有变成一本书，希望对您有所帮助。如果您有后续问题或意见，请随时与我联系。谢谢！