One day, many years ago, in a panic of "how the hell do I make this scale: I need it to work right now" I replaced an infrequently read data logging setup I had with S3... I ended up spending >$100k storing keys into that thing and momentarily was 2% of all objects stored in S3 (based on the stats they occasionally provided) before I eventually (two or three years later?) retired it; and to be extremely honest and to add insult to injury, my read access was so "infrequent" that I think I just never ended up reading it again after that day :/.
Yes. I should include this info in the README calcs. For my usecase I intend to do 4 - 10 PUTs per hour, since they are batched. 10 PUTS/h = 7300 PUTs/month = $0.073/month. The key here is infrequent
Be most careful with retries. Saw a case where the bucket wasn't writable and the code just retried in a loop. You get charged for the API call, successful or not.
Stuff like this is great! And you said you mentioned you are primarily doing it for timeseries data - then you can easily batch writes to handle high volume throughput too!
Maybe you should take another look at pricing? DynamoDB is like $0.002/GB/month more expensive than S3 for storage. Requests are more expensive, but you're also not reinventing every wheel and if they're as infrequent a set of requests as this seems designed for it's still only a few bucks a month.
So, a database that's has a file format of write-once content-addressed "shards" and is persisted/distributed by "offlining" those shards into object storage, and then "onlining" them back into a given DB node's MRU cache at query time; and is mostly read-only, but can update by downloading the relevant shards, modifying them locally, re-hashing the modified shards to get new names for them, and then uploading them again under those new names.
Is this basically equivalent to Datomic, then? (Not that that's a bad thing. The world needs an open-source, non-JVM-targeted Datomic.)
I think flat JSON files wont be efficient. My goal is to have the cache on disk, and each cached file would be big with lots of keys on it. In order to use JSON files, I would either have to keep the whole parsed data in memory, or parse the whole JSON each time I want to lookup a key.
If the data fits in memory then sure JSON is more convenient.
Comments
Be careful using S3 for lots of small writes. The price is utterly dominated by the PUT calls which cost $0.01/1000.
One day, many years ago, in a panic of "how the hell do I make this scale: I need it to work right now" I replaced an infrequently read data logging setup I had with S3... I ended up spending >$100k storing keys into that thing and momentarily was 2% of all objects stored in S3 (based on the stats they occasionally provided) before I eventually (two or three years later?) retired it; and to be extremely honest and to add insult to injury, my read access was so "infrequent" that I think I just never ended up reading it again after that day :/.
Yes. I should include this info in the README calcs. For my usecase I intend to do 4 - 10 PUTs per hour, since they are batched. 10 PUTS/h = 7300 PUTs/month = $0.073/month. The key here is infrequent
Be most careful with retries. Saw a case where the bucket wasn't writable and the code just retried in a loop. You get charged for the API call, successful or not.
Stuff like this is great! And you said you mentioned you are primarily doing it for timeseries data - then you can easily batch writes to handle high volume throughput too!
We did this with S3 as the storage engine, 100M+ records for $10/day: https://www.youtube.com/watch?v=x_WqBuEA7s8
And discord had a very nice article on this as well: https://blog.discordapp.com/how-discord-stores-billions-of-m...
Great work, I think there is a lot of exciting stuff you can add to it!
That's cool. Last week I tried googling for similar stuff but all I could find was people asking "How to run postgres on S3"...
We use a similar approach with TrailDB. You can make S3 access totally seamless with user-space page fault handling, which is pretty cool: http://tech.adroll.com/blog/data/2016/11/29/traildb-mmap-s3....
Next level, same idea but with SQLite: https://github.com/lmatteis/torrent-net
This is pretty cool. Do you invalidate all pages if the file changes upstream on S3?
In our case all blobs in S3 are immutable, so no need to invalidate anything.
How is this different than AWS Athena ? - https://aws.amazon.com/blogs/aws/amazon-athena-interactive-s...
Also why don't you dump the log data into a NoSQL like dynamoDB instead of S3 ?
Athena looks cool. Didn't know about it. It probably describes what I'm trying to do.
Price.
Maybe you should take another look at pricing? DynamoDB is like $0.002/GB/month more expensive than S3 for storage. Requests are more expensive, but you're also not reinventing every wheel and if they're as infrequent a set of requests as this seems designed for it's still only a few bucks a month.
My infrequent reads and writes are huge, and possibly spikey.
As I understand it, for $4.68/month I can only add 36 MB/hour, and thats assuming my objects are in exact multiple of 1KB.
Ahh, gotcha. That makes sense, this setup makes a lot more sense if you're dealing with very spikey reads.
If your data storage requirement is semi-constant at 1.5TB and is ephemeral, have you looked at just using your own replicated servers ?
That would probably turn out to be cheaper than using S3 - https://github.com/minio/minio
The data is not ephemeral, only the cache is.
So, a database that's has a file format of write-once content-addressed "shards" and is persisted/distributed by "offlining" those shards into object storage, and then "onlining" them back into a given DB node's MRU cache at query time; and is mostly read-only, but can update by downloading the relevant shards, modifying them locally, re-hashing the modified shards to get new names for them, and then uploading them again under those new names.
Is this basically equivalent to Datomic, then? (Not that that's a bad thing. The world needs an open-source, non-JVM-targeted Datomic.)
Couchdb?
What do you think about this being able to work with Gzip compressed JSONs stored on S3? Cool project, thank you.
Thanks.
I think flat JSON files wont be efficient. My goal is to have the cache on disk, and each cached file would be big with lots of keys on it. In order to use JSON files, I would either have to keep the whole parsed data in memory, or parse the whole JSON each time I want to lookup a key.
If the data fits in memory then sure JSON is more convenient.