2

在讨论下一代科学数据格式时，需要某种类似 JSON 的数据结构（已确定字段的逻辑分组。此外，最好利用现有编码而不是使用自定义二进制结构。对于序列化格式有很多选择。感谢那些对这些编码有经验的人提供的任何指导或见解。

要求：在我们的格式中，数据需要打包成记录，通常不大于 4096 字节。每条记录必须是独立可用的。数据必须在未来几十年内可读。数据归档和交换是通过存储和传输一系列记录来完成的。数据损坏必须只影响损坏的记录，使文件/流/对象中的所有其他记录可读。

优先事项（大致按顺序）是：

  • 稳定性，长期存档使用
  • 性能，主要是阅读
  • 存储不透明斑点的能力
  • 尺寸
  • 简单
  • 广泛的软件（又名库）支持
  • 流能力，传输和可读作为记录生成（如果可能的话）

我们已经开始研究 Protobuf（协议缓冲区 RFC）、CBOR（RFC）和一些MessagePack。

任何有经验的人提供的任何信息都将帮助我们确定最合适的方案，或者更重要的是，避免陷阱和死胡同，我们将不胜感激。

提前致谢！

4

2 回答 2

4

迟到的答案，但是：您可能需要决定是否需要基于模式的格式或自描述格式。Amazon Ion概述讨论了这些设计决策的一些优缺点，以及其他ION（与 Amazon Ion 完全不同）。

这些都不完全符合您的标准，但这些文章应列出您可能要考虑的一些标准。显然，实际上成为标准并被采用比任何技术设计标准都更能保证寿命

于 2017-12-30T19:50:25.700 回答
3

您从数据损坏中恢复的目标几乎肯定应该在一个单独的架构层中解决，而不是记录编码的问题。将多少条记录打包到一个 blob/文件/流中实际上与您在找到您可能需要的记录之前可以按顺序读取多少条记录更相关。

存储损坏的最佳解决方案取决于您认为可能发生的损坏类型。例如，如果您将数据存储在旋转磁盘上，则最佳保护可能与将数据存储在磁带上不同。但其中的细节确实不是应用程序级别的问题。最好抽象/外包这种关注。

现代基于云的数据存储服务提供了极其强大的防腐败保护，在行业中被称为“耐用性”。例如，即使是 Microsoft Azure 成本最低的存储选项，本地冗余存储 (LRS)，也至少存储接收到的任何数据的三个不同副本，并且只要您愿意，至少可以保持该级别的保护。如果任何副本损坏，将尽快从未损坏的副本中制作另一个副本。这导致每年 11 个 9 的“耐用性”（99.999999999% 的耐用性），这就是微软的“低成本”选项。正常的冗余计划 Geo Redundant Storage (GRS) 提供超过 16 个 9 的持久性。请参阅Azure 存储冗余。

根据 Wasabi 的说法，11 个九的持久性意味着如果您存储了 100 万个文件，则每 659,000 年您可能会丢失一个文件。你被流星击中的可能性是丢失文件的 411 倍。

PS 我之前曾在 Microsoft Azure 存储团队工作，所以这是我最了解的服务。但是，我相信其他云存储选项（例如 Wasabi 和 Amazon 的 S3）提供类似的持久性保护，例如 Amazon S3 Standard 和 Wasabi 热存储就像 Azure LRS：11 个九的持久性。如果您不担心流星撞击，您可以放心，这些服务不会很快丢失您的数据。

于 2018-04-30T00:01:32.010 回答