是)我有的
一个SQL Azure DB,用于在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上根据自托管服务器和服务的需要尽可能少地做. 你真的在这儿读过吗？ 那么非常感谢你宝贵的时间和思考我的问题:) 任何建议将不胜感激.如你所见,我有自己的想法和计划,但没有什么能比以前走过路上的人有经验:) 谢谢,
伯恩哈德
解决方法
现在,至于将html存储在blob中：这是一种非常常见的模式,可以将大型对象卸载到blob存储中.一次调用blob存储(单个事务)就可以实现GET,特别是在你提到的文件大小范围内.而且您不必连续检索每个blob;您可以利用TPL将多个blob并行下载到您的角色实例中.
还有一件事：你是如何使用这些内容的？如果你是从你的角色实例中流式传输它,那么我对TPL的说法应该很好.另一方面,如果你将href注入输出页面,你可以直接将blob url放入你的html页面.如果您担心隐私,请将blob设为私有并生成短TTL“共享访问签名”,以便为小时间窗口授予访问权限(这仅适用于将blob url插入其他html页面;它不适用如果您正在下载到角色实例,然后在那里做一些事情).
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。