database - 与存储系统性质相关的大容量存储图像格式

Question

现在，我已经阅读了这些可能与这个问题有关的问题: Scalable Image Storage , Large scale image storage , https://serverfault.com/q/95444 .

在我问问题之前，我发现了以下事情:

1. Facebook uses Haystack (something CLOSED-SOURCE to the open-source world) 
which is very efficient. Its a form of File system storage, engineered for speed
 and large metadata management.
2. Any Operating System has a file limit in directories and may start to perform 
extremely poorly when this limit is being exceeded.
3. Most NoSQL developers, have found it easy to use CouchDB / CouchBase Server
 to handle images as it handles it as an attachment, glued to a document (record
 in the database). However, still, this is file system storage.
4. HDFS, NFS, ZFS, are all File systems that may make it easy to handle large
 distributed data. However, at applications like facebook, they could not help
5. Any proper form of caching is very essential to highly Image dependent
 applications
6. Some PHP developers (mostly) have used MySQL to keep image meta-data while
 creating folders and sub-folders (matching the meta-info) on the file system.
 Each image will have a random hash name in relation to the meta-data in the 
database to enable fast location on the file system

在理解了这些陈述和更多其他陈述之后，我开始意识到在文件系统上保留数十亿不断增长的图像是非常昂贵的。如果有人使用像 Amazon S3 这样的云存储，它会因为高图像流量和应用程序的存储而扼杀业务。

我已经评估了CouchBase Server的使用，将图像作为附件进行管理。然而，对于图像增长应用程序，这也是一个文件系统存储，我想知道如果成百上千的人同时访问图像，Couch base 会如何表现。我可以使用 Cloudant/Big Couch它具有自动分片/负载平衡。重点仍然是 NoSQL 解决方案也会将图像保存在文件系统上，当以高并发率请求图像时，这可能会导致整个服务宕机(图像可能很重)。

我的想法

我正在考虑将我的图像管理为 SVG格式。这是因为，我认为我可以将此 SVG 数据视为存储中的文本。现在，大多数 NoSQL 数据库对文档(记录)大小的大小限制至少不超过 4MB(不确定)。这就带来了一个问题，因为根据图像的不同，SVG 文件甚至可以达到 6-10MB。所以，我认为我不能将 Couch 基本服务器用于 SVG 存储。此外，应用程序的本质是，图像数据不断增长并且永远不会存档/永远不会删除:沙发底座不适合此类数据(高度持久和不变的数据)。

这带来了我回到以良好的文本压缩而闻名的 RDBMS(尤其是 Oracle)。如果我获得 SVG 数据及其元数据并将其作为 BLOB 存储在 Oracle 数据库中，我觉得这可行。我听说 Oracle 表甚至可以增长到 TB，可能是通过分区或某种碎片。但重点是，对于一个达到 20GB 的包含文本的 oracle 表，我认为这将是大量数据。
现在，我的问题来自上述所有发现:

1。为什么开发人员一直选择文件系统存储图像而不是 SVG，在我(可能天真)的想法中，SVG 可以作为文本处理，因此可以压缩、加密、消化、拆分、轻松存储等。 ？

2.当应用程序将图像完全作为 SVG 处理时，将 SVG 提供给浏览器而不是实际的图像文件时，会有什么复杂性？

3. 从技术上讲，哪个对 Web 服务器的内存干扰更大:提供从文件系统(.png、.jpg、.gif)读取的图像和提供作为 SVG 的图像(可能来自数据库，或来自中间层)特别是在重负载下，Facebook 的示例场景？

4.在不同的“缩放”或分辨率下呈现时，SVG 似乎并没有降低质量，为什么开发人员还没有在图像动态应用程序中大量使用 SVG？我的意思是，从 PNG、JPG 或 GIF 转换为 SVG 时是否存在任何已知的质量损失？

5. 我对使用像 Oracle/MySQL Cluster 这样的 RDBMS 来存储高度持久的元数据和持久的 SVG 数据的看法是否非常幼稚？

请高亮显示，并给出您对大图像存储格式的建议。谢谢

编辑/更新

有像 Image Magick 这样的工具它提供用于操作图像的命令行选项。我需要的最重要的想法可能是: Can CouchBase Server(无论是 single server 还是 version 2.0 capability to serve Images at "user-experience acceptable performance"或者在“社交网络规模”？)

Answer 1

关于数据库

什么是文件而不是数据，什么是文件系统而不是数据库？数据库中的记录、文件系统中的文件、KV 存储中的键和值 - 这些都是同一棵树的果实。

普通文件系统经过数十年的发展，旨在实现在本地传输文件的目的 - 在此基础上，您可以构建分发模型。

HDFS 之类的东西包括分发作为文件系统本身的一部分，但是当您尝试在本地处理文件时会产生不必要的开销。

关系数据库或 KV 存储之类的东西可能会帮助您布置图表或轻松存储更多元数据，但除非它们专门设计为用作文件存储系统 - 它们会失败。

选择存储系统需要权衡取舍，您需要找出解决问题的最佳方案。很有可能您的问题与 facebook 的问题相去甚远。很少有服务器在它们之上安装 cdn，你会没事的。

关于文件格式

1. SVG 不适用于普通图片，别想了。
2. 在大范围内，您希望在接受文件时进行最少数量的转换:如果图像不符合您的要求并存储它，则重新缩放/压缩/裁剪图像。除非您对这些图像施展魔法，否则您不想将它们转换成不同的格式或在没有真正需要的情况下压缩它们。
3. 在大规模情况下，您希望您的文件是(按优先级排序):
   • 从客户端的缓存中获取
   • 从操作系统缓存/内存中获取
   • 直接从文件系统提供服务