有谁知道LevelDB的测试结果如何？它在生产中的使用状态如何？这是一个相对较新的库，当我检查源代码时，它似乎没有太好地处理错误。有人在生产中使用LevelDB并可以评论我的问题吗？
在生产环境中使用的一个地方是比特币项目。在比特币中，它的使用对平台的安全性至关重要。请参阅Bitcoin QT 0.8.0的发行说明
LevelDB有很多高可见性问题https://github.com/bitcoin/bitcoin/issues/2770，代码编写得很糟糕，需要一笔赏金才能找到修复https://bitcointalk.org/index.php?topic=337294.0;all而leveldb讨论组主要是关于非常基本的数据库功能的bug报告，这些功能无法像宣传的那样工作。 https://groups.google.com/forum/#!forum/leveldb（例如，“快照”实际上不是快照，并且可能被随后的写入https://groups.google.com/forum/#!topic/leveldb/IAKJaL2zqZM等污染...）
在提出这个问题之日，LevelDB当然不是生产准备好的，任何一个这样认为是妄想的人。正如独立开发者https://twitter.com/rescrv/status/406106256890286080所证实的那样，代码质量非常糟糕
我们在我们的网站中使用LevelDB，但包含在LevelDB网络服务器SSDB（https://github.com/ideawu/ssdb）中，支持hash / zset数据类型。我们的SSDB实例每天提供1亿个查询。
你如何在2011年取得“相对较新”的资格？
您能否详细说明“不能很好地处理错误”？
LevelDB用作Riak和Hyperdex的后端，它们都定制它以提高巨大负载下的吞吐量。有 一个伟大的video from Ricon East 2013解释了Basho所做的Riak变化。 （在2019-03之前的某个时间点取消）。
请注意，RocksDB是Facebook的另一个主要分支，推荐用于服务器端。它从LevelDB分岔的历史就在WikiPedia上。您可以阅读RocksDB如何处理this page上的错误：
目前在RocksDB中，写操作期间的任何错误（写入WAL，Memtable Flush，后台压缩等）都会导致数据库实例默认进入只读模式，并且不接受进一步的用户写入....
调用DB :: Resume（）手动恢复数据库并将其置于读写模式。此函数将清除错误，清除任何过时的文件，并重新启动后台刷新和压缩操作。目前，它仅支持从压缩期间发生的后台错误中恢复。将来，我们会增加更多案例。