Xml 或 Sqlite，何时为数据库删除 Xml？ [关闭]

Question

就目前而言，这个问题不适合我们的问答形式。 我们希望答案得到事实、参考资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。 如果您认为此问题可以改进并可能重新打开，请访问帮助中心获取指导。

10年前关闭。

我真的很喜欢 Xml 来保存数据，但是 sqlite/database 什么时候会成为更好的选择？ 例如，当 xml 有超过x 个项目或大于y MB 时？

我正在编写一个 rss 阅读器，我相信我在使用 xml 而不是 sqlite 数据库来存储所有提要项的缓存时做出了错误的选择。 有些提要一个月后的 xml 文件约为 1mb，另一些提要有超过 700 项，而大多数只有约 30 项，几个月后大小约为 50kb。

我目前没有计划实施上限，因为我喜欢能够搜索所有内容。

所以，我的问题是：

1. sqlite/数据库的开销何时比使用 xml 更合理？
2. 当有很多小文件时，少数几个大的 xml 文件是否足以满足数据库的要求，尽管即使是小的文件也会随着时间的推移而增长？ （很久很久）

更新（更多信息）

每次在 GUI 中选择一个提要时，我都会从该提要 xml 文件中重新加载所有项目。

我还需要修改已读/未读状态，当我遍历 xml 中的所有节点以查找该项目然后将其设置为已读/未读时，这似乎真的很糟糕。

Answer 1

伙计，我有这方面的经验。 我在一个项目中工作，我们最初使用 XML 存储所有数据，然后转移到 SQLite。 每种技术都有很多优点和缺点，但导致转换的是性能。 这是我们观察到的。

对于小型数据库（几兆或更小），XML 速度更快，也更容易处理。 我们的数据自然采用树格式，这使得 XML 更具吸引力，而 XPath 允许我们在一行中执行许多查询，而不必沿着祖先树走下去。

我们在 Win32 环境中编程，并使用标准的 Microsoft DOM 库。 我们会将所有数据加载到内存中，将其解析为 DOM 树，然后在内存中的副本上搜索、添加、修改。 我们会定期保存数据，并且需要轮换副本，以防机器在写入过程中崩溃。

我们还需要使用 C++ 树映射手动建立一些“索引”。 当然，这对于 SQL 来说是微不足道的。

请注意，文件系统上的数据大小比“内存中”的 DOM 树小 2-4 倍。

当数据达到 10M-100M 大小时，我们开始遇到真正的问题。 有趣的是，在所有数据大小下，XML 处理都比 SQLite 快得多（因为它在内存中，而不是在硬盘上）！ 问题实际上是双重的——首先，加载时间真的开始变长。 在数据进入内存并构建地图之前，我们需要等待一分钟左右。 当然，一旦加载程序非常快。 第二个问题是所有这些内存一直被占用。 即使我们运行得非常快，只有几百兆的系统在其他应用程序中也会无响应。

我们实际上正在研究使用基于文件系统的 XML 数据库。 有几个开源版本的 XML 数据库，我们试过了。 我从未尝试过使用商业 XML 数据库，所以我无法评论它们。 不幸的是，我们根本无法让 XML 数据库正常工作。 即使是用数百兆 XML 填充数据库的行为也需要几个小时......也许我们使用不正确。 另一个问题是这些数据库非常重量级。 他们需要 Java 并且拥有完整的客户端服务器架构。 我们放弃了这个想法。

那时我们找到了 SQLite。 它解决了我们的问题，但要付出代价。 当我们最初插入 SQLite 时，内存和加载时间问题就消失了。 不幸的是，由于现在所有处理都在硬盘驱动器上完成，后台处理负载大大增加。 虽然早些时候我们甚至没有注意到 CPU 负载，但现在处理器使用率上升了。 我们需要优化代码，并且仍然需要在内存中保留一些数据。 我们还需要将许多简单的 XPath 查询重写为复杂的多查询算法。

所以这里是我们学到的总结。

1. 对于树数据，使用 XPath 更容易查询和修改 XML。

2. 对于小型数据集（小于 10M），XML 在性能上击败了 SQLite。

3. 对于大型数据集（大于 10M-100M），XML 加载时间和内存使用成为一个大问题，以至于一些计算机变得无法使用。

4. 我们无法获得任何开源 XML 数据库来解决与大型数据集相关的问题。

5. SQLite 没有 XML DOM 的内存问题，但它处理数据的速度通常较慢（它在硬盘驱动器上，而不是在内存中）。 （注意——SQLite 表可以存储在内存中，也许这样可以让它更快......我们没有尝试这个，因为我们想从内存中获取数据。）

6. 在表中存储和查询树数据并不令人愉快。 但是，管理事务和索引部分弥补了这一点。

Answer 2

我基本上同意Mitchel的观点，这可能是非常具体的，具体取决于您要使用 XML 和 SQLite 做什么。 对于您的情况（缓存），在我看来，使用 SQLite（或其他嵌入式数据库）更有意义。

