嵌入用于数字数据的 SQLite / Firebird

Question

我有一个实验，以 1Mb/s 的速度传输数字数据，需要存储这些数据以供以后处理。直接写入数据库似乎与写入 CSV 文件一样容易，然后我就能够轻松检索子集或范围。

我有使用 sqlite2 的经验（当它只有文本字段时），它看起来与原始磁盘访问一样快。对于当前最适合此应用程序的进程内 DBMS 有什么意见吗？

抱歉 - 应该添加这是 Windows 上的 C++，但跨平台很好。理想情况下，数据库二进制文件格式应该是跨平台的。

Answer 1

如果您只需要读/写数据，而不需要在数据库中进行任何检查或操作，那么两者都应该可以很好地完成。Firebird的数据库文件可以被复制，只要系统具有相同的字节序（即您无法在具有 Intel 和 PPC 处理器的系统之间复制文件，但 Intel-Intel 没问题）。

但是，如果您需要对数据执行任何操作，而不仅仅是简单的读/写，那么请使用 Firebird，因为它是一个完整的 SQL 服务器，具有所有“企业”功能，如触发器、视图、存储过程、临时表、 ETC。

顺便说一句，如果您决定尝试 Firebird，我强烈建议您使用 IBPP 库来访问它。它是 Firebird 的 C API 的一个非常薄的 C++ 包装器。我有大约 10 个类，它们封装了所有内容，并且非常易于使用。

Answer 2

如果您只想存储数字并能够轻松进行范围查询，则可以采用 STL 中可用的任何标准树数据结构并将其序列化到磁盘。这可能会在跨平台环境中困扰您，尤其是当您尝试跨架构时。

就更灵活/人性化的解决方案而言，sqlite3被广泛使用，坚固，稳定，各方面都非常好。

BerkeleyDB 有许多值得使用的好特性，但恕我直言，它们都不适用于这种情况。

如果您可以接受许可协议，我会说使用 sqlite3。

-D

Answer 3

取决于您使用的语言。如果是C/C++、TCL、PHP，在单编写器场景中SQLite仍然是最好的。如果您不需要 SQL 访问，berkeley DB 风格的库可能会稍微快一些，例如 Sleepycat 或 gdbm。对于多个编写器，您可以考虑单独的客户端/服务器解决方案，但听起来您并不需要它。如果您使用 Java，hdqldb 或 derby（以“JavaDB”品牌随 Sun 的 JVM 一起提供）似乎是首选的解决方案。

Answer 4

您可能还需要考虑专门用于存储这些类型的大型数据集的数字数据文件格式。例如：

• 高密度纤维束 -- 在许多语言中最常见且受良好支持的免费库。我强烈推荐这个。
• CDF -- NASA 使用的类似格式（但任何人都可以使用）。
• 网络CDF -- 另一种类似的格式（最新版本实际上是精简版 HDF5）。

此链接提供了有关上述数据集类型之间差异的一些信息：http://nssdc.gsfc.nasa.gov/cdf/html/FAQ.html

Answer 5

我怀疑这两个数据库都不允许你以如此高的速度写入数据。您可以自己检查一下以确定。根据我的经验 - 对于具有单个整数主键的非常简单的表，SQLite 无法每秒插入超过 1000 行。

如果出现性能问题 - 我会使用 CSV 格式写入文件，然后将其数据加载到数据库（SQLite 或 Firebird）以进行进一步处理。