undefined | Better HN

0 pointsDave3of52y ago0 comments

> No, you get a DBMS and only change the storage underneath

I think what you mean is what we have implemented a side channel DBMS which holds a copy which you use for the transactionality. It's a terrible approach I would not do this at all you don't get any benefit from using s3 here.

This is not to say you can't use s3 to pull large blob storage off the DB and reference it in the DB I'm talking about the entire DB as s3.

0 comments

ddorian432y ago

> I'm talking about the entire DB as s3.

Yes, it can be done, except for WAL append & COLD GET. You "just" have to re-architect everything in the storage layer.

Do you have anything specific in mind besides the 2 things I mentioned?

Dave3of5OP2y ago

You haven't given specific of this to be blunt no idea what you mean.

I already said my points about the problems your follow-up comments have not addressed those.

Also there is no such thing in s3 as a cold GET there is a cold startup for a lambda. The latency from s3 on a get is orders of magnitude poorer that EBS or LSSD and should be used "infrequently".

ddorian432y ago

Imagine using rocksdb backed by S3. You store only sstables in S3. You append the WAL in EBS and archive it in S3. You cache blocks in local SSD. If you want faster WAL, you append the WAL in local-ssd and use multi-az replication in your db and fsync WAL to EBS less frequently than locally.

> What about transactionality, partial updates, running multi document queries, consistency of the whole set of documents.

You do that in another layer on top. The filesystem doesn't provide transactions, yet you do them on a layer on top.

> In terms of scalability there are, limits 3500rps per key prefix.

The S3 metadata is (was?) sharded on key-prefix. You fix this by using more prefixes. By hashing the filenames or something.

> The latency from s3 on a get is orders of magnitude poorer that EBS or LSSD and should be used "infrequently".

Yes, it is. You should use a local SSD for most things.

1 more reply

j / k navigate · click thread line to collapse

0 pointsDave3of52y ago0 comments

> No, you get a DBMS and only change the storage underneath

This is not to say you can't use s3 to pull large blob storage off the DB and reference it in the DB I'm talking about the entire DB as s3.

0 comments

ddorian432y ago

> I'm talking about the entire DB as s3.

Yes, it can be done, except for WAL append & COLD GET. You "just" have to re-architect everything in the storage layer.

Do you have anything specific in mind besides the 2 things I mentioned?

Dave3of5OP2y ago

You haven't given specific of this to be blunt no idea what you mean.

I already said my points about the problems your follow-up comments have not addressed those.

Also there is no such thing in s3 as a cold GET there is a cold startup for a lambda. The latency from s3 on a get is orders of magnitude poorer that EBS or LSSD and should be used "infrequently".

ddorian432y ago

> What about transactionality, partial updates, running multi document queries, consistency of the whole set of documents.

You do that in another layer on top. The filesystem doesn't provide transactions, yet you do them on a layer on top.

> In terms of scalability there are, limits 3500rps per key prefix.

The S3 metadata is (was?) sharded on key-prefix. You fix this by using more prefixes. By hashing the filenames or something.

> The latency from s3 on a get is orders of magnitude poorer that EBS or LSSD and should be used "infrequently".

Yes, it is. You should use a local SSD for most things.

1 more reply

j / k navigate · click thread line to collapse