4 ms·

Well it seems clear to me that they can only provide that level of performance for blocks already in their onsite cache. Presumably they're using a novel compre

Well it seems clear to me that they can only provide that level of performance for blocks already in their onsite cache. Presumably they're using a novel compression/de-duplication scheme and maybe prioritizing blocks using historical and/or predictive analysis to cache the right data at the right time but you can only transfer data as fast as you can transfer it. I'm guessing a full export of all of your data (that isn't cached) is going to go as fast as the line/compression allows.

colanderman 10y ago
Bandwidth is much less a problem for OLTP workloads than latency is. (If all you care about is bandwidth, S3 is your friend.) With ClearSky, even for workloads that don't fit in the edge cache (which we believe are few), you'll still see single-digit millisecond random read (and write) latencies. This is made possible by our points of presence (PoPs) located in each metro area we serve. These PoPs house the lion's share of data in a private cloud, and are connected to each customer site with private lines with sub-millisecond latency. In other words, the speed of light is very fast when it goes in a straight line with nothing in its way ;) While we do have some secret sauce in the data pipeline, it is because we own the network to the customer that we can provide the performance we do. (Fancy PDF with a few more details here: http://cdn2.hubspot.net/hubfs/445689/2015_assets/ClearSky-Data-Sheet.pdf http://cdn2.hubspot.net/hubfs/445689/2015_assets/ClearSky-Da...)