Могут ли целочисленные ключи / значения храниться в LevelDB?

Question

Я искал хранилища значений ключей, которые поддерживают целочисленные ключи и целочисленные значения.LevelDB кажется хорошим вариантом, хотя я не могу найти никакой информации о том, поддерживаются ли целочисленные значения / ключи

Answer 1

Вы можете хранить практически все что угодно в LevelDB. Вы предоставляете непрозрачные фрагменты данных в LevelDB через структуру Slice. Вот пример:

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.

Answer 2

LMDB имеет явную поддержку целочисленных ключей (и значений, если вы используете отсортированные дубликаты). http://symas.com/mdb

Когда БД сконфигурирован для целочисленных ключей, функции сравнения ключей также намного быстрее, поскольку они могут сравнивать слово за раз, а не просто за байтом, как это делает сравнение, ориентированное на строки по умолчанию.

Отказ от ответственности: я являюсь автором LMDB. Конечно, это не делает факты другими.

Answer 3

Во многих случаях более сложная схема кодирования для целочисленных ключей является лучшим выбором.Упаковка int в его представление с двумя дополнениями в char * (как предложено в другом ответе на этот вопрос) является одним из вариантов;другое кодирование varint (экономит место для маленьких целых чисел, может хранить произвольные числа без верхней границы).

Answer 4

Чтобы уточнить ответ Линка, отчасти потому, что я только что играл с этой точной вещью, как часть книги, которую я пишу, вы можете увидеть результаты BytewiseComparator, о которых он / она говорит ниже.

Другой подход состоит в том, чтобы перевернуть ваши двоичные целые числа в формат с прямым порядком байтов, чтобы они сортировались нормально с компаратором по умолчанию. Это облегчает составление ключей. long flippedI = htonl(i);

Обратите внимание, что LevelDB очень быстрый. Я провел тесты на iPhone4 с 50000 записей с текстовыми ключами и вторичными ключами, так что около 100000 пар ключ / значение, и он кричал вместе.

Очень легко написать собственный компаратор, который будет использоваться вашей базой данных всегда и по-прежнему использует 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)