Hi Amit, On July 31, 2017 at 4:49:37 AM, Amit Jain ([email protected]) wrote:
With this in mind can't we just conceptually have a Composite DataStore (Not drilling down to interface/class hierarchy and API yet) which can then support the following: * User provided "type" of blob to influence the logical/physical DataStore the blob/file to be written to (Needs some sort of configuration to have some pre-defined types with mapping to the datastores). * Optionally defining characteristic of the DataStore(s) ** read/write ** storage class - slow,fast ** priority Can you give me a bit more detail about what you have in mind WRT “storage class”? What would be important to accomplish here that isn’t accomplished by “priority”? I’m not opposed to this idea, but it seems like it would be difficult to make it really useful. What I mean is, “slow” and “fast” are of course relative, and any terms I can think of to use in their place have the same limitation. Let’s consider AWS for an example. Using this nomenclature, you’d probably say Glacier is “slow” and S3 is “fast”. S3 IA is probably not any slower than S3, but you probably wouldn’t want to label it the same. But it is certainly not “slow” if Glacier is also slow. Likewise, if you also had a FileDataStore configured, it seems like S3 wouldn’t be “fast” anymore compared to FDS. I then thought of using terms like “hot” (S3), “cool” (S3 IA), and “cold” (Glacier), but I’m not sure what that tells me that I couldn’t know simply via priority. And that doesn’t address the problem that FDS would also be “hot” but probably hotter than S3. There could be a number of nuances in between as this grows. Storage class should be included if it can be, so long as it serves a purpose. I’m not sure I’m seeing the purpose yet. -MR
