educative.io

KGS ... confusion

If someone can help my confused thinking …

What is meant by “keep some keys in memory…” in the statement below?
KGS can always keep some keys in memory so that it can quickly provide them whenever a server needs them.

Then this suggestion in the very next passage … how does the above and the below work together or are they two separate approaches?
For simplicity, as soon as KGS loads some keys in memory, it can move them to the used keys table

Also, the KGS section has been talking about tables yet mentions data structures in the passage below. Can anyone explain what DS is involved?
KGS also has to make sure not to give the same key to multiple servers. For that, it must synchronize (or get a lock on) the data structure holding the keys before removing keys from it and giving them to a server

Finally, although duplicate KGS keys are unlikely, collisions can happen. With a two table approach, will KGS need to check for collisions on both tables before generating new keys?

Thank you!

1 Like

For your first question “keep some keys in memory…”, I think this is one possible scenario:

If you implement the KGS with Java, you can think that “keep some keys in memory…” means you store some keys into a collection like LinkedHashMap, since we know that all java object will be located in the heap area of the JVM, which means it’s in the memory instead of the physical storage.

Next question, “For simplicity, as soon as KGS loads some keys in memory, it can move them to the used keys table”, as my imagination, it can be something like:

  1. The program loads keys that are not used from the table.
  2. Add those keys into the collection, and then move the record of those keys in the database from “not used key” table to “the used keys” table.

Hope this could help you to understand it.

The third question, “KGS also has to make sure not to give the same key to multiple servers. For that, it must synchronize (or get a lock on) the data structure holding the keys before removing keys from it and giving them to a server”

For this, I think it could be something like ConcurrentHashMap in Java, for more detail about the implementation, you can refer to this link.

For the final question, I think there might not be a generating new keys functionality in the system since in the section “Generating keys offline - What would be the key-DB size” has said that it already generate 64^6 = ~68.7 billion possible strings by using base64 encoding. Which can be seen as the power sets of all possible output. That’s why I think we don’t need a functionality for “regenerating” the keys.

Also, in the section of “purging or DB cleanup”, the author supposed that “After removing an expired link, we can put the key back in the key-DB to be reused”. I think it’s similar to “regenerate” the key for reusing.

Not sure my understanding is correct, please just see it as a reference.