Replying to Avatar ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ

also, you probably didn't know this because you haven't actually written a relay, you have to unpack the whole event. it's not capn proto or flatbuffers style read on demand. but even if it was, i don't think that really changes anything. to store events in a database you have to decode the entire event anyway. single letter tags have to be indexed by spec anyway. i just think why not also index all the tags. it's really not that complicated to implement. databases use hash functions for this reason, to enable indexing words.
Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

further, all the relays that use RDBs and NoSQL DBs are automatically indexing all those tags whether you like it or not.

i write database engines from scratch using a KV store, and it's not really that difficult, and the tailoring of the implementation greatly improves performance. i don't think i'm exaggerating when i say that the #orly database engine is the fastest in all of nostr. it uses an engine that is used for a moderately popular graph database called dgraph, and you can't do that shit without highly optimized iteration and log storage strategies.

Reply to this note

Please Login to reply.

Discussion

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

also, my custom nostr-specific JSON unmarshal function is nearly as fast as a binary decoder for an optimized binary encoding. about 20% slower. it's also the fastest json event decoder in all nostr land.