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