6

我正在编写一个应用程序,它解析一个大文件,生成大量数据并用它做一些复杂的可视化。由于无法将所有这些数据保存在内存中,因此我进行了一些研究,并开始考虑将嵌入式数据库作为这些数据的临时容器。

我的问题是:这是解决这个问题的传统方法吗?嵌入式数据库(结构化数据除外)是否应该通过仅在内存中保留一个子集(如缓存)来管理数据,而其余的则保留在磁盘上?谢谢你。

编辑:澄清:我正在编写一个桌面应用程序。应用程序将输入一个大小为 100s 的 Mb 文件。读取文件后,应用程序将生成大量图形,这些图形将被可视化。由于图可能有如此多的节点,它们可能不适合内存。我应该将它们保存到一个嵌入式数据库中,该数据库只负责将相关数据保存在内存中吗?(嵌入式数据库会这样做吗?),还是我应该编写自己的复杂模块来做到这一点?

4

1 回答 1

9

棘手的问题 - 但我会分享我的经验,让你决定它是否有帮助。

如果您需要保留处理源文件的输出,并使用它来生成派生数据的多个视图,那么您可以考虑使用嵌入式数据库。使用嵌入式数据库(恕我直言)的原因:

  • 利用 RDBMS 功能(ACID、关系、外键、约束、触发器、聚合......)
  • 为了更容易以灵活的方式导出数据
  • 允许外部客户端访问您处理的数据(已知格式)
  • 在准备查看时允许更灵活地转换数据

做出决定时应考虑的因素:

  • 目标平台是什么(windows、linux、android、iPhone、PDA)?
  • 有什么技术基础?(Java、.Net、C、C++、...)
  • 预期或需要针对哪些资源限制进行设计?(RAM、CPU、硬盘空间)
  • 您需要考虑哪些操作行为(连接到网络、断开连接)?

在典型的现代桌面上,有足够的备用容量来处理大多数操作。在 eeePC、PDA 和其他便携式设备上,可能不是。在嵌入式设备上,很可能不会。您使用的语言可能具有帮助内存管理的内置功能 - 也许您可以利用这些功能。连接方面(有状态/无状态/等)可能会影响您在任何给定点真正需要保留多少内存。

如果您正在处理非常大的文件,那么您可能会考虑使用流式处理方法,这样您一次只能在内存中保存一小部分整体数据 - 但这并不意味着您应该(或不应该)使用嵌入式数据库。纯文本或二进制文件也可以正常工作(基于记录、基于列、基于行……等等)。

某些数据库将允许您在数据存储后以更有效的方式与数据进行交互——这取决于引擎。我发现如果您的基本文件(我的意思是您最初从原始源生成的文件)中需要大量聚合,那么 RDBMS 引擎对于简化逻辑非常有帮助。其他选项包括构建您的基本转换,然后添加额外的步骤以将其处理到每个特定视图的其他临时存储中,然后依次处理这些转换以呈现为目标(报告?)格式。

只是一种意识流反应——希望能有所帮助。

编辑:

根据您的进一步说明,我不确定嵌入式数据库是您想要采取的方向。您要么需要为渲染图形做出某种简化假设,要么研究分段等方法(渲染图形的各个部分,然后在渲染下一部分之前缓存输出)。

于 2010-06-24T09:23:08.190 回答