Replying to Avatar semisol

the underlying DB matters too, in this case, it uses an external K/V DB that handles scaling, and can distribute load to multiple servers instead of one disk

which allows scaling way higher than 1 server’s disk or CPU

the amount of latency added is negligible compared to a local DB
Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

i can see how that would be a plus... i have pondered a lot the idea of making relays able to use othre relays as second level stores, i already wrote the code so that whatever comes back from the layer2 is cached and is found faster from the relay event store

Reply to this note

Please Login to reply.

Discussion

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

also, yeah, K/V stores are the best... it's really not worth the time to market advantage of generalised sql/graph databases unless the data really is of the kind those DB architectures are faster for

for nostr, KV is teh only way, the indexes are super simple and there's just no reason to extend it unless you want to implement this "DVM" bullshit, which is really just fucking full text search and maybe image/video classifier shit that AIs could probably help with

people are so hyped about AI but really it only improves image, voice and video recognition, that's good, and all, but lol, it's not skynet, gimme a break, fucking morons in fiat corporate VC land

Avatar
semisol 1y ago

I will check out realy, at least for replacing parts of go-nostr and khatru as I don’t really like it

NFDB is just an event store, the extensibility part is for modifying the query pipeline and indexing

the indexes use a fully pluggable provider, and it is really easy to change things, such as to add search indexes