yeah, that lines up with my observations too.
it did take a lot of work to iron out the bottlenecks though. khatru badger in particular gets a big score on the ranking because of the way its badger event store just flings events but i bet it fails to always get them in order on a relay that has had old events loaded up after a lot of newer ones. it depends on sequence of events being stored to order the results. orly has a special index to make sure they always are delivered in the explicit order of timestamp, and if you read nip-01, you will see. fiatjaf cheated on that with khatru. and relayer.
Login to reply
Replies (1)
index optimization is crucial… on NFDB 2.1 I have worked on some stuff:
- some index size optimizations
- move the event header (content stripped + only indexables) into the event store as before it was duplicated across multiple dbs sharing the same eventstore
- a faster “exists in any one of these relays” lookup with event stores, that also can return event lifecycle info
- better event lifecycle state (NFDB supports a soft-deleted stage, and for large events like follow lists it is inserted in multiple transactions due to FDB size limit)
- unified deletion index that can be shared across all relays
- unified event state data (encoded with capnp, contains lifecycle + expiration + index version + size + …)
- “size” accounting based on any metric
- global event cache