Question

我阅读了Azure Table / Blob / SQL存储之间的大量比较，我想我对所有这些都有很好的理解......但是，我仍然不确定在哪里可以满足我的特定需求。也许有人在类似场景中有经验并能够提出建议。

我有什么

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

问题是什么

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

出现了两个问题：由于Azure SQL存储空间很昂贵，而且比以后更早，我会将自己的存储费用与存储成本相提并论。此外，我还会比以后更早地达到150 GB数据库大小限制。这500,000篇文章现在已占用1.6 GB的数据库空间。

我想要什么

很明显，这些HTML内容必须离开SQL DB。虽然文章表本身必须保留用于将其加入用户，订阅，标签等以便快速关联发现所需文章，但至少包含HTML内容的列可以外包到更便宜的存储。

乍一看，Azure Table存储看起来非常合适

一个大表中的数TB数据非常便宜且查询速度快 - 听起来非常适合使用一个表格存储表来保存文章内容作为SQL DB的附加组件。

但通过这里的比较阅读显示它甚至可能不是一个选项：每列64 KB对于我的文章的98％就足够了，但是有些2％留下了一些单篇文章甚至整个1 MB的文章行限制可能还不够。

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

所以Azure上只有一个选项：Blob。现在，它可能没有听起来那么错误。在大多数情况下，我一次只需要一篇文章的内容。使用Blob存储时，这应该可以正常工作。

但我也有查询，我需要一次50行，100行甚至更多行，甚至包括内容。因此，我必须运行SQL查询来获取所需的文章，然后从Blob存储中提取每一篇文章。我对此没有任何经验，但我无法相信在执行此操作时我可以保持毫秒级的查询时间。对于我的项目而言，花费多秒的查询是绝对禁止的。

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

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

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

类似“只要内容<64 KB将其导出到表存储，否则将其保存在SQL表中（甚至将此单个XL记录导出到BLOB存储中）”

这可能足够好。但它使事情变得复杂，可能不容易出错。

其他选项

还有一些像MongoDB和CouchDB这样的其他NoSQL数据库似乎更符合我的需求（至少从我天真的角度来看，因为有人刚读过纸上的规格，我对它们没有经验）。但是他们需要自我托管，如果可能的话，有些事我想摆脱它。我在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 Ram - 我的笔记本电脑具有更好的性能），并且能够在几秒钟内处理/查询/排序100GB +数据（95％的情况在1秒内））。我相信这是相当令人印象深刻的，因为我们检查所有＆＃34;文章＆＃34;在展示它们之前（4,000多万＆＃34;文章＆＃34;）。首先，这很棘手，在您的情况下可能会或可能不会。我对数据及其查询/处理用法没有足够的了解，但是如果你能找到一种很好地组织数据的方法，这可能是理想的。我将做一个假设：听起来你正试图搜索并找到相关文章，给出一些关于用户和一些标签的信息（也许是新闻聚合器的变体，只是为此预感）。这个假设是为了说明这个建议，所以即使不正确，我希望它能帮助你或引发关于如何采用这个建议的新想法。

1A级数据。 在静态类中识别并添加关键实体或其属性（定期，具体取决于您预见的更新方式）。假设我们识别用户偏好（例如，人口统计和兴趣等）和标签（技术，政治，体育等）。这将用于快速检索用户是谁，他/她的偏好以及任何标签。将这些视为键/值对;例如，key是一个标记，其值是文章ID列表或其范围。 这解决了一小部分问题，即：给定一组密钥（用户首选项，标签等）我们感兴趣的文章！这些数据应该很小，如果有条理的话正确（例如，不是存储文章路径，而是只能存储数字）。 *注意：静态类中数据持久性的问题是，默认情况下，Azure中的应用程序池会每20分钟左右重置一次，因此静态类中的数据不再持久 - 也可以跨实例共享它们（如果你有超过1）可以成为负担。欢迎等级1B到救援。

Leval 1B数据 我们使用的解决方案是将第1A层数据保存在Azure缓存中，其唯一目的是在需要时重新填充静态实体。 1B级数据解决了这个问题。此外，如果您遇到应用程序池重置时间问题，您可以通过编程方式进行更改。因此1A级和1B级具有相同的数据，但是一个比另一个快（足够接近类比：CPU高速缓存和RAM）。

