ambry

Short answer: Yes.

However, Ambry doesn't use byte-ranges for the upload. Each chunk can be uploaded separately and the client then requests a _stitch_ operation[1]. In that operation, the client specifies the list of blob IDs for each chunk (in order) and asks Ambry to create a metadata blob listing those IDs. Ambry then returns the blob ID for the metadata blob.

[1]: https://github.com/linkedin/ambry/blob/9b7a49ac79b1678fd7fd7...

Internally, Ambry stores large objects as a series of chunks. At LinkedIn we've found that 4mb makes a good chunk size. So (for example), your 40mb upload could be streamed directly where Ambry would handle chunking it, or you could chunk it yourself. Client-side chunking has the advantage of cleaner resumption from a broken connection. After all the chunks are uploaded, Ambry creates (or the client asks Ambry to create[1]) a special metadata blob which contains a listing of all the chunk blob IDs. Clients can use the blob ID of the special metadata blob as a single reference to the large (composite) object without needing to worry about the underlying chunking for GET and DELETE operations.

Depending on context, anything larger than the chunk size could be considered a large object, but using this method Ambry easily handles gigabyte- and larger-sized objects.

[1]: https://github.com/linkedin/ambry/blob/9b7a49ac79b1678fd7fd7...

That's right: You upload an object, and the HTTP 200 response includes a header that is the object ID. Your imagination is almost certainly correct: creating a mapping from user-defined key to storage location is really best done by a metadata store so that data doesn't need to be reshuffled with topology changes.

A classic distributed key-value store (such as Dynamo[1]) spends a lot of its design on how to consistently map user-keys to storage locations. Most of these solutions are focused on performance (so avoiding a middle-layer lookup) and accept the tradeoff that data will need to be re-balanced when doing things like expanding the cluster. This isn't an acceptable tradeoff for object stores that have much higher data density (100+ TBs per NIC)

[1]: https://www.allthingsdistributed.com/files/amazon-dynamo-sos...

I've worked on Ambry at LinkedIn for a little while, I'd be happy to answer any questions about architecture or things we've done since 2016. I wasn't part of the original team. One thing I would call attention to from the article:

> it’s key-value based approach to interacting with blobs doesn’t support file-system like capabilities, posing more of a burden on the user of the system (who must manage metadata and relationships between entities themselves).

I think this trade-off is one Ambry's strongest design decisions. By giving up key-value access, Ambry gets to dictate the location of an object at write time. When a partition fills up, set it to read-only and create new partitions on new hosts. By having Ambry generate the blob ID, the system can embed information (like the partition number) right in the ID. With a key-value approach you need to worry about balancing (and re-balancing) the key space over your topology. With dense storage nodes, re-balancing is VERY expensive.

Also--most applications don't actually need key-value access. For storing something like media (think: LinkedIn profile photo), you've already got a database row for the user profile; now one of those fields is a reference to your object store. It might as well be a storage-generated reference instead of one where the application tries to manage reference uniqueness and ends up using UUIDs or something similar anyway.

Apologies for the new account, I try to keep my main HN account semi-anonymous.