当前位置：文江博客话题详情

LevelDB 中可以存储整数键/值吗？

发布于 2024-12-25 20:02:34 字数 68 浏览 2 评论 0原文

我搜索了支持整数键和整数值的键值存储。 LevelDB 似乎是一个不错的选择，尽管我找不到任何有关是否支持整数值/键的信息

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

蓦然回首 2025-01-01 20:02:34

您可以在 LevelDB 中存储几乎任何内容。您通过 切片结构。这是一个例子：

int intKey = 256;
int intValue = 256*256;

Slice key((char*)&intKey, sizeof(int));
Slice value((char*)&intValue, sizeof(int));

db->Put(leveldb::WriteOptions(), key, value);

差不多就是这样了！

但是，需要注意的一件事是，虽然通常可以在 LevelDB 中存储整数（作为键和值），但它们将通过 BytewiseComparator 进行排序，因此您的键具有支持字节比较。这也意味着，如果您依赖于键的特定顺序，那么您必须注意系统上的字节序。

您还可以通过 Comparator接口，它允许您替换默认的 BytewiseComparator。

You can store pretty much anything in LevelDB. You provide opaque slices of data into LevelDB via the Slice structure. Here is an example:

int intKey = 256;
int intValue = 256*256;

Slice key((char*)&intKey, sizeof(int));
Slice value((char*)&intValue, sizeof(int));

db->Put(leveldb::WriteOptions(), key, value);

And that's pretty much it!

However, one thing to note is that while it's generally fine to store integers in LevelDB (as both keys and values), they will be order via the BytewiseComparator so your key has to support bytewise comparison. This also means that if you rely on specific ordering of the keys, then you have to be mindful of the endian-ness on the system.

You can also write your own comparator via the Comparator interface which will allow you to replace the default BytewiseComparator.

回复收藏 0 原文

箹锭⒈辈孓 2025-01-01 20:02:34

在许多情况下，更复杂的整数键编码方案是更好的选择。将 int 打包到 char* 中的两个补码表示中（如该问题的另一个答案中所建议的）是一种选择； varint 编码是另一种编码（为小整数节省空间，可以存储没有上限的任意数字）。

回复收藏 0 原文

寄人书 2025-01-01 20:02:34

为了放大 Link 的答案，部分原因是我刚刚在我正在写的书中研究了这个确切的事情，您可以看到他/她在下面讨论的 BytewiseComparator 结果。

另一种方法是将二进制整数翻转为大端格式，以便它们可以使用默认比较器进行排序。这使得组合键变得更加容易。
long FlippedI = htonl(i);

请注意，LevelDB 非常快。我在 iPhone4 上进行了测试，其中包含 50,000 个带有辅助键的文本键控记录，大约有 100,000 个键/值对，而且效果很好。

编写一个自定义比较器非常容易，该比较器将永远由您的数据库使用，并且仍然对除数字之外的键使用 ByteWiseComparator。最大的问题是决定自定义规则是否涵盖哪些键。

一种简单的方法是，所有非整数密钥的长度都超过 4 个字符，因此您假设 4 字节密钥是一个整数。这意味着您只需要确保添加尾随空格或其他内容来推动它。这一切都是非常随意的，取决于你，但请记住你仅有的两条信息是关键内容及其长度。给定密钥没有其他元数据。

标准比较器示例的部分结果，其 int 键从 1 开始，递增 1 到 1000，使用具有标准 BytewiseComparator 的数据库

Listing the keys in decimal and hex
 256 ( 100)
 512 ( 200)
 768 ( 300)
   1 (   1)
 257 ( 101)
 513 ( 201)
 769 ( 301)
   2 (   2)
 258 ( 102)
 514 ( 202)
 770 ( 302)
   3 (   3)
 259 ( 103)
 515 ( 203)
 771 ( 303)
...
 254 (  fe)
 510 ( 1fe)
 766 ( 2fe)
 255 (  ff)
 511 ( 1ff)
 767 ( 2ff)

To enlarge on Link's answer, partly because I've just been playing with this exact thing as part of the book I'm writing, you can see the BytewiseComparator results he/she talks about below.

Another approach is to flip your binary integers to big endian format so they will sort OK with the default comparator. This makes it easier to compose keys.
long flippedI = htonl(i);

Note that LevelDB is very fast. I've done tests on an iPhone4 with 50,000 text-keyed records with secondary keys, so about 100,000 key/value pairs and it screams along.

It is very easy to write a custom Comparator which is used by your database forevermore and still uses ByteWiseComparator for keys other than your numbers. The biggest issue is deciding which keys are covered by your custom rules or not.

A trivial way would be to say that all non-integer keys are more than 4 characters long so you assume a 4 byte key is an integer. That means you just need to ensure you add trailing spaces or something else to push that. It's all very arbitrary and up to you but remember the only two pieces of information you have are the key content and its length. There's no other metadata for a given key.

Part of the results from a sample for standard comparator with int keys starting at 1 and going up by 1 to 1000, using a database with standard BytewiseComparator

Listing the keys in decimal and hex
 256 ( 100)
 512 ( 200)
 768 ( 300)
   1 (   1)
 257 ( 101)
 513 ( 201)
 769 ( 301)
   2 (   2)
 258 ( 102)
 514 ( 202)
 770 ( 302)
   3 (   3)
 259 ( 103)
 515 ( 203)
 771 ( 303)
...
 254 (  fe)
 510 ( 1fe)
 766 ( 2fe)
 255 (  ff)
 511 ( 1ff)
 767 ( 2ff)

回复收藏 0 原文