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

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的附加组件.

但是通过这里的比较显示它甚至可能不是一个选项:对于98%的文章,每列64 KB就足够了,但是对于某些单篇文章,即使整个1 MB的行限制也可能会留下2%还不够.

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

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

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

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

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

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

像"只要内容<64 KB将其导出到表存储,或者将其保存在SQL表中(甚至将此单个XL记录导出到BLOB存储中)"

这可能足够好了.但它使事情变得复杂,并且可能不容易出错.

那些其他选择

还有一些像MongoDB和CouchDB这样的其他NoSQL DB似乎更符合我的需求(至少从我天真的角度来看,那些刚读过纸上规格的人,我没有经验).但是他们需要自我托管,如果可能的话,有些事我想摆脱它.我在Azure上根据自托管服务器和服务的需要尽可能少地做.

你真的在这儿读过吗？

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

任何建议将不胜感激.如你所见,我有自己的想法和计划,但没有什么能比以前走过路上的人有经验:)

谢谢,伯恩哈德

Answer 1

我注册只是为了帮助解决这个问题.在过去,我从Stackoverflow找到了有用的问题答案 - 谢谢你们社区 - 所以我认为尝试用这个问题回馈一下是公平的(也许是公平的,这是不公平的)因为它落在了我的胡同里.

简而言之,在考虑问题中陈述的所有因素的同时,表存储可能是最佳选择 - 如果您可以正确估计每月的交易:这是一篇很好的文章.您可以通过拆分(纯文本方法或序列化)文档/ html/data来解决您提到的两个限制,行和列限制.根据存储在表存储中的40 GB +数据的经验,我们的应用程序经常以毫秒为单位检索每页访问超过10行 - 这里没有参数!如果您有时需要50多行,您可以查看低位数秒,或者您可以并行执行(并通过在不同分区中拆分数据),或以某种异步方式执行.或者,阅读下面建议的多级缓存.

更详细一点.我尝试使用SQL Azure,Blob(页面和块)和表存储.我不能代表Mongo DB,因为部分由于这里已经提到的原因,我不想走那条路.

• 表存储速度快; 在使用分区和行键查询时,在20-50毫秒的范围内,或者有时甚至更快(取决于,例如,在我看到它的同一数据中心,它已经低至10毫秒).您还可以根据您的数据和您对它的了解,以某种方式进一步拥有多个分区.
• 就GB而言,它可以更好地扩展,但不是交易
• 您提到的行和列限制是一种负担,同意,但不是显示阻止.我已经为分割实体编写了自己的解决方案,你可以轻松地,或者你可以看到这个已经编写的解决方案(不能解决整个问题,但这是一个好的开始):https://code.google.com/ p/lokad云/维基/ FatEntities
• 还需要记住,将数据上传到表存储是非常耗时的,即使在由于其他限制(即请求大小小于4 MB,上载带宽等)而批量处理实体时也是如此.

但仅使用TableStorage可能不是最佳解决方案(考虑增长和经济).我们最终实现了使用多级缓存/存储的最佳解决方案,从静态类,基于Azure角色的缓存,表存储和块Blob开始.出于可读性目的,我们将其分别称为1A,1B,2和3级.使用这种方法,我们使用一个中等单个实例(2个CPU核心和3.5 GB Ram - 我的笔记本电脑具有更好的性能),并且能够在几秒钟内处理/查询/排序100GB +数据(95%的情况在1秒内) ).鉴于我们在展示它们之前检查所有 "文章"(400多万篇"文章"),我相信这是相当令人印象深刻的.首先,这很棘手,在您的情况下可能会或可能不会.我对数据及其查询/处理用法没有足够的了解,但是如果你能找到一种很好地组织数据的方法,这可能是理想的.我将做一个假设:听起来你正试图搜索并找到相关文章,给出一些关于用户和一些标签的信息(也许是新闻聚合器的变体,只是为此预感).这个假设是为了说明这个建议,所以即使不正确,我希望它能帮助你或引发关于如何采用这个建议的新想法.

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中,您可以按以下方式组织数据:

1. 将每篇文章拆分为单独的文件.
2. 在一个文件中分组n篇文章.
3. 将所有文章分组在一个文件中(不推荐,但不如第一次印象那么糟糕).

对于第一个选项,您将在表存储中存储文章的路径,然后直接从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

我对此的想法：走 MongoDB（或 CouchDB）路线最终会花费你额外的计算成本，因为你需要运行一些服务器（为了高可用性）。根据所需的性能，您最终可能会运行 2 核或 4 核机器。三个 4 核机器的运行成本将超过 SQL DB 成本（加上存储成本，MongoDB 等将在 Azure blob 中支持其数据以进行耐用存储）。

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

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