Live data from Hacker News

HopsFS: 100x Times Faster Than AWS S3

logicalclocks.com

71–80 of 139 posts

Re: HopsFS: 100x Times Faster Than AWS S3

#72

Earlier quoted context omitted.

Reading through your article, this solution is built on top of s3. So, moving and listing files is faster, presumably due to a new metadata system you've built for tracking files. The trade off here, is that writes must be strictly slower now than they were previously because you've added a network hop. All read and write data now flows through these workers. Which adds a point of failure, if you steam too much data…

I'm one of the co-authors. The numbers for writes are in the paper, so it is very unfair to call it an advertisement. And it is a global cache - if the block is cached somewhere, it will be used in reads.

The parent does make a good point about centralization of requests being a problem. S3 load balances under the hood, so different key prefixes within a bucket are usually serviced in isolation -- a DoS to one prefix will usually not affect other prefixes.

It seems like you'd be limiting yourself for concurrent access -- if everything is flowing through the MySQL cluster -- not a bad thing! Just perhaps warrants a caveat note. I'd expect S3 to smoke HopFS on concurrency.

Re: HopsFS: 100x Times Faster Than AWS S3

#73
post #69
post #52

Earlier quoted context omitted.

> EdgeFS is one I was looking at recently Do you have any additional info? EdgeFS's github[1] doesn't work; does repo access require a Nexenta sales call? We're also looking into asynchronously replicated FSs, I think built-in caching + tiering is slightly nicer than cron + rsync; would love to know what other solutions you looked into. [1] https://github.com/Nexenta/edgefs

Don't give up too easily on (something like cron+rsync). Things like cron+rsync fail in boring ways. Fancy things fail in fascinating ways .

This guy rsyncs

Re: HopsFS: 100x Times Faster Than AWS S3

#76
post #44

Earlier quoted context omitted.

> It usually starts with NFS, which is a big huge single point of failure. NFS is just the protocol. Whether it's a single point of failure depends on the server-side implementation. In Amazon EFS it is not. (disclaimer: I'm a PM-T on the EFS team)

Hi, my use case for EFS Lambda is burts of small writes. Could you add a perf mode that favors bursts of small writes? We did some perf tests and just couldn’t make it fast enough.

https://www.netapp.com/cloud-services/cloud-volumes-service-...

You could try NetApp - it's significantly faster than EFS in my experience.

Re: HopsFS: 100x Times Faster Than AWS S3

#78
post #39

Earlier quoted context omitted.

Any particular reason you don't tag the objects instead? That's a significantly lighter-weight operation, since S3 doesn't have native renaming capability.

You can't list objects by tag.

IIRC, you can, but it's bit elliptical: because IAM access policies can key off tags, you can adopt an IAM role that can only see the desired tags, and list objects.

Re: HopsFS: 100x Times Faster Than AWS S3

#79
post #39

Earlier quoted context omitted.

Any particular reason you don't tag the objects instead? That's a significantly lighter-weight operation, since S3 doesn't have native renaming capability.

You can't list objects by tag.

Ah hah - but see https://medium.com/zendesk-engineering/resurrecting-amazon-s...

Re: HopsFS: 100x Times Faster Than AWS S3

#80

S3 isn’t a file system. It’s a key-value store. If you’re trying to use it as a file system, you’re doing it wrong :)

This.

It is an eventually consistent key-value store with some built-in optimization (indexes) for filtering/searching object timestamps and keys (e.g. listing keys by prefix), which allows for presenting them in a UI similar to how it is possible with files in a directory. That's about it.

Post reply on HN