我正在编写一个应用程序，它解析一个大文件，生成大量数据并用它做一些复杂的可视化。由于所有这些数据都无法保存在内存中，我做了一些研究，我开始将嵌入式数据库视为此数据的临时容器。
我的问题是：这是解决这个问题的传统方式吗？应该通过在内存中仅保留一个子集（如缓存）来管理数据的嵌入式数据库（除结构化数据之外），而其余数据库保留在磁盘上？谢谢。
编辑：澄清：我正在编写一个桌面应用程序。应用程序将输入大小为100s Mb的文件。在读取文件后，应用程序将生成大量可视化的图形。由于图形可能具有如此大量的节点，因此它们可能不适合存储器。我应该将它们保存到嵌入式数据库中，该数据库将仅保留内存中的相关数据吗？ （嵌入式数据库会这样做吗？），或者我应该编写自己的复杂模块来做到这一点？
答案 0 :(得分：7)
棘手的问题 - 但我会分享我的经验，让你决定是否有帮助。
如果您需要保留处理源文件的输出，并使用它来生成派生数据的多个视图，那么您可能考虑使用嵌入式数据库。使用嵌入式数据库（IMHO）的原因：
做出决定时应考虑的因素：
在典型的现代桌面上，有足够的备用容量来处理大多数操作。在eeePC，PDA和其他便携式设备上，也许不是。在嵌入式设备上，很可能不是。您使用的语言可能具有内置功能以帮助进行内存管理 - 也许您可以利用这些功能。连接方面（有状态/无状态/等）可能会影响您在任何给定点上确实需要保留多少内存。
如果您正在处理非常大的文件，那么您可能会考虑使用流式处理方法，因此您一次只能在内存中获得一小部分整体数据 - 但这并不是真的意味着您应该（或不应该）使用嵌入式数据库。直接文本或二进制文件也可以正常工作（基于记录，基于列，基于行...等等。）
一些数据库将允许您在存储数据后更有效地与数据交互 - 这取决于引擎。我发现如果您的基本文件中需要大量聚合（我指的是您最初从原始源生成的文件），那么RDBMS引擎可以非常有助于简化您的逻辑。其他选项包括构建基本转换，然后添加其他步骤以将其处理到每个特定视图的其他临时存储中，然后处理这些步骤以呈现为目标（报告？）格式。
只是一种意识流的反应 - 希望有所帮助。
编辑：
根据您的进一步说明，我不确定嵌入式数据库是您想要的方向。你需要做一些简化的假设来渲染你的图形或研究像分割这样的方法（渲染图形的部分，然后在渲染下一部分之前缓存输出）。