141–150 of 237 posts
Updated object store comparison: http://gaul.org/object-store-comparison/
your chart is missing https://nimbus.io/ which is .02 per GB/Mo.
https://github.com/andrewgaul/object-store-comparison/issues...
Earlier quoted context omitted.
Our inbound is not completely full, and we always try to have extra capacity/headroom for new customers. But if you plan to upload more than 5 petabytes at a rate of faster than 15 Gbps sustained, you probably want to contact us ahead of time to let us know it's coming and we'll increase our capacity for you. We can absorb anything less and it won't cause us any issues. As somebody else mentioned, since we're in a co…
> we're in a commercial datacenter with a bunch of network providers already serving us, it's pretty easy to dial up our capacity as we need it. Whats the lead time in your case? In my historic experience doing this regardless of if I was even in MAE-West... cross connects and provisioning were eons in internet time...
It could go faster, but if we need to buy a new (expensive) network switch that can take a few days to arrive. And as you mention, the datacenter guys are happiest if you give them 3 - 4 days and a work order to do the cross connect.
Building out more vaults (the blocks of 20 storage pods we store data in) is usually about the same if we rush it, but we have a big (multi-petabyte) buffer spinning ready to accept data at anytime. We have a regularly scheduled delivery of pods once per month based on projections, but we have been known to tell our provider to go ahead and build three months worth of pod chassis (everything except for the drives) immediately and ship them to us. We supply the hard drives, so that either comes from our own stashes or we quickly order some more from various sources.
Earlier quoted context omitted.
> It is surprising that they didn't make it compatible with the S3 API .... The lack of scalable front-end load balancing is shown by the fact that they require users to first make an API call to get an upload URL And... you answered your own question. :-) We reduce our operating costs by not having as many load balancers in the datacenter and pushing off the responsibility to the API. It all comes from our tradition…
I, for one, prefer the directness of not having to go through a front-end proxy. It probably eliminates some failure modes. I think that, instead of Backblaze providing an S3-compatible API, someone should do an open-source S3-compatible front-end for B2, that any interested user can run on a cheap VPS.
Earlier quoted context omitted.
It is certainly interesting how OVH undercuts the competition by quite a large margin in everything. We use them for dedicated servers, but I wonder why they're not as well known as AWS...
Yeah, it is very interesting how everyone here loves AWS. And the reasons for it seem to be (1) the "trust" in AWS, (2) the existing knowledge about AWS's API etc. and (3) that it's just not worth the time to evaluate another provider because you could spend your time growing your startup/doing something more profitable. And these are interestingly exactly the same reasons enterprises buy IBM and Oracle. This is actu…
Reading the API, it seems that I need to precalculate a SHA-1 before uploading? This makes it impossible to stream data to b2 from another source, I'll need to store it first then send to b2.
Right now your only option would be to "buffer" packets of say 1 MByte in RAM, calculate the SHA-1, then store them as separate files in Backblaze B2. We do plan to add file offset access and larger file support very soon, so you would be able to append a 1 MByte chunk to an existing file in Backblaze with a SHA-1 of only the 1 MByte chunk. That should allow you to stream? All great feedback, by the way. We really wa…
Being able to append to a file in 1 MByte chunks (or larger) would be perfect - that is exactly the way Amazon S3 multipart uploads and google drive multipart uploads work.
Took a quick look at the API. For context, I was involved in the early days of Google Cloud Storage. It is surprising that they didn't make it compatible with the S3 API -- at least for common object/bucket create/delete. This will require more code to be written and it will be harder to adapt client libraries. The API documentation is here: https://www.backblaze.com/b2/docs/ Other notes: * The lack of scalable front…
> They require a SHA1 hash when uploading objects. This is probably overkill over a cheaper CRC. Having been on the receiving end of entirely too many corrupted files in my life, I strongly approve of their use of a hash that's been standardized and fast for decades and remains cryptographically strong. "But fast" if you fail to store it isn't very helpful. TCP has a CRC too. We're wallpapering over it with better on…
But there is no call for a cryptographic hash here. This isn't being used as any sort of ID or to verify integrity outside of corruption.
Buyer beware when it comes to Backblaze.
Finally some more reasonable prices in this space. Eventually it could make sense for Backblaze to partner with someone like DigitalOcean or Linode and offer low cost bulk storage and low cost virtualization colocated in the same datacenter: these services seem to be a perfect complement for each other.
To elaborate: I think these two would be able to become a viable competitor to AWS. If you think about it AWS launched with S3 and then EC2.
They could differentiate themselves by staying as a pure IaaS play. Then companies like Dropbox would not be afraid of DigitalBlazeOcean moving up the stack and competing as AWS has done in several instances (e.g. WorkDocs).