问题标签 [leveldb]

我们正在尝试在 redhat 机器上使用 leveldbjni。它在 ubuntu 上完美运行。但是在redhat上它给出了以下错误：

org.fusesource.leveldbjni.internal.NativeDB$DBException：IO 错误：<文件位置>/LOCK：没有这样的文件或目录

我们尝试在 redhat 上创建 leveldb C++ 库（使用https://github.com/fusesource/leveldbjni上的说明），但仍然遇到同样的问题。

目前我们正在使用 KahaDB 存储在 ActiveMQ 中进行消息持久性，到目前为止效果很好。
根据 ActiveMQ5.6 的发行说明，LevelDB提供增强的性能。
有没有人试过usign LevelDB，如果是的话，你能提供利弊吗？

我正在开发一个分布式键值系统（或数据存储），它在后端使用levelDB作为其嵌入式数据库库。

我希望一台节点/机器托管多个表（出于复制和负载平衡的目的）。我知道 levelDB 没有表的概念，所以我不能以表的形式对我的数据进行逻辑分区（因此不能将这些表用作我的基本分布单位）。

我的问题是：是否有规定在 levelDB 的单个实例中拥有多个“逻辑表”？

据我所知，我可以在我的节点上运行多个 levelDB 实例，每个实例处理一个表。但我不想这样做，因为在这种情况下，当同时访问这些多个数据库实例时，会出现严重的争用（我相信在磁盘上）。虽然在单个 DB 实例中拥有多个逻辑表可以为我提供 levelDB 优化的优势，以最大限度地减少磁盘访问。

LevelDB-Go是 Go 语言中 LevelDB 的移植。LevelDB-Go 通常被称为 Go 应用程序的原生替代方案。网站没有示例，也没有文档。

我应该通过阅读源代码来学习它吗？或者有另一个网站有示例和文档？

库是否支持并发？

我正在使用 leveldb 进行压力测试。

在util/env_poisx.cc : NewRandomAccessFile()

在插入 300 万个数据（每个 100k）之后。errno 说Cannot allocate memory。

为什么？

更多细节：

最佳：

免费-m：

ulimit -a：

系统控制：

目前，我们正在评估几个键+值数据存储，以替换 owr 主应用程序当前正在使用的较旧的 isam（20 多年！）...

问题是我们当前的 isam 不支持崩溃恢复。

所以 LevelDB 对我们来说似乎没问题（也检查 BerkleyDB 等）

但是我们遇到了热备份的问题，而且，鉴于 LevelDB 是一个库，而不是服务器，要求“热备份”很奇怪，因为它直观地暗示了一个外部备份过程。

也许有人想提出选择（或已知的解决方案）？

例如： - 通过主应用程序的内线程进行热备份？- 仅通过复制 LevelDB 数据目录进行热备份？

提前致谢

我喜欢 LevelDB 作为我的应用程序数据库的外观，但有一个问题。

我想将数据存储到数据库中，但是当我读取数据时，有时我只需要数据的特定部分。以及leveldb_get(db, readOptions, key, keySize, &size, &err)我想要类似leveldb_get_subsection(db, readOptions, key, keySize, offset, size, &err)但不存在的东西。

当然，我可以将数据索引到更小的部分，但我想知道是否有一个很好的替代 LevelDB 的方法，它允许我读取更有意义的记录/值的子部分。有什么建议吗？

我需要安全同步到磁盘的原子操作，因为数据完整性很重要。我还需要一个C接口。

谢谢。

我有一组 100+ 百万个字符串，每个最多 63 个字符。我有很多磁盘空间和很少的内存（512 MB）。我需要单独查询存在，并且不存储其他元数据。

我事实上的解决方案是 BDB btree。有没有更好的选择？我知道 leveldb 和京都内阁，但不够熟悉以确定优势。

好像没有这个界面。。

我是否必须迭代所有键才能获得计数？

这样做的设计目的是什么？或者实现此功能的限制是什么？

由于以下内容有点长：这是 tl;dr; 版本：是否存在用于快速键和值查找的键/值最佳实践，例如具有持久索引的基于哈希的集合？

我对键值数据库的世界很感兴趣，但到目前为止还没有弄清楚如何有效地实现以下用例：

假设我们想要序列化一些数据并通过一个持久的、唯一的整数索引在其他地方引用它们。因此例如：Key = unsigned int，Value = MyData。

数据库应具有快速键查找并确保 MyData 是唯一的。

现在，当我在我的数据库中插入一个新值时，我可以为其分配一个新的索引键，例如数据库的当前大小或防止删除项目后发生冲突，我可以在外部保留一些计数器。

但是我如何确保我不会将相同的 MyData 值插入到我的数据库中？到目前为止，在我看来，键值数据库似乎无法有效地实现这一点 - 这是正确的吗？即我不想迭代整个数据库只是为了确保 MyData 值不在那里......

那么，实现这一点的最佳做法是什么？

背景：我在 KDevelop 上工作，我们使用上面的代码分析缓存。我们实际上有上述用例1的自定义实现。如果您对内部结构感兴趣，请搜索 Bucket 和 ItemRepository，有关 ItemRepository 的示例性用法，请参见2。

但是您可能会同意，这段代码很难理解，因此也很难维护。我想将其性能与可能导致代码更简单的替代解决方案进行比较——但前提是它不会导致严重的性能损失。考虑到围绕 OpenLDAP MDB、Kyoto Cabinet 和 LevelDB 等键值存储性能的炒作，这就是我想开始的地方。

我们在 KDevelop 中所拥有的——据我所知——基本上是一种混合的磁盘/内存哈希映射，它会定期保存到磁盘（这当然会在崩溃等情况下导致重大数据损坏）。 ）。项目根据它们的散列值存储在一个位置，只要散列函数速度快，这当然也允许相对快速的值查找。增加的转折是您还可以获得某种持久性数据库索引，可用于非常有效地查找项目。

所以——长话短说——如何用一个键/值数据库来做到这一点，比如 LevelDB、Kyoto Cabinet、OpenLDAP MDB——你说的吗？