在谈论数据库系统时，事务层由什么构成？
例如，LevelDB 不支持多语句事务。我在某处读到您必须处理“事务层”中的那些内容。
为了向不支持事务的较低级别库添加事务支持，该层必须做什么？
For example, LevelDB doesn't support multi-statement transactions. I read somewhere that you would have to deal with those in a "transactional layer".
What would this layer have to do to add transaction support to a lower-level library that doesn't support transactions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
定义事务的方法有多种，并且实现它们的方法也有多种。事务的一个共同属性是它的 ACID：
一个事务可能有几种状态：
LevelDB 不支持事务，但它确实具有一些ACID 属性：
那么...回到你的问题：
问：
答：
这取决于您如何定义事务。如果您使用上述属性定义事务，并且希望事务具有 ACID，那么您必须弄清楚 LevelDB 是否可以实现这一点（集成了大多数 ACID 属性），然后您必须围绕 LevelDB 编写一个包装器，以确保正确维护事务的状态。但是，我并不完全确定单独的包装器可以做到这一点，因此您可能必须实际获取源代码并将其修改为真正支持事务。
There are various ways to define transactions and there are various ways to implement them. A common property of a transaction is that it's ACID:
A transaction may have several states:
LevelDB does not support transactions, however it does have some of the ACID properties:
So... back to your question:
Q:
A:
It depends on how you define a transaction. If you define a transaction with the above-mentioned properties and if you want your transactions to be ACID, then you'd have to figure out if that's possible with LevelDB (most of the ACID properties are integrated) and then you'd have to write a wrapper around LevelDB which ensures that the states of the transactions are maintained properly. However, I'm not entirely sure that a wrapper alone would do it, so you may have to actually take the source code and modify it to truly support transactions.
鉴于您的数据库是单线程的，您可以执行以下操作：
使用 leveldb 批处理功能：创建一个新密钥，而不是覆盖旧密钥。还记录密钥的旧值和新值。
如果此时数据库崩溃，请查找日志记录并通过将事务一部分的键重新声明为其旧值来回滚事务。删除日志以完成回滚。
如果事务已提交，则删除旧密钥并删除日志条目以完成提交。
然后，您有一个使用多个版本的单线程键/值存储事务。
如果数据库是多线程的，则必须使用 MVCC（参见 Yahoo 的 Omid、PostgreSQL、Wiredtiger、bsddb...）以及诸如精确可序列化快照隔离（PSSI）之类的东西。
Given your database is single threaded you can do the following:
Using leveldb batch feature: Instead of overriding old key, create a new one. Also log key's old and new value.
If the database crash at this point, lookup the log records and rollback the transaction by restate keys that were part of the transaction to their old value. Delete the log to complete the rollback.
If the transaction is committed, delete old keys and delete log entries to complete commit.
Then you have a transaction for single threaded key/value store using multiple versions.
If the database is multithread you have to use MVCC (see Yahoo's Omid, PostgreSQL, Wiredtiger, bsddb...) and something like Precisely Serializable Snapshot Isolation (PSSI).