Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SeaweedFS fast distributed storage system for blobs, objects, files and datalake

github.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#71

Post by tinco »

vendiddy wrote: post #69
maeln wrote: post #67

Earlier quoted context omitted.

Yes and no. While for most application, the GC is hardly an issue and is fast enough, the problem is for application where you need to be able to control exactly when and how memory/objects will be freed. These will never do well with any form of GC. But a looot of software can perform perfectly fine with a GC. If anything, it is mostly Go error handling that is the bigger issue...

Why is Go error handling the bigger issue?

You can often tell a system is written in Go when it locks up with no feedback. Go gives the illusion that concurrency is easy, but it simply makes it easy to write fragile concurrent systems.

A common pattern is that one component crashes because of a bug or a misconfiguration, then the controlling component locks up because it can't control the crashed component, and then all the other components lock up because they can't communicate with the locked up controller.

Anyway that's my experience with several Go systems. Of course it's more a programming issue than a deficiency in Go itself. Though I think the way errors are return values that are easily ignored and are frustrating to deal with encourage this sort of lax behavior.

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#72

Post by ddorian43 »

seized wrote: post #24
bnewbold wrote: post #12

SeaweedFS does the thing: I've used it to store billions of medium-sized XML documents, image thumbnails, PDF files, etc. It fills the gap between "databases" (broadly defined; maybe you can do few-tens-KByte docs but stretching things) and "filesystems" (hard/inefficient in reality to push beyond tens/hundreds of millions of objects; yes I know it is possible with tuning, etc, but SeaweedFS is better-suited). The do…

GarageS3 is a nice middle ground, it is not file on disk per object but it's simpler than SeaweedFS as well. https://garagehq.deuxfleurs.fr/

Garage has no intention to support erasure coding though.

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#73

Post by ddorian43 »

blr_lpm wrote: post #57
pilgrim0 wrote: post #22

Earlier quoted context omitted.

I was quite surprised to discover that minio is one file per object. Having read some papers about object stores, this is definitely not what I expected.

What are the pros/cons of storing one file per object? As a noob in this domain, this made sense to me. It will be great if you can share name or reference of some papers around this. Thank you in advance.

When using HDDs, you want to chunk files at about 1MB-10MB. This helps with read/write scaling/throughput etc.

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#74

Post by ddorian43 »

lolpanda wrote: post #52

For companies hosting their entire infra on AWS, what's the advantage of SeaweedFS running on a fleet of EC2 machines over storing on S3?

Nothing. AWS doesn't give you the option to rent HDDs to create your own S3 so you're locked in to use S3.

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#75

Post by [deleted] »

jdthedisciple wrote: post #62

Sounds great! Now I only need to wait 10 years until all the hidden but crucial bugs are found (at the massive loss of real data, ofc) before I'm ready to use it, like with every new piece of technology... Or what should give me the confidence that it isn't so?

[deleted]

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#77

Post by ddorian43 »

throw0101d wrote: post #44

Advantages over Ceph?

Ceph should have 10x+ metadata overhead for chunk storage. When using erasure-coding writes are faster because it's using replication and then erasure-coding is done async for whole volumes (30GB).

Re: SeaweedFS fast distributed storage system for blobs, objects, files and datalake

#80

Post by arccy »

papaver-somnamb wrote: post #65

Tried and rejected SeaweedFS due to Postgres failing to even initialize itself on a POSIX FS volume mounted over SeaweedFS' CSI driver. And that's too bad, because SeaweedFS was otherwise working well! What we need and haven't identified yet is an SDS system that provides both fully-compliant POSIX FS and S3 volumes, is FOSS, a production story where individuals can do all tasks competently/quickly/effectively (manag…

running something like postgres over a networked filesystem sounds very wrong
Post reply on HN