2 ms·
I think the OP means less about perf and more about dollar cost since you have to either be able to trust the uptime of a storage node (and likely pay more) or
by vhiremath4 5y ago
I think the OP means less about perf and more about dollar cost since you have to either be able to trust the uptime of a storage node (and likely pay more) or make more copies (and therefore pay more) in order to be guaranteed your data isn't lost when a node goes down.
The performance of splitting up files and storing them on multiple nodes tends to be very good since you're not as bottlenecked to one node feeding out all of the bytes (think about bitorrent and how fast it is to download a well-seeded file). That said, network egress might become a problem if the node you're seeding content from lives within AWS or another cloud provider. I don't think this egress price penalty exists in any major ISPs that I know of.
- cmckn 5y agoThe comment you’re replying to is poking fun at a gag project; but I agree with you as well. The ETH chain was about 500 gigs over the summer when I synced a full node, but it was growing fast. The amount of data stored is monotonically increasing for every full node in the network. You also need fast storage, you can’t use dirt cheap spinning platters. Maybe it won’t grow faster than storage cheapens, but I’m not sure I’d make that bet.
- vhiremath4 5y agoAhhhh missed the "/s" at the end of the comment I was reply to. :facepalm: > The amount of data stored is monotonically increasing for every full node in the network Right-O. Also the archived nodes seemed to be ~6TB in size a year ago. Today I learned! https://ethereum.stackexchange.com/a/91156 https://ethereum.stackexchange.com/a/91156
- knorker 5y agoAlso the linked performance section says that going from 0.005s to 3 minutes is "negligible performance overhead". I added the "/s" to spare people clicking through before realizing it was a joke.