Please don't post your own garbage with only a half-dozen commits and zero users.
Wait for something to be used by more than yourself before you assume anyone else will want to see it.
Anyways, the whole thing is utterly broken because S3 has no consistency guarantee on read-after-update, only read-after-write-untouched-key, so each get of a partition ID can be arbitrarily stale.
This is terrible feedback. Have you used it? Do you plan on using it? If the answer to both of those questions is "no," then you (a) can't call it garbage, and (b) haven't provided anything useful. The whole point of showing something on HN is to get more feedback and, in turn, more users.
In the current form, I don't directly deal with stale reads. But there is a CheckExpiry [1] method that iterates thru each cached partition, does a HEAD request to the corresponding S3 object and compares Last-Modified. If the cached object is older than the one in S3, the cache will be invalidated. Currently the user needs to invoke this by them-self.
I also plan on having a user configurable TTL per partition, so user could use low TTL for objects they expect to change, i.e. One would think data for today might change soon, but data from 5 years ago wont.
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.
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 :/.
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.
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.
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!
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.)
29 comments
[ 2.6 ms ] story [ 66.6 ms ] threadWait for something to be used by more than yourself before you assume anyone else will want to see it.
Anyways, the whole thing is utterly broken because S3 has no consistency guarantee on read-after-update, only read-after-write-untouched-key, so each get of a partition ID can be arbitrarily stale.
How did you deal with stale reads caused by S3 lacking consistency guarantees on read-after-update?
In the current form, I don't directly deal with stale reads. But there is a CheckExpiry [1] method that iterates thru each cached partition, does a HEAD request to the corresponding S3 object and compares Last-Modified. If the cached object is older than the one in S3, the cache will be invalidated. Currently the user needs to invoke this by them-self.
I also plan on having a user configurable TTL per partition, so user could use low TTL for objects they expect to change, i.e. One would think data for today might change soon, but data from 5 years ago wont.
[1] https://godoc.org/github.com/turbobytes/infreqdb#DB.CheckExp...
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.
Also why don't you dump the log data into a NoSQL like dynamoDB instead of S3 ?
> Also why don't you dump the log data into a NoSQL like dynamoDB instead of S3 ?
Price.
> Write Throughput: $0.0065 per hour for every 10 units of Write Capacity (enough capacity to do up to 36,000 writes per hour)*
> A unit of Write Capacity enables you to perform one write per second for items of up to 1KB in size
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.
That would probably turn out to be cheaper than using S3 - https://github.com/minio/minio
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!
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?