Database Reference
In-Depth Information
U66.300 . Because of this randomness, writes for the topic ID U66 are spread across
multiple hash key values for better throughput and parallelism.
This approach seriously fine grains the write throughput, but reads for a specific item be-
come harder because you are not aware of which of the 400 keys contains the particular
item. Here, instead of selecting a completely random number, select a number that you
will be able to calculate from a bit inherent to the item. Here for example, if the item
shows a customer that has the topic, calculate the hash key suffix from his/her name or
book ID. This calculation should compute a number between 1 and 400 that is reasonably
distributed given any set of names (or book IDs.) Now the writes are extending across the
hash keys. You can easily perform a get operation because you can conclude the related
hash key when you want to regain a specific book consumer value. Query operations re-
quire a tranquil environment to run beside all U66.x keys and your app requires specific
logic to merge all of the query results for each hash key value. But here, the schema will
avoid hot hash keys taking all of the workload.
Search WWH ::




Custom Search