WIP: Add default implementation for the database #1

Copy link

era commented 2022年07月24日 19:51:34 +02:00

Thinking out loud (take it with a bit of salt, there is probably someway better to do what I'm saying here):

It would be nice to use the HashMap to find if the key is in the cache, so we can do it in O(1) instead of O(n). For that you must be able to locate the entry in the lru_cache with the information provided by the index object. One way to do that would be to store the position of the item in the index object. But everytime we move an object from position x to 1 we would have to update the x elements in the index as well with their new position.

Another way would be to point to the node itself from the index. Since the node contains prev & next, we could easily swap it to the front without having to update x elements.

Sooner or later we may need to introduce a TTL configuration for the cache. If that's the case, I think there is an interesting third option:

1. Create an object Bucket:

struct Bucket{used_at: Timestamp// milliseconds precision
values: Map<Key,Value>}

1. transform lru_cache in a MaxHeap or MinHeap which elements are Bucket and they are sorted by used_at.
2. Modify the index to store the used_at timestamp.
3. When getting the key:

self.index.get(key).map(|timestamp|self.lru_cache.get(timestamp).values.get(key))//omiting the process of updating the timestamp

Dropping items from the cache: you will need to get the oldest timestamp in the queue and drop one entry in the values. If values are empty you can remove the timestamp from lru_cache as well. We are sacrificing some correctness here, if there are more than one value in the given timestamp we may not be respecting exactly the order they were used, but the error here should be so marginal that I don't think we care.

PS: We could also just use a LinkedHashMap and merge lru_cache and index in the same object, which would be the simplest solution.

Thinking out loud (take it with a bit of salt, there is probably someway better to do what I'm saying here): It would be nice to use the HashMap to find if the key is in the cache, so we can do it in O(1) instead of O(n). For that you must be able to locate the entry in the lru_cache with the information provided by the index object. One way to do that would be to store the position of the item in the index object. But everytime we move an object from position x to 1 we would have to update the x elements in the index as well with their new position. Another way would be to point to the node itself from the index. Since the node contains prev & next, we could easily swap it to the front without having to update x elements. Sooner or later we may need to introduce a TTL configuration for the cache. If that's the case, I think there is an interesting third option: 1) Create an object Bucket: ```rust struct Bucket { used_at: Timestamp // milliseconds precision values: Map<Key, Value> } ``` 1) transform lru_cache in a MaxHeap or MinHeap which elements are Bucket and they are sorted by used_at. 2) Modify the index to store the used_at timestamp. 3) When getting the key: ```rust self.index.get(key).map(|timestamp| self.lru_cache.get(timestamp).values.get(key) ) //omiting the process of updating the timestamp ``` Dropping items from the cache: you will need to get the oldest timestamp in the queue and drop one entry in the `values`. If values are empty you can remove the timestamp from lru_cache as well. We are sacrificing some correctness here, if there are more than one value in the given timestamp we may not be respecting exactly the order they were used, but the error here should be so marginal that I don't think we care. PS: We could also just use a LinkedHashMap and merge lru_cache and index in the same object, which would be the simplest solution.

era commented 2022年07月24日 20:23:25 +02:00

PS2: The third option is O(logn)

PS2: The third option is O(logn)