1

现在，我已经阅读了这些可能与这个问题有关的问题：可扩展的图像存储，大规模图像存储，https://serverfault.com/q/95444。

在我问我的问题之前，我发现了以下几点：

1. Facebook 使用Haystack（开源世界的 CLOSED-SOURCE）
，非常高效。它是一种文件系统存储形式，专为速度
和大型元数据管理而设计。
2. 任何操作系统在目录中都有一个文件限制，
当超过这个限制时，可能会开始执行极差。3. 大多数 NoSQL 开发人员发现使用CouchDB / CouchBase Server
处理图像很容易，因为它将图像作为附件处理，粘贴到文档（数据库中的记录）。但是，这仍然是文件系统存储。4、HDFS、NFS、ZFS，都是可以轻松处理大型文件的文件系统



分布式数据。然而，在像 facebook 这样的应用程序中，他们无能为力5. 任何适当形式的缓存对于高度依赖图像的应用程序
都非常重要6. 一些 PHP 开发人员（大多数）在创建文件夹和子文件夹时使用 MySQL 来保存图像元数据（匹配元信息）在文件系统上。每个图像将具有与数据库中的元数据相关的随机散列名称，以实现在文件系统上的快速定位




在理解了这些陈述和更多其他陈述之后，我开始意识到在文件系统上保留数十亿不断增长的图像非常昂贵。如果有人使用云存储之类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 转换为 GIF 时是否有任何已知的质量损失SVG？

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

请突出显示，并就大型图像存储格式提出您的建议。谢谢

编辑/更新

有像Image Magick这样的工具提供了用于操作图像的命令行选项。我需要的最重要的想法可能是：CouchBase Server（是否single server能够version 2.0以“用户体验可接受的性能”或“社交网络规模”提供图像？）

4

4 回答 4

1

首先，我想提一下，您对图像文件格式的理解可能很幼稚，因为您没有提供很多细节。您打算如何存储（例如）PNG 图像“作为 SVG 格式”？

我不能回答你所有的问题，但我会尽力的。

  1. “文件系统或 SVG”是一种错误的二分法，很容易将 JPG blob 存储在数据库中，或者将 SVG 文件存储在文件系统存储中。您也可以将任何位图图像格式作为文本处理。如果您想要一个示例，请尝试打开一个带有嵌入位图数据的 PostScript 文件。您关于“为什么不”的问题意味着两者是可以互换的，而且通常不是。例如，我的公司评估了一系列不同的文件存储格式，根据具体情况，我们选择了 PDF（不寒而栗）和 PS。我们没有使用 SVG 有两个原因；首先是多页文档在官方标准中，SVG 编辑器和查看器似乎对它们有不稳定的支持。其次，SVG 在以自动化方式打印时会出现一些复杂情况（为了演示，请尝试这个实验：创建一个 SVG 文件和一个等效的 PostScript 文件，然后尝试使用 打印两者lp）。

  2. 我已经提到了两个（尽管如果你正在处理一个网络应用程序，那么两者都不应该咬你，因为你的客户可能会使用浏览器的渲染引擎，你可能不需要超过一页）。唯一的另一个是浏览器支持，这在旧版本的 IE 上一如既往地不稳定。您还必须了解字体情况；要么确保任何花哨的排版被视为路径，要么确保只使用你知道观众可以访问的字体（对于网络应用程序，CSS3 在那里有点帮助）。

  3. SVG 和其他矢量/过程表示往往更小，所以我倾向于说它们对服务器来说更容易处理。这不是基于任何测试，因此请谨慎对待。请记住，它们确实倾向于在客户端消耗更多资源，但这在 Web 情况下应该不是什么大问题。

  4. 如果您的图像可以表示为 SVG，是的，非常好的主意。然而，将任意位图转换为矢量表示是 AFAIK 一个未解决的问题。有些东西不能很好地转换，即使是手动转换，有些东西在以 SVG 表示时实际上比以 JPG 表示时更大。对于诸如商业文档、流程图或排版之类的东西，矢量绝对是更好的（除了我上面提到的字体问题）。某些类型的插图作为矢量效果更好，有些作为光栅效果更好。最后，如果您从位图（例如照片）开始，将其转换为 SVG 会明显降低质量，或者需要大量的手动时间（如果可以做得很好的话）。

  5. 这是我无法真正回答的问题，因为我从来没有按照您的目标建造任何东西。

于 2012-07-16T13:18:52.040 回答
1

关于数据库

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

纯文件系统已经开发了数十年，以服务于在本地交付文件的目的——在此之上，您可以构建一个分发模型。

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

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

挑选存储系统就是权衡取舍，由您决定什么是解决问题的最佳方案。您的问题可能与 facebook 的问题相差甚远。很少有带有cdn的服务器，你会没事的。

关于文件格式

  1. SVG 不适用于常规图片，甚至不要梦想它。
  2. 在接受文件时，您希望在大规模上进行最少的转换：如果图像不符合您的要求并存储它，请重新缩放/压缩/裁剪图像。除非你对这些图像做了一些魔法，否则你不想将它们转换成不同的格式或在没有真正需要的情况下压缩它们。
  3. 在大规模上，您希望您的文件是（按优先级排序）：
    • 从客户端的缓存中提供
    • 从操作系统缓存/内存提供
    • 直接从文件系统提供
于 2012-07-16T16:25:19.950 回答
1

我建议将您的图像存储在 S3 中——不要担心自己滚动，直到经济迫使您这样做。与您的 blob 的存储方式相比，担心用户关心的事情要好得多。

就 Couchbase（我是联合创始人）而言，我们看到人们在类似的用例中使用它：通常用于元数据和图像跟踪（谁拥有它、时间戳、标签，基本上是您想要存储或查询的任何东西。） Couchbase 记录然后将只包含存储在 S3 上的实际图像的 URL。

于 2012-07-17T04:21:12.213 回答
0

“SVG 不适用于常规图片，甚至不要梦想它。”

“然而，将任意位图转换为矢量表示是 AFAIK 的一个悬而未决的问题。有些东西不能很好地转换，即使是手动的，有些东西在以 SVG 表示时实际上比以 JPG 表示时更大。”

我认为这两种说法都是错误的。

https://sites.google.com/site/jcdsvg/svg_paradoxes.svg

参见示例三和四。猫图像保存为中等分辨率的 png 文件，允许图像的缩放为高分辨率。它的文件大小比普通的网络图像要大，但这是故意的。

将位图图像存储为 SVG 就像将它们放入 SVG 容器中一样简单。

于 2012-07-25T00:21:17.960 回答