You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 22, 2022. It is now read-only.
Has anyone thought about trying other low-level storage backends to experiment with efficiency & performance? Perhaps something like VPack could be interesting to test.
I'm asking despite seeing libmdbx's internals being rather more tightly bound to the current format (which seems nearly identical to LMDB).
The text was updated successfully, but these errors were encountered:
MDBX treat user's keys and data as opacity byte strings, except the MDBX_INTEGERKEY and MDBX_INTEGERDUP features. So nothing prevents you from using any serialization format, including noted VelocyPack.
On the other hand, using custom format for keys requires "custom comparators" which entails certain restrictions. Therefore, it is planned to implement minimal support for MessagePack.
However, I do think it is NOT reasonable to do same for VPack, since it is used rarely in comparison with MsgPack.
Oh, pardon me for not being clear with my question.
I'm asking whether someone has tried to exchange the memory layout (and thus also the on-disk data layout) libmdbx uses internally for VPack or anything similar.
Has anyone thought about trying other low-level storage backends to experiment with efficiency & performance? Perhaps something like VPack could be interesting to test.
I'm asking despite seeing libmdbx's internals being rather more tightly bound to the current format (which seems nearly identical to LMDB).
The text was updated successfully, but these errors were encountered: