mongodb - 从 SQL Azure 中获取大行 - 但去哪里？表、Blob 或 MongoDB 之类的东西？

Question

我阅读了大量 Azure 表/Blob/SQL 存储之间的比较，我认为我对所有这些都有很好的理解......但是，我仍然不确定我的特定需求应该去哪里。也许有人在类似情况下有经验并且能够提出建议。

我有什么

一个 SQL Azure DB，它将文章以原始 HTML 格式存储在 varchar(max) 列中。每行还有许多元数据列和许多索引，以便于查询。该表包含许多对用户、订阅、标签等的引用 - 因此我的项目将始终需要 SQL DB。

有什么问题

我在这个表中已经有大约 500,000 篇文章，我预计它会以每年数百万篇文章的速度增长。每篇文章的 HTML 内容可以在几 KB 到 1 MB 之间，或者在极少数情况下大于 1 MB。

出现了两个问题:由于 Azure SQL 存储很昂贵，所以我会早晚考虑存储它的成本。此外，我也会更早地达到 150 GB 的数据库大小限制。这 500,000 篇文章现在已经消耗了 1.6 GB 的数据库空间。

我要什么

很明显，这些 HTML 内容必须从 SQL DB 中删除。虽然文章表本身必须保留以将其连接到用户、订阅、标签等，以便快速发现所需文章的关系，但至少可以将保存 HTML 内容的列外包给更便宜的存储。

乍一看，Azure 表存储似乎非常适合

以非常便宜的价格和快速查询在一个大表中存储 TB 的数据 - 拥有一个单独的表存储表作为 SQL DB 的附加组件保存文章内容，这听起来很完美。

但是阅读此处的比较表明它甚至可能不是一个选项:每列 64 KB 足以容纳我 98% 的文章，但还有 2% 的空间对于某些单篇文章，甚至整个 1 MB 的行限制都可能不够。

Blob 存储听起来完全错误，但是...

因此，Azure 上只剩下一个选项:Blob。现在，它可能不像听起来那么错误。在大多数情况下，我一次只需要一篇文章的内容。对于 Blob 存储，这应该可以正常工作且足够快。

但是我也有一些查询，我需要一次包含 50、100 甚至更多行，甚至包括内容。所以我必须运行 SQL 查询来获取所需的文章，然后从 Blob 存储中获取每篇文章。我没有这方面的经验，但我无法相信在执行此操作时我能够保持查询的毫秒时间跨度。对于我的项目来说，需要几秒钟的查询是绝对不行的。

所以它似乎也不是一个合适的解决方案。

我看起来像个有计划的人吗？

至少我有类似计划的东西。我只考虑将适当的记录“导出”到 SQL 表存储和/或 Blob 存储中。

类似于“只要内容小于 64 KB，就将其导出到表存储，否则将其保留在 SQL 表中(甚至将此单个 XL 记录导出到 BLOB 存储中)”

这可能足够好。但它使事情变得复杂，并且可能会导致不必要的错误。

其他选项

还有一些其他的 NoSQL DB，如 MongoDB 和 CouchDB，它们似乎更适合我的需求(至少从我作为一个只阅读纸上规范的人的幼稚观点来看，我没有使用它们的经验)。但是他们需要自托管，如果可能的话，我想摆脱它。我在 Azure 上尽可能少地做自托管服务器和服务方面的工作。

你真的读到这里了吗？

那么非常感谢您抽出宝贵的时间和思考我的问题:)

任何建议将不胜感激。如您所见，我有自己的想法和计划，但没有什么比以前走在路上的人的经验更胜一筹了:)

谢谢，
伯恩哈德

Answer 1

我注册只是为了帮助解决这个问题。过去，我从 Stackoverflow 找到了对我的问题有用的答案 - 谢谢社区 - 所以我认为尝试用这个问题来回馈是公平的(也许公平是轻描淡写)，因为它落在我的胡同里.

简而言之，在考虑问题中陈述的所有因素的同时，表存储可能是最佳选择 - 如果您可以正确估计每月的交易量:a nice article on this .
您可以通过拆分(纯文本方法或序列化)文档/html/data 来解决您提到的两个限制，行和列限制。从表存储中存储 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 是一个标签，它的值是一个文章 ID 列表，或者它的一个范围。这解决了一小部分问题，那就是:给定一组键(用户偏好、标签等)我们对哪些文章感兴趣!如果组织得当，这些数据应该很小(例如，您只能存储一个数字而不是存储文章路径)。 *注意:静态类中数据持久性的问题在于，默认情况下，Azure 中的应用程序池每 20 分钟左右不活动就会重置一次，因此您在静态类中的数据不再是持久性的——也会跨实例共享它们(如果你有超过 1) 项会成为负担。欢迎 1B 级前来救援。

级别 1B 数据
我们使用的一个解决方案是将第 1A 层数据保留在 Azure 缓存中，其唯一目的是在需要时重新填充静态实体。 Level 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)中获取值，我们就使用该值来检索 Table Storage 中的数据。该值应该告诉您需要什么分区和行键。问题在这里解决:您只查询与用户/搜索上下文相关的那些行。正如您现在看到的，拥有 1A 级数据是为了最大限度地减少从表存储中进行的行查询。

3级数据
表存储数据可以保存文章的摘要、第一段或类似的内容。当需要显示整篇文章时，您可以从 Blob 中获取。表存储，也应该有一个列，唯一标识 blob 中的完整文章。在 blob 中，您可以按以下方式组织数据:

将每篇文章拆分为单独的文件。

将 n 篇文章归为一个文件。

将所有文章组合在一个文件中(不推荐，尽管不像第一印象那么糟糕)。

对于第一个选项，您将在表存储中存储文章的路径，然后直接从 Blob 中获取它。由于上述级别，您应该只需要在这里阅读几篇完整的文章。

对于第二个和第三个选项，您将在表存储中存储文件的路径以及从哪里开始读取以及从哪里停止读取的开始和结束位置，使用搜索。

这是 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;
        }

我希望这不会变成一本书，并希望它有所帮助。如果您有后续问题或意见，请随时与我联系。
谢谢!