search

nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

Time-ordered event ids #1587

Open vitorpamplona opened 2 days ago

vitorpamplona commented 2 days ago

There are a lot of performance benefits to having primary keys with temporal locality. For instance, when your database needs to check the uniqueness of IDs, only a small portion of the index needs to be hot (in memory). With the current "random identifiers", the working set eventually becomes all of the data and your database will be page-faulting continuously. Sequential primary keys also make it easier for the database to place new records in order, minimizing the need to rearrange data or update index structures.

This PR makes a simple, but breaking change, to the way we compute event ids. It was inspired by the improvements made by UUIDv7.

It's a long shot, but I do think we should do this at some point in Nostr's lifetime.

staab commented 2 days ago

Neat idea, might be a better fit for https://github.com/mikedilger/nostr-next

mikedilger commented 1 day ago

I don't use event IDs as database keys in chorus. I use offset (into a long list of events serialized back-to-back). I have to have an index from event ID to offset for filters specifying IDs, but all the other indexes go straight to offset.

But your idea would still cut down on page faults into the one index.