SQL Server CE 4.0性能比较
SQL Server CE 4 (SQL Server Compact Edition 4.0) 已经不是新闻了(如果是的话,您可以 阅读本文)
但是看到 SQL Server CE 4 与其他数据库的性能比较是非常有趣的。
尤其是:
- SQLite
- SQL Server (1)
- SQL Server Express *
- 可能是 Firebird
对于功能相当的应用程序,
(1)。不幸的是,谷歌目前提供的关于该主题的链接并不多。实际上我无法找到任何(对于正确的 SQL CE 版本)。
如果有人能够找到或分享此类信息,让我们为未来的人类收集它。
SQL Server CE 4 (SQL Server Compact Edition 4.0) is not news already (If it is, you could read this article)
But it is very interesting to see SQL Server CE 4 performance comparison to other databases.
Especially with:
- SQLite
- SQL Server (1)
- SQL Server Express *
- maybe Firebird
(1) for applications where functionality is comparable.
Unfortunately there are not so much links about the subject that google provides right now. Actually I was unable to find any (for proper SQL CE version).
If one could find or share such information lets collect it here for future humanity.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
在我看来,将嵌入式数据库(如 SQL CE)与服务器端关系数据库(如所有其他数据库一样,除了 SQLite 和 Firebird 的嵌入式版本)进行比较是不正确的。
它们之间的主要区别在于通用服务器端关系数据库(如MS SQL、MySQL、Firebird Classic和SuperServer等)作为独立服务安装并在外部运行主要应用程序的范围。这就是为什么它们可以表现得更好,因为它们对多核和多 CPU 架构的内在支持,使用预缓存、VSS 等操作系统功能来提高密集数据库操作时的吞吐量,并且可以占用尽可能多的内存您的操作系统可以提供单一服务/应用程序。这也意味着它们的性能指标或多或少独立于您的应用程序,但很大程度上取决于您的硬件。在这方面,我想说任何数据库的服务器版本总是比嵌入式版本具有更高的性能。
SQL CE(以及 Firebird Embedded、SQLite、TurboSQL 等)是嵌入式数据库引擎,这意味着完整的数据库被打包到单个(或最多 2 个)DLL 文件中,这些文件与您的申请。由于明显的大小限制(您是否需要将 30 MB 的 DLL 与 2-3 MB 长的应用程序一起分发?),它们还直接在您的应用程序上下文中运行,并且总<数据访问操作的内存和性能与应用程序的其他部分共享 - 这涉及可用内存、CPU 时间、磁盘吞吐量等。具有与数据访问线程并行运行的计算密集型线程可能会导致数据库性能急剧下降。
由于应用领域不同,这些数据库具有不同的选项:server-db 提供广泛的用户和权限管理、对视图和存储过程的支持,而嵌入式数据库通常缺乏对用户和权限管理的任何支持,并且对视图的支持有限和存储过程(后者失去了在服务器端运行的大部分好处)。数据吞吐量是 RDBMS 的常见瓶颈,服务器版本通常安装在条带 RAID 卷上,而嵌入式 DB 通常是面向内存的(尝试将所有实际数据保留在内存中)并最大限度地减少数据存储访问操作。
因此,比较 .Net 的不同嵌入式 RDBMS 的性能可能是有意义的,例如 MS SQL CE 4.0、SQLite、Firebird Embedded、TurboSQL。
我不希望在通常的非高峰操作期间出现巨大的差异,而某些数据库由于与操作系统更好的集成,可能会为大型 BLOB 提供更好的支持。-- 更新 --
我必须收回我的最后一次换句话说,我的快速实施显示了非常有趣的结果。
我编写了一个简短的控制台应用程序来测试这两个数据提供程序,如果您想自己尝试它们,这里是您的源代码。
必要的免责声明:
以下是两个不同示例的结果:
...以及一个更大的示例:
因此,如您所见,与 SQLCE 相比,SQLite 中的任何写入操作(创建、更新、删除)所需的时间几乎多出 1000 倍。它不一定反映该数据库的总体性能不佳,可能是由于以下原因造成的:
In my opinion, it is incorrect to compare the embedded database (like SQL CE) versus server-side relational database (like all the rest, except for SQLite and the Embedded version of Firebird).
The main difference between them is that the general-purpose server-side relational databases (like MS SQL, MySQL, Firebird Classic and SuperServer etc.) are installed as an independent service and run outside of the scope of your main application. That is why they can perform much better because of the intrinsic support for multi-core and multi-CPU architectures, using OS features like pre-caching, VSS etc to increase the throughput in case of intensive database operation and can claim as much memory as your OS can provide for a single service/application. It also means that the performance indicators for them are more or less independent from your application, but largely depend upon your hardware. In this respect I would say that the server versions of any database are always more performance compared to the embedded ones.
SQL CE (along with Firebird Embedded, SQLite, TurboSQL and some other) are embedded DB engines, meaning that the complete database is packed into a single (or maximally 2) DLL-files that are distributed together with your application. Due to the evident size limitations (would you like to have to distribute a 30 MB DLL together with your 2-3 MB long application?) they also run directly in the context of your application and the total memory and performance for data access operations are shared with other parts of your application -- that regards both available memory, CPU time, disk throughput etc. Having a computation-intensive threads running in parallel with your data access thread might lead to dramatic decrease of your database performance.
Due to the different areas of application these databases have different palette of options: server-db provide extensive user and right management, support for views and stored procedures, whereas embedded database normally lack any support for users and rights management and have limited support for views and stored procedures (latter ones lose the majority of their benefits of running on server side). Data throughput is a usual bottlenecks of RDBMS, server versions are usually installed on striped RAID volumes, whereas embedded DB are often memory-oriented (try to keep all the actual data in the memory) and minimize the data storage access operations.
So, what would make sense probably is to compare different embedded RDBMS for .Net for their performance, like MS SQL CE 4.0, SQLite, Firebird Embedded, TurboSQL.
I wouldn't expect drastic differences during usual non-peak operation, whereas some database may provide better support for large BLOBs due to better integration with OS.-- update --
I have to take back my last words, for my quick implementation shows very interesting results.
I wrote a short console application to test both data providers, here is the source code for you if you want to experiment with them on your own.
Necessary disclaimer:
Here are the results for two different samples:
... and a bigger sample:
So, as you can see, any writing operations (create, update, delete) require almost 1000x more time in SQLite compared to SQLCE. It does not necessarily reflect the general bad performance of this database and might be due to the following:
这是我在 CodeProject 网页上新鲜出炉的关于基准测试的文章:
基准测试 .Net 嵌入式数据库的性能:SQL CE 4.0 vs SQLite
(该文章现在处于待处理状态,您需要登录 CodeProject 才能访问其内容)
PS:我错误地将我之前的答案标记为社区 wiki 条目,并且不会得到任何内容为它赢得声誉。这鼓励我为代码项目撰写关于此主题的文章,其中包含一些优化的代码、有关嵌入式数据库和统计分析的更多附加信息结果。因此,如果您喜欢这篇文章和我的第二个答案,请投票支持该答案。
Here is my freshly baked article about the benchmarking on CodeProject webpage:
Benchmarking the performance of embedded DB for .Net: SQL CE 4.0 vs SQLite
(the article has a pending status now, you need to be logged-in on CodeProject to access its content)
P.S.: I mistakenly marked my previous answer as a community wiki entry and won't get any reputation for it. This encouraged me to write the article for Code Project on this topic, with a somewhat optimized code, more additional information about embedded dbs and statistical analysis of the results. So, please, vote this answer up if you like the article and my second answer here.
因为我对 Alaudo 的测试、测试结果以及最终的结论感到非常困难,所以我继续尝试了一下他的程序,并提出了一个修改版本。
它测试以下 10 次中的每一个并输出平均时间:
这里是程序(实际上是一个类):
这是我得到的数字:
使用 sqlite 进行 200 次插入或更新大约 3 秒可能看起来仍然有点高,但至少比 23 秒更合理。相反,人们可能会担心 SqlCe 完成相同的 200 次插入或更新所需的时间太少,特别是因为在单个事务中使用每个 SQL 查询或在一个事务中一起使用每个 SQL 查询之间似乎没有真正的速度差异。我对 SqlCe 不太了解,无法解释这一点,但这让我担心。这是否意味着当 .Commit() 返回时,您不确定更改是否实际写入磁盘?
Because I'm having a real hard time with Alaudo's tests, test results, and ultimately with his conclusion, I went ahead and played around a bit with his program and came up with a modified version.
It tests each of the following 10 times and outputs the average times:
Here is the program (it's a class actually):
Here are the numbers I get:
~3 seconds for 200 inserts or updates using sqlite might still seem a little high, but at least it's more reasonable than 23 seconds. Conversely, one might be worried how SqlCe takes too little time to complete the same 200 inserts or update, especially since there seems to be no real speed difference between having each SQL query in individual transactions, or together in one transaction. I don't know enough about SqlCe to explain this, but it worries me. Would it mean that when .Commit() returns, you are not assured that the changes are actually written to disk?
我最近参与了一个使用 SQL CE 4 和 NHibernate 的项目,我发现性能非常好。使用 SQL CE 4,我们能够在一秒钟内插入 8000 条记录。使用网络上的 Oracle,即使使用批量大小和 seqhilo 方法,我们每秒也只能插入 100 条记录。
我没有测试它,但查看了 .NET 的 NoSQL 产品的一些性能报告,SQL CE 4 似乎是独立应用程序的最佳解决方案之一。
只要避免使用 Identity 列,我们注意到如果不使用它们,性能会提高 40 倍。当使用 Identity 列作为 PK 时,插入相同的 8000 条记录需要 40 秒。
I have recently worked on a project using SQL CE 4 and NHibernate and I found the performance to be really good. With SQL CE 4 we were able to insert 8000 records in a second. With Oracle over the network we were only able to insert 100 records per second even batch-size and seqhilo approaches were used.
I did not test it but looking at some of the performance reports for NoSQL products for .NET, SQL CE 4 seems to be one of the best solutions for stand-alone applications.
Just avoid using Identity columns, we noticed the performance was 40 times better if they are not used. The same 8000 records were taking 40 secs to insert when an Identity column was used as PK.