首先，我并不认为 SQLite 需要比 XML 更多的开销。 我的意思是开发时间开销和运行时开销。 唯一的问题是您依赖于 SQLite 库。 但是由于无论如何您都需要一些 XML 库，所以这并不重要（我假设项目是 C/C++ 中的）。

SQLite 相对于 XML 的优势：

• 一切都在一个文件中，
• 随着缓存变大，性能损失低于 XML，
• 您可以将提要元数据与缓存本身（其他表）分开，但可以以相同的方式访问，
• 对于大多数人来说，SQL 可能比 XPath 更容易使用。

SQLite 的缺点：

• 访问同一数据库的多个进程可能会出现问题（可能不是您的情况），
• 你至少应该知道基本的 SQL。 除非缓存中有数十万个项目，否则我认为您不需要对其进行太多优化，
• 从安全的角度来看（SQL 注入），它可能在某种程度上更危险。 另一方面，您不是在编写 Web 应用程序，所以这不应该发生。

这两种解决方案的其他事情可能都差不多。

总结一下，分别回答你的问题：

1. 你不会知道，除非你用两个后端测试你的特定应用程序。 否则它总是只是一个猜测。 对两个缓存的基本支持对代码来说应该不是问题。 然后进行基准测试和比较。

2. 由于 XML 文件的组织方式，SQLite 搜索应该总是更快（除非在某些极端情况下它并不重要，因为它非常快）。 无论如何，加速 XML 中的搜索都需要索引数据库，在您的情况下，这意味着缓存用于缓存，这不是一个特别好的主意。 但是使用 SQLite，您可以将索引作为数据库的一部分。

Answer 3

不要忘记您有一个触手可及的出色数据库：文件系统！

许多程序员忘记了一个像样的目录文件结构是/具有：

1. 它快得像地狱
2. 它是便携式的
3. 它的运行时占用空间很小

人们正在谈论将 XML 文件拆分为多个 XML 文件...我会考虑将您的 XML 拆分为多个目录和多个纯文本文件。

搏一搏。 速度快得令人耳目一新。

Answer 4

1. 将 XML 用于应用程序应该知道的数据 - 配置、日志记录等等。
2. 将数据库（oracle、SQL server 等）用于用户直接或间接交互的数据 - 真实数据
3. 如果用户数据更像是一个序列化的集合，请使用 SQLite——比如巨大的文件列表及其内容或电子邮件项目的集合等。SQLite 擅长于此。

取决于数据的种类和大小。

Answer 5

我不会使用 XML 来存储 RSS 项目。 提要阅读器在接收数据时会不断更新。

使用 XML，您需要先从文件中加载数据，解析它，然后存储它以便于搜索/检索/更新。 好像是数据库...

另外，如果您的应用程序崩溃了怎么办？ 如果使用 XML，XML 文件中的数据与内存中的数据是什么状态。 至少使用 SQLite，您可以获得原子性，因此您可以放心，您的应用程序将以与上次数据库写入时相同的状态开始。

Answer 6

当您需要将数据从应用程序移动到其他地方或在应用程序之间共享信息时，XML 最适合用作交换格式。 数据库应该是几乎任何规模的应用程序的首选存储方法。

Answer 7

什么时候应该使用 XML 而不是数据库来实现数据持久性？ 几乎从不。 XML 是一种数据传输语言。 解析速度慢，查询麻烦。 解析 XML（不要分解它！）并将生成的数据转换为域对象。 然后持久化域对象。 持久性数据库的一个主要优势是 SQL，这意味着非结构化查询以及对常用工具和优化技术的访问。

Answer 8

对我来说，这实际上取决于您对它们做什么，有多少用户/进程需要同时访问它们等。

我一直在处理大型 XML 文件，但它们是单个进程、导入样式项、多用户或性能并不是真正需要的。

所以真的是一种平衡。

Answer 9

我已经切换到 SQLite，知道它在数据库中我感觉好多了。

这样做还有很多其他好处：

• 添加新项目非常简单
• 按多列排序
• 删除具有唯一索引的重复项

我创建了 2 个视图，一个用于未读项目，一个用于所有项目，不确定这是否是视图的最佳用途，但我真的很想尝试使用它们。

我还使用StopWatch类对 xml 与 sqlite 进行了基准测试，并且 sqlite 更快，尽管可能只是我解析 xml 文件的方式不是最快的方法。

1. 小# 项和大小（25 项，30kb）
   • ~1.5 毫秒 sqlite
   • ~8.0 毫秒 xml
2. 大量项目（700 个项目，350kb）
   • ~20 毫秒 sqlite
   • ~25 毫秒 xml
3. 大文件大小（850 项，1024kb）
   • ~45 毫秒 sqlite
   • ~60 毫秒 xml

Answer 10

如果您需要扩展，请使用数据库。

Answer 11

XML 非常适合存储不完全结构化的数据，并且您通常希望与另一个应用程序交换它。 我更喜欢使用 SQL 数据库存储数据。 XML 容易出错，因为数据本身的拼写错误或遗漏可能会导致细微的错误。 一些开源应用程序框架使用太多的xml文件来进行配置、数据等，我更喜欢在SQL中拥有它。

由于您要求经验法则，我会说如果您要设置一次而不是访问/搜索太多，请使用基于 XML 的应用程序数据、配置等。 对于主动搜索和更新，最好使用 SQL。

例如，Web 服务器将应用程序数据存储在 XML 文件中，而您实际上并不需要执行复杂的搜索、更新文件。 Web 服务器启动，读取 xml 文件，仅此而已。 所以 XML 在这里是完美的。 假设您使用像 Struts 这样的框架。 您需要使用 XML，并且一旦开发和部署了应用程序，操作配置就不会发生太大变化。 同样，XML 文件是一个好方法。 现在，如果您的 Struts 开发的应用程序允许广泛的搜索和更新、删除，那么 SQL 是最佳方式。

当然，您肯定会在您的组织中遇到一两个开发人员，他们只会高呼 XML 或 SQL，并宣称 XML 或 SQL 是唯一的出路。 提防这些人，并为您的应用程序做“感觉”正确的事情。 不要只遵循“技术宗教”。

想想你需要多久更新一次数据，多久需要搜索一次数据。 然后，您将获得关于使用什么的答案——XML 或 SQL。

Answer 12

我同意@Bradley。

XML 非常慢，并且作为一种存储格式并不是特别有用。 何必？ 您会使用文本编辑器手动编辑数据吗？ 如果是这样，与 YAML 之类的格式相比，XML仍然不是一种非常方便的格式。 使用 SQlite 之类的东西，查询更容易编写，并且有一个定义明确的 API 用于输入和输出数据。

如果您需要在程序之间发送数据，XML 很好。 但是以效率的名义，您可能应该在发送时生成 XML，并在接收时将其解析为“真实数据”。

以上所有意味着您关于“何时证明数据库的开销是合理的”的问题有点没有实际意义。 XML 总是比 SQlite 有更高的开销。 （像 MSSQL 这样的完整数据库更重，尤其是在管理开销方面，但这是一个完全不同的问题。）

Answer 13

XML 可以存储为文本和二进制文件格式。

如果您的主要目标是让计算机有效地读取/写入文件格式，您应该使用二进制文件格式。

数据库是一种易于使用的存储和维护数据的方式。 它们不是存储二进制文件格式数据的最快方式。

可以加快速度的是使用内存数据库/数据库类型。 Sqlite 有这个选项。

这听起来像是为您做这件事的最佳方式。

Answer 14

我的意见是，只要您不需要纯文本文件格式，就应该使用 SQLite（或其他合适的嵌入式数据库）。 请注意，这是一个很大的例外。 有很多场景需要纯文本文件格式，或者受益于纯文本文件格式。

就开销而言，SQLite 编译为带有正常标志的 250 k 之类的东西。 许多 XML 解析库都比 SQLite 大。 使用 XML 不会获得并发收益。 SQLite 二进制文件格式将支持更高效的写入（主要是因为您不能追加到格式良好的 XML 文件的末尾）。 甚至读取数据，我认为其中大部分是相当随机的访问，使用 SQLite 会更快。

最重要的是，您可以获得 SQL 的好处，例如事务和索引。

编辑：忘了提。 SQLite 的一个好处（与许多数据库相反）是它允许在任何列中的任何行中使用任何类型。 基本上，使用 SQLite，您可以在数据类型方面获得与使用 XML 相同的自由。 这也意味着您不必担心对文本列进行限制。

Answer 15

您应该注意，许多大型关系数据库（Oracle 和 SQLServer）都有 XML 数据类型来在数据库中存储数据，并在 SQL 语句中使用 XPath 来访问该数据。

此外，还有一些原生 XML 数据库，它们的工作方式与 SQLite 非常相似，因为它们是一个二进制文件，其中包含一组文档（可能大致是一个表），然后您可以在单个文档或整个集合上使用 XPath/XQuery。 因此，使用 XML 数据库，您可以将日期数据作为单独的 XML 文档存储在集合中……因此，在处理今天的数据时，您只需要使用该文档即可。 但是编写一个 XQuery 来找出那个人的文档集合的历史数据。 光滑。

我使用过 Berkeley XMLDB（现在由 Oracle 提供支持）。 如果您在 google 上搜索“Native XML Database”，还有其他的。 我没有看到以这种方式存储/检索数据的性能问题。

XQuery 是一种不同的野兽（但非常值得学习），但是您可以只使用当前使用的 XPath，只需稍加修改即可。

Answer 16

数据库非常适合作为程序的一部分。 如果查询数据是您业务逻辑的一部分。 XML 是最好的文件格式，特别是如果您的数据格式是：

1、层次分明
2、未来可能以你无法猜测的方式发生变化
3、数据的寿命比程序长

Answer 17

我说这不是数据大小的问题，而是数据类型的问题。 如果您的数据是结构化的，请使用关系数据库。 如果您的数据是半结构化的，请使用 XML 或 - 如果数据量确实增长得太大 - 使用 XML 数据库。

Answer 18

如果您的搜索与分贝一起使用。 您可以将 xml 文件拆分为目录以方便查找，但管理开销很容易变得相当沉重。 您还可以获得更多的不仅仅是使用 sql 数据库的性能......