I assume that the key for content. Then paste table and user table are in metadata database and content is in object storage. Does that mean we need paste urlKey to get contentKey in metadata database , then use content key to find content in object storage? There is a performance issue and also we need use hash and encode methods to generate contentKey just like urlKey. Do I get it correct or there is other explanation?
2 Likes
Hi Franklin,
Yes your understanding is right. As mentioned in the chapter:
Here, ‘URlHash’ is the URL equivalent of the TinyURL and ‘ContentKey’ is the object key storing the contents of the paste.
Performance could be issue here, we can use ContentKey as the primary key in the Paste table. This way we don’t need a separate URLHash but then we need a bigger filed to store the key, as ContentKeys (cloud storage keys) are generally bigger. Secondly same ContentKey will be part of the paste’s URL which could be a security issue.
Hope this answers your question.
2 Likes
What’s the downside of using a bigger field to store the primary key if we use ContentKey as the primary key?
I guess that’s not the main reason why we’re not doing this, the primary risk here is security, we should not expose the primary key in the URL, which may lead to many other problems. See also: https://softwareengineering.stackexchange.com/questions/218306/why-not-expose-a-primary-key
If the URL and the Content Key are each 6-letters string , are we just grabbing two 6-letters strings from the not used table of the KGS service?
ContentKey is not 6-letters long. It would be lot bigger, generally a UUID. See our comment above:
Performance could be issue here, we can use ContentKey as the primary key in the Paste table. This way we don’t need a separate URLHash but then we need a bigger filed to store the key, as ContentKeys (cloud storage keys) are generally bigger. Secondly same ContentKey will be part of the paste’s URL which could be a security issue.