Why separate keys for each metadata parameter? #113
Description
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.