我已经编写了一个将输出写入文件的程序。输出为6列n行格式，所有值均为双精度浮点数。在我的代码中，n通常变得非常大（1e20左右），因此输出数据文件也变得非常大。
我目前正在以* .csv格式存储所有内容，这显然会产生巨大的数据文件。有没有更有效的方法来存储这些值？任何新的文件格式或新方法会大大减小文件大小？
为了澄清：数据不必是人类可读的，二进制就可以了。我将进一步处理文件中的数据，以从运行中获取一些重要参数，可能是行进距离，在特定点的出口时间等。该代码实际上是对运动粒子的天体模拟，对于大约1e10个粒子，每百万个时间步长，它的大小变得相当大。
设计文件格式时，必须考虑各种因素，例如：
a）是否有可能该文件已损坏或被恶意篡改（或有任何保密要求）？答案几乎总是“是”。为了防止这些事情，您需要考虑某种校验和和/或加密。您可能还需要考虑是否需要部分恢复（例如，将文件拆分为多个块/部分，每个块都有自己的校验和/加密是否有益，因此，如果一个块/部分中的4个字节损坏，您仍然可以恢复大部分数据）。
b）是否有便携性问题？例如，如果将原始double值存储在文件中，它将在其他计算机上为“ double”使用不同二进制格式的计算机时产生问题吗？
c）对于每种类型的值；实际需要表示的范围是多少，精度要求是多少？通常，软件使用“更大且更精确”的软件（通常是因为它可以更快地选择CPU支持的下一个最大类型）。但是对于文件格式，这会导致文件大小不必要的增加。举个简单的例子；也许您可以将（64位）double转换为32位定点格式，将使用的空间减半，同时仍能达到实际所需的范围和精度。
d）是否有“巧妙”的方法来减小某些值所需的范围和精度？举个简单的例子；也许您有“起始值”和“结束值”，两者都需要64位；但是您可以将其转换为“起始值”和“差异”（以便可以将“终止值”计算为“起始值+差异”），其中“差异”值的范围较小，只需要32位即可存储。
e）任何一种索引都是有益的吗？举个简单的例子；如果文件可能包含一百万个条目，而您只想查找一个条目，则可以使用索引查找所需条目的偏移量，并且仅加载该条目（避免加载所有一百万个条目）。
f）您还需要其他什么元数据？可能是“魔术签名”（这样，软件可以检查文件是否应该符合文件格式，并且用户没有给您的程序提供错误的文件类型），例如“文件格式版本号” （以便程序可以“自动更新为新文件格式”或至少检测文件何时使用了不再受支持的过时/不推荐使用的文件格式）。它还可以包含用于识别诸如作者，谁来自数据，何时获得数据，哪个程序创建/准备了文件等信息的信息。有时还会有可选数据和标志，以说明可选数据。是否包含在文件中。您可能还需要诸如“条目数”和“每个不同区域的文件偏移量”之类的内容，等等。
g）您需要为可扩展性（以及向后兼容性和前向兼容性）留出哪些余地？通常，人们在标头中留下诸如“保留以供将来使用”字段之类的内容，以便他们将来可以添加/更改/扩展文件格式而不会破坏所有内容。有时，这甚至更具体地说明了软件在不支持的保留字段中看到值时应执行的操作，例如“保留，供将来使用，如果非零软件应忽略该值，则应为零”与“保留给以后的使用，应为零；如果非零（由于将来使用），软件应生成错误而不使用文件”
h）哪种压缩技术有用吗？举一个简单的例子，如果您有带有索引的“ 6列，N行”，有时两行或更多行的数据恰好是相同的；那么也许您只能为这些行存储一个数据副本，然后使用索引来找出哪一行使用哪些数据（有点像“ row[n] = unique_row_data[ index[n] ]”）。