开源是否曾经创建过自动处理事务的单文件数据库？
开源是否曾经创建过一个单文件数据库，在处理未在正式 SQL 事务集中传递的大型 SQL 查询集时具有更好的性能？我使用的 .NET 服务器对来自另一台服务器的数千行数据进行大量复制，并且以一对一的方式进行复制，无需正式的 SQL 事务。因此，我不能使用 SQLite 或 FirebirdDB 或 JavaDB，因为它们都不会自动批处理事务，因此性能很差。每个插入都会等待前一个插入成功，等等。因此，我被迫使用较重的数据库，如 SQLServer、MySQL、Postgres 或 Oracle。
有谁知道平面文件数据库（具有 JDBC 连接驱动程序）可以支持自动批处理事务并解决我的问题？
我不喜欢较重的数据库的主要原因是缺乏通过一键单击操作查看数据库内部的能力，就像使用 SQLLite 一样。
我尝试创建一个 SQLite 数据库并 然后设置 PRAGMA read_uncommissed=TRUE; 并且它没有导致任何结果 性能改进。
Has open source ever created a single file database that has better performance when handling large sets of sql queries that aren't delivered in formal SQL transaction sets? I work with a .NET server that does some heavy replication of thousands of rows of data from another server and it does so it a 1-by-1 fashion without formal SQL transactions. So, therefore I cannot use SQLite or FirebirdDB or JavaDB because they all don't automatically batch the transactions and therefore the performance is dismal. Each insert waits for the success of the previous one, etc. So, I am forced to use a heavier database like SQLServer, MySQL, Postgres, or Oracle.
Does anyone know of a flat file database (that has a JDBC connect driver) that would support auto batching transactions and solve my problem?
The main think I dont like about the heavier databases is the lack of the ability to see inside the database with a one-mouse-click operation, like you can with SQLLite.
I tried creating a SQLite database and
then set PRAGMA read_uncommitted=TRUE;
and it didn't result in any
performance improvement.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为 Firebird 可以解决这个问题。
Firebird 有很好的 dotnet 提供程序和许多复制 解决方案，
也许您可以阅读此Firebird 交易文章
I think that Firebird can work for this.
Firebird have good dotnet provider and many solution for replication
May be you can read this article for Firebird transaction
尝试超音速数据库 - http://hsqldb.org/doc/guide/ch02.html# N104FC
Try hypersonic DB - http://hsqldb.org/doc/guide/ch02.html#N104FC
如果您希望事务持久（即在电源故障时幸存），那么数据库必须在每次事务后写入磁盘（这通常是某种日志）。
如果您的事务非常小，这将导致大量写入，甚至在电池支持的 raid 控制器或 SSD 上性能也很差，但在消费级硬件上性能更差。
避免这种情况的唯一方法是以某种方式禁用 txn 提交时的刷新（这当然会破坏持久性）。我不知道哪些人支持这一点，但应该很容易找到。
If you want your transactions to be durable (i.e. survive a power failure) then the database will HAVE to write to the disc after each transaction (this is usually a log of some sort).
If your transactions are very small this will result in a huge number of writes, and very poor performance even on your battery backed raid controller or SSD, but worse performance on consumer-grade hardware.
The only way of avoiding this is to somehow disable the flush at txn commit (which of course breaks durability). I have no idea which ones support this, but it should be easy to find out.