稍微讨论第1A和1B级 有人可能会指出，使用静态类和缓存是一种过度杀伤，因为它使用了更多的内存。但是，我们在实践中发现的问题是，首先它在静态时更快。其次，在缓存中存在一些限制（即，每个对象8 MB）。对于大数据，这是一个小限制。通过将数据保持在静态类中，可以具有大于8 MB的对象，并通过拆分它们将它们存储在缓存中（即，目前我们有超过40个分割）。 BTW请在下一个版本的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中获取它。由于上述级别，您应该只需阅读一些完整的文章。

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

以下是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;
        }

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

Answer 2

文件的正确存储是一个blob。但是如果你的查询需要同时返回几十个blob，那么当你指出它时它会太慢。因此，您可以使用混合方法：对98％的数据使用Azure表，如果数据太大，请使用Blob，并将Blob URI存储在表中。

另外，你在压缩你的内容吗？我当然会。

Answer 3

您可以使用MongoDB的GridFS功能：http://docs.mongodb.org/manual/core/gridfs/

默认情况下，它将数据拆分为256k块（最多可配置为16mb），并允许您将分片数据库用作可用于存储和检索文件的文件系统。如果文件大于块大小，则mongo db驱动程序会在需要检索文件时处理拆分/重新组装数据。要添加额外的磁盘空间，只需添加其他分片。

你应该知道，但只有一些mongodb驱动程序支持这个，它是一个驱动程序约定，而不是允许这种行为的服务器功能。

Answer 4

一些评论：

您可以做的是始终将HTML内容存储在blob存储中，并将blob的URL存储在表存储中。我个人不喜欢有条件地存储数据的想法，即如果HTML文件的内容超过64 KB，则将其存储在blob存储中，否则使用表存储。您从这种方法中获得的其他优势是您仍然可以查询数据。如果将所有内容存储在blob存储中，则会丢失查询功能。
就使用其他NoSQL商店而言，我遇到的唯一问题是它们在Windows Azure上本身不受支持，因此您也有责任管理它们。

Answer 5

我对此的看法：使用MongoDB（或CouchDB）路线最终会花费额外的Compute，因为您需要运行一些服务器（以获得高可用性）。根据所需的性能，您最终可能会运行2核或4核盒。三个4核盒的运行速度将超过SQL DB的成本（此外还有存储成本，MongoDB等会将其数据备份到Azure blob中以实现持久存储）。

现在，至于将html存储在blob中：这是一种非常常见的模式，可以将大型对象卸载到blob存储中。 GET应该在一次调用blob存储（单个事务）时可行，特别是在您提到的文件大小范围内。而且您不必连续检索每个blob;您可以利用TPL将多个blob并行下载到您的角色实例中。

还有一件事：你是如何使用这些内容的？如果你是从角色实例中流式传输它，那么我对TPL的说法应该很好。另一方面，如果您将href注入输出页面，则只需将blob网址直接放入html页面即可。如果您担心隐私，请将blob设为私有并生成短TTL“共享访问签名”，以便为小时间窗口授予访问权限（这仅适用于将blob url插入其他html页面;它不适用如果您正在下载到角色实例，然后在那里做一些事情。）

Answer 6

另一种选择是将文件存储为blob存储中的VHD图像。您的角色可以将VHD挂载到其文件系统，并从那里读取数据。

复杂性似乎是只有一个VM可以对VHD具有读/写访问权限。其他人可以创建快照并从中读取，但他们不会看到更新。取决于您的数据更新的频率可行。例如，如果您在众所周知的时间更新数据，则可以卸载所有客户端，获取新快照，然后重新安装以获取新数据。

您还可以使用SMB共享分享VHD，如MSDN blog post所述。这将允许完全读/写访问，但可能不太可靠，而且有点复杂。

Answer 7

您没有说，但如果您没有压缩可能解决您问题的文章，那么只需使用表格存储。

否则只需使用表存储并为每篇文章使用唯一的分区键。如果一篇文章太大就把它放在两行中，只要你按分区键查询就可以获得两行，然后使用行键作为指示文章如何重新组合的索引

Answer 8

我的一个想法是使用CDN来存储您的文章内容，并直接从客户端链接它们，而不是从sql获取数据然后转到某个存储的任何多阶段操作。这就像是

http://<cdnurl>/<container>/<articleId>.html

事实上，Blob存储也可以做同样的事情。

这里的优势在于它变得非常快。

缺点是安全方面丢失了。

可以探索共享访问签名之类的安全性，但我不确定它对客户端链接有多大帮助。

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

8 个答案: