我真的很喜欢Xml来保存数据,但什么时候sqlite/database成为更好的选择？例如,当xml有多于x项或大于y MB时？
我正在编写一个rss阅读器,我相信我在sqlite数据库上使用xml来存储所有 feed项的缓存时做出了错误的选择.有哪些一个月后有〜1MB一个XML文件,一些饲料,另外有超过700个项目,而大部分只是后具有约30项,并在〜50KB大小数个月.
我目前没有计划实施上限,因为我希望能够搜索所有内容.
所以,我的问题是:
什么是sqlite /数据库的开销是否适合使用xml？
当有很多小的文件时,少数大型xml文件是否足以为数据库辩护,尽管即使是小的文件也会随着时间的推移而增长？(很长一段时间)
更新(更多信息)
每次在GUI中选择一个订阅源时,我都会重新加载该订阅源xml文件中的所有项目.
我还需要修改读取/未读状态,当我循环遍历xml中的所有节点以查找项目然后将其设置为已读/未读时,这似乎非常黑客.
男人我有这方面的经验.我在一个项目上工作,我们最初使用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查询重写为复杂的多查询算法.
所以这里是我们学到的内容的总结.
对于树数据,使用XPATH查询和修改XML要容易得多.
对于小型数据集(小于10M),XML在性能上吹走了sqlite.
对于大型数据集(大于10M-100M),XML加载时间和内存使用成为一个大问题,以至于某些计算机变得无法使用.
我们无法获得任何opensource xml数据库来修复与大型数据集相关的问题.
SQLITE没有XML dom的内存问题,但它在处理数据时通常较慢(它位于硬盘驱动器上,而不是内存中).(注意 - sqlite表可以存储在内存中,也许这会使它快速....我们没有尝试这个,因为我们想要从内存中获取数据.)
在表中存储和查询树数据并不令人愉快.但是,管理事务和索引部分弥补了这一点.
我基本上同意Mitchel,这可能是非常具体的,这取决于你将如何处理XML/sqlite.对于你的情况(缓存),在我看来,使用sqlite(或其他嵌入式dbs)更有意义.
首先,我并不认为sqlite需要比XML更多的开销.我的意思是开发时间开销和运行时开销.唯一的问题是你对sqlite库有所依赖.但是既然你需要一些XML库,那也没关系(我假设项目是在C/C++中).
sqlite优于xml的优点:
一切都在一个文件中,
随着缓存变大,性能损失低于XML,
您可以将Feed元数据与缓存本身(其他表)分开,但可以相同的方式访问,
对于大多数人来说,SQL可能比XPath更容易使用.
sqlite的缺点:
多个进程访问相同的数据库可能会有问题(可能不是你的情况),
你应该至少知道基本的SQL.除非缓存中有数十万个项目,否则我认为你不需要对它进行多次优化,
也许在某种程度上,从安全角度来看它可能更危险(SQL注入).另一方面,您不是在编写Web应用程序,因此不应该这样.
对于这两种解决方案而言,其他事情可能相同
总结一下,分别回答你的问题:
您不会知道,除非您使用两个后端测试您的特定应用程序.否则它总是只是猜测.对两个缓存的基本支持不应该是代码的问题.然后基准和比较.
由于XML文件的组织方式,sqlite搜索应该总是更快(除非一些极端情况无关紧要,因为它的速度非常快).加快XML中的搜索将需要索引数据库,在你的情况下,这将意味着缓存缓存,而不是一个特别好的主意.但是使用sqlite,您可以将索引作为数据库的一部分.
不要忘记你手边有一个很棒的数据库:文件系统!
很多程序员忘记了一个像样的目录文件结构:
这很快就像地狱一样
它是便携式的
它的运行时间很小
人们正在谈论将XML文件拆分成多个XML文件......我会考虑将XML拆分为多个目录和多个纯文本文件.
搏一搏.它令人耳目一新.
将XML用于应用程序应该知道的数据 - 配置,日志记录以及不应该使用的数据.
将数据库(oracle,SQL server等)用于用户直接或间接交互的数据 - 真实数据
如果用户数据更多是序列化集合,则使用SQLite - 如巨大的文件列表及其内容或电子邮件项目集合等.SQLite擅长于此.
取决于数据的种类和大小.
我不会使用XML来存储RSS项目.提要阅读器在接收数据时会不断更新.
使用XML,您需要首先从文件加载数据,解析它,然后存储它以便于搜索/检索/更新.听起来像数据库......
此外,如果您的应用程序崩溃会发生什么？如果使用XML,XML文件中的数据与内存中的数据的状态.至少在SQLite中你获得了原子性,所以你可以放心,你的应用程序将以与上一次数据库写入时相同的状态开始.
当您需要将数据从应用程序移动到其他位置或在应用程序之间共享信息时,XML最适合用作交换格式.对于几乎任何大小的应用程序,数据库应该是首选的存储方法.
京公网安备 11010802040832号 | 京ICP备19059560号-6 