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 Oct 7, 2023. It is now read-only.
Thinking about I cann‘t see any benefits from current "key per metadata parameter scheme" versus "single key (or couple of keys) for serialized metadata".
Current scheme doesn't improve query (ie with conditions) performance for single parameter since its value is not a part of a key. And it doesn't improve single param lookup significantly. (Serialization coukd be choosen to allowe single key lookup without unpacking whole value. Even json has Go libraries capabke to do it).
But current scheme eats significantly more space (since BBoltDB doesn't compress keys afaik), and requires to update and/or query keys in many parts of database which lay far from each other.
I suppose, using just one key (or two keys if there is clean distinction between "slim" and "fat" params) with appropriate serialization (msgpack or protobuf (msgpack is better, imho)) will greatly improve performance of zetcd.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Thinking about I cann‘t see any benefits from current "key per metadata parameter scheme" versus "single key (or couple of keys) for serialized metadata".
Current scheme doesn't improve query (ie with conditions) performance for single parameter since its value is not a part of a key. And it doesn't improve single param lookup significantly. (Serialization coukd be choosen to allowe single key lookup without unpacking whole value. Even json has Go libraries capabke to do it).
But current scheme eats significantly more space (since BBoltDB doesn't compress keys afaik), and requires to update and/or query keys in many parts of database which lay far from each other.
I suppose, using just one key (or two keys if there is clean distinction between "slim" and "fat" params) with appropriate serialization (msgpack or protobuf (msgpack is better, imho)) will greatly improve performance of zetcd.
The text was updated successfully, but these errors were encountered: