Các khóa/giá trị nguyên có thể được lưu trữ trong LevelDB không?

Question

Tôi đã tìm kiếm các cửa hàng giá trị khóa hỗ trợ các phím số nguyên và giá trị số nguyên. LevelDB có vẻ là một lựa chọn tốt, mặc dù tôi không thể tìm thấy bất kỳ thông tin nào về việc các giá trị/khóa số nguyên có được hỗ trợ hay không

Answer 1

Bạn có thể lưu trữ khá nhiều thứ trong LevelDB. Bạn cung cấp các mảng dữ liệu mờ đục vào LevelDB thông qua cấu trúc Slice. Dưới đây là ví dụ:

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); 

Và đó là khá nhiều!

Tuy nhiên, có một điều cần lưu ý là trong khi nó nói chung là tốt để lưu trữ các số nguyên trong LevelDB (như cả khóa và giá trị), họ sẽ có trật tự thông qua BytewiseComparator để khóa của bạn có hỗ trợ bytewise so sánh. Điều này cũng có nghĩa là nếu bạn dựa vào thứ tự cụ thể của các khóa, thì bạn phải chú ý đến sự kết thúc của hệ thống.

Bạn cũng có thể viết trình so sánh của riêng mình qua giao diện Comparator cho phép bạn thay thế mặc định BytewiseComparator.

Answer 2

Trong nhiều trường hợp, một lược đồ mã hóa phức tạp hơn cho các phím số nguyên là một lựa chọn tốt hơn. Đóng gói một int vào biểu diễn hai bổ sung của nó trong một char * (như được đề xuất trong câu trả lời khác cho câu hỏi này) là một lựa chọn; varint encoding là một số khác (tiết kiệm không gian cho các số nguyên nhỏ, có thể lưu trữ các số tùy ý mà không có giới hạn trên).

Answer 3

Để mở rộng câu trả lời của Link, một phần vì tôi đã chơi chính xác như một phần của cuốn sách tôi đang viết, bạn có thể thấy kết quả của BytewiseComparator mà anh ta/cô ấy nói về bên dưới.

Cách tiếp cận khác là lật các số nguyên nhị phân của bạn sang định dạng cuối lớn để chúng sắp xếp OK với bộ so sánh mặc định. Điều này giúp tạo các khóa dễ dàng hơn. long flippedI = htonl(i);

Lưu ý rằng LevelDB rất nhanh. Tôi đã thực hiện các thử nghiệm trên iPhone4 với 50.000 bản ghi có khóa văn bản với các khóa phụ, do đó, khoảng 100.000 cặp khóa/giá trị và nó hét lên.

Nó rất dễ dàng để viết một so sánh tùy chỉnh được sử dụng bởi cơ sở dữ liệu của bạn mãi mãi và vẫn sử dụng ByteWiseComparator cho các phím khác với số của bạn. Vấn đề lớn nhất là quyết định khóa nào được bao phủ bởi các quy tắc tùy chỉnh của bạn hay không.

Một cách tầm thường là nói rằng tất cả các khóa không phải số nguyên dài hơn 4 ký tự để bạn giả sử khóa 4 byte là số nguyên. Điều đó có nghĩa là bạn chỉ cần đảm bảo rằng bạn thêm dấu cách hoặc thứ gì khác để đẩy điều đó. Đó là tất cả rất tùy ý và tùy thuộc vào bạn nhưng hãy nhớ rằng chỉ có hai mẩu thông tin bạn có là nội dung chính và độ dài của nó. Không có siêu dữ liệu nào khác cho một khóa nhất định.

Một phần của kết quả từ một mẫu để so sánh tiêu chuẩn với int phím bắt đầu từ 1 và đi lên bằng 1-1000, sử dụng một cơ sở dữ liệu với BytewiseComparator chuẩn

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) 

Answer 4

LMDB đã hỗ trợ rõ ràng cho các phím số nguyên (và giá trị, nếu bạn đang sử dụng trùng lặp được sắp xếp). http://symas.com/mdb

Khi DB được cấu hình cho khóa nguyên, các hàm so sánh chính cũng nhanh hơn nhiều vì chúng có thể so sánh từ-at-a-time thay vì chỉ byte-tại-một-thời gian làm.

Tuyên bố từ chối trách nhiệm: Tôi là tác giả của LMDB. Tất nhiên, điều đó không làm cho sự thật khác biệt.