本文介绍了为具有数百万个广告的网站组织图像档案的预算存储的经验。
就我而言，图像应理解为公寓，房屋，地块等的照片。 我有
自己的项目 ，该网站上刊登了用于房地产销售和出租的广告。 该网站已经存在了大约6年，在此期间，已经积累了相当多的广告。 在每个对象卡上显示照片，每个广告平均显示8张照片。 实际上，我将这些照片存储在云中，以便以后可以将它们通过对象卡显示给访问者。
我以前如何存储它们？ -没办法 除了手动放置的图像外，我没有保留其他图像。 在大多数情况下，广告会通过自动Feed上传通过合作伙伴到达网站。 在每个对象的供稿中，都有指向照片的链接-我存储这些链接，并直接从合作伙伴那里给访客提供照片。 该电路工作良好，节省了大量资源。
访客在
广告选择或
对象卡片中看到的照片实际上是从第三方资源加载的。
需要注意的是有关该站点的详细信息-决不会删除存档对象。 即 从发布中删除广告后，它肯定会从搜索结果中消失，但是直接链接始终可用（没有卖方的联系）。 一段时间以来，指向照片的链接仍然存在，有时长达数年，但迟早会消失。 归档的对象很有价值，因为来自搜索引擎的访问者会继续来找它们。 此外，还从档案库中构建
了一个价格图 （我已经
写过它了 ），我无意中发现了该项目的另一种收入来源，即出售档案对象的联系信息。 我不确定他们为什么要购买它们，但我想访问者希望获得联系是因为他们认为广告是偶然或错误地从出版物中删除的。 他们可能还想从以前的所有者那里学习一些东西。 无论哪种方式，在这种情况下，带有照片的广告更有可能被购买。 意识到这种细微差别后，照片的价值就会增加。
我要存储在云中的数据量约为3-4 TB。 每天增加几千兆字节。 鉴于这项创新不会直接带来收入，因此只能间接影响访问者的决策，我想满足一个非常适中的预算是1000-2000 r。 每月。 这完全是免费的，但是我没有找到这样的机会。
蔚蓝
我以某种方式立即转向Azure，因为我在.net上工作，并且经常看到有关此主题的精美广告文章。 另外，我必须使用该平台来完成主要工作，但在那里，我的能力受到业务需求和管理层希望的限制。
Azure提供具有三个存储层的BLOB存储：热，酷和存档。 各个级别的价格都不同。 通常，温度越高，读/写越便宜，每月的存储费用也就越高，反之亦然。 热门-写/读和删除很多都是有利可图的，但是长时间存储很昂贵。 存档存储起来很便宜，但是读/写却很昂贵。 同样，在存档和冷级别，提早删除需要付费-这意味着，如果我在某个时期之前删除（或转移到另一个级别）对象，则仍然需要支付整个期间的费用。 对于存档级别，这是180天，对于寒冷-30天。
价钱
在归档级别，
存储成本为每月每GB 0.0023美元，冷存储为0.01美元，热
存储为0.0196美元。 以目前的汇率，这分别约为0.15、0.65和1.28卢布。
我将其与亚马逊和谷歌的成本进行了比较，结果发现Azure更便宜。
| 蔚蓝 | 亚马逊（S3） | 谷歌 |
| 热卖 | $ 0.0196 | $ 0.024 | $ 0.026 |
| 很酷 | 0.01美元 | 0.01美元 | 0.01美元 |
| 封存 | $ 0.0023 | $ 0.0045 | $ 0.007 |
除了存储成本外，还必须考虑到运营成本-它们在各个级别上都不同。 价格为10,000笔交易。
热卖读取：$ 0.0043，写入：$ 0.054
很酷读取：$ 0.01，写入：$ 0.10
封存读取：$ 6，写入：$ 0.12
工作逻辑
广告处于活动状态时，其中的照片通过第三方资源（来自合作伙伴）的链接显示。 公告从出版物中删除后，它成为档案，但指向照片的链接仍然存在一段时间。 迟早它们会消失，并且您需要确保此时有一个归档副本。
照片处理过程可以在以下步骤中进行描述：
- 广告从合作伙伴导入文件中消失后，即 如果伙伴停止发布，则在优先级队列中形成一个条目，其中优先级是访问者的视图数-视图越多，归档的可能性就越大，则将进一步查看该对象。
- 处理队列中的记录时，将形成一个BLOB对象，其中包含用于广告的缩小的照片（最多800x600）。 使用合成对象而不是直接拍摄照片也是由于节省了费用-代替执行8个记录操作（每个对象平均8张照片），而是执行一次，并且每次操作都需要花费金钱。
- 首先将BLOB加载到Hot中，然后立即将其传输到存档中。 无法直接写入存档，并且由于Cool提早删除需要付费，因此使用Hot进行传输会更便宜。
- 只要原始照片的链接处于活动状态，BLOB存档就可以使用（到目前为止，照片已通过合作伙伴的链接显示出来）。
- 当访问者访问对象的卡片时，将检查链接的功能-如果访问该卡片，则该对象很受欢迎，从存档中恢复照片很有意义。
- 如果原始照片的链接消失了，我会检查是否有存档副本，如果是，则会将存档中的还原请求发送到Cool（可能需要15个小时才能从存档中还原BLOB对象-这称为Microsoft的补液）。
- 从存档中还原BLOB后，会将其复制到本地存储中并分为普通照片。 本地存储是我服务器的硬盘。
- 公告卡上的照片已从本地存储中提供。
- 照片会在本地存储中存储几天。 如果在此期间进行了扫描，则将延长本地存储时间。 如果没有视图，则将照片从本地存储中删除，但仍保持在Azure的“酷”级别。
- 从Cool到Archive，如果两个月都没有视图，则将它们复制-该对象显然不受欢迎，因此，为Cool中的存储多付钱是没有道理的。
首次发射
在编写和测试过程时，是时候进行试运行了，预料会有麻烦。 当时队列中大约有1000万个对象，我决定从每天30,000个对象开始迁移。 在仪表板上设置漂亮的图形并开始观察。 在统计数据中，我看到了与GetBlobProperties请求有关的奇怪“陷阱”。 它们以大约一小时的相等间隔发生，总是在迁移开始后大约一个半小时开始，并在迁移完成后持续一段时间。
此类请求的数量太大，无法忽略。 我查看了日志，发现这些请求不是来自服务器，而是来自外部IP地址。 我根本不想付钱。
我在堆栈和文档中进行了搜索，但均无济于事。
在Stackoverflow和技术支持
上写了一个
问题 。 结果，在长期与技术支持联系并向他们提供日志后，他们告诉我他们可以重现这种情况，这是他们的错误。
一个有趣的细微差别是，我对Stackoverflow的问题的回答没有说明原因，而只是确认我将为这些请求付费，但是给出答案的人始终要求我将其标记为正确。 他还暗示要告诉我，不欢迎他们（支持）传播自己产品中的错误。 我让他知道，除非他写下真相，否则我不会这样做。 我可以自己写这个，但是我认为技术支持人员可能会测量已确认答案的数量，因此我请他写下真正的原因，在这种情况下，我将他的答案标记为正确。 经过一番犹豫之后，他同意了并在错误报告中补充了他的评论。 总的来说，我喜欢技术支持的工作方式-我甚至被转到了一位俄罗斯姑娘，她仍然让我知道这个问题的变化。
发现该错误的事实仅在道德上令我满意，但我希望将该机制投入运行，同时不为惯用左手的请求付钱。 特别是考虑到我通常会感到困惑，以最大程度地减少请求数，从而减少成本。
在技术支持中，建议我等待启动，几周后，他们写道该错误已修复，但是何时发布包含该修复程序的代码，尚不清楚。 他们提供了启用日志记录的功能，并在发布后要求Microsoft赔偿。 实际上，在此模式下，它仍然有效。 每天，我开始迁移少量对象，然后等待发布。
结论
每天30,000个物体的成本仍为900 p。 每月-这是完全可以接受的。 大多数费用是写操作。 因此，当处理完整个队列并开始计划的工作阶段时，将很清楚此类存储的实际成本是多少。 但是根据我的计算，这将在大约一年后发生。
当Azure Blob存储中将发布一个版本时，我将在此处添加是否设法获得补偿。 关于每月的支出，这大约是成本的10％。