[deleted]
FoundationDB Record Layer
31–40 of 85 posts
Re: FoundationDB Record Layer
#32This might be the first good alternative to etcd for configuration stores that need real-time updates. Like Kubernetes. Many Kubernetes scaling issues are etcd-related. RethinkDB is dead-ish, and CockroachDB is treating their changefeeds as an enterprise feature that requires a Kafka instance to stream to :(
For kubernetes unless you’re past a couple of million keys it’s unlikely etcd is the issue, and other things would fall over first. However, if you’re at those levels it might be worth it to use something else.
I’m not sure foundation would be able to do the full consistent list required in the current model though (someone above mentioned full consistent table scans being not possible in FDB). In etcd and cockroach you can leverage MVCC and get a consistent scan over older history. But if FDB has that it’s pretty close (I looked into this before FDB was acquired the first time).
Edit: unlikely = in practice I haven’t seen anything except large range lock contention (which is why we added chunking to the api)
Re: FoundationDB Record Layer
#33Very interesting. I've been looking closely at FoundationDB as a way forward (to replace RethinkDB and Cassandra in existing systems). It's one of the few contenders for a really interesting take on a distributed database. I am not sure if I will use the record layer (I've been planning to write "my layer" myself), but it will definitely be an interesting thing to look at.
Fellow RethinkDB user here. I’ve been looking at Cassandra and FoundationDB as replacements. I’m genuinely curious— what didn’t you like about Cassandra?
Cassandra
To be honest, I don't like anything about Cassandra. Beginning with the naming: back when I was trying to learn about Cassandra, I couldn't get past the obscure and bizarre naming (super-columns?). When I dealt with systems using it, I never quite understood how you can keep saying that "the later timestamp wins" and speak of consistency with a straight face: in a distributed system, there is no such thing as a "later timestamp". Or speak of transactions which aren't really transactions at all.
Then I read the Jepsen reports about Cassandra. Yes, Cassandra has made progress since then, but still.
I think of Cassandra as an outdated piece of technology at this point: we can (and do) build better distributed databases today, with better consistency guarantees, and proper transactions in case of FoundationDB. Cassandra was designed for a specific use case and then outgrew its initial design, because there was nothing else at the time. But I see no reason to stick with it any longer.
Even now when you need massive multi-region scalability there is little to choose from — if you want it to be open-source, there's pretty much only FoundationDB left.
Re: FoundationDB Record Layer
#34This might be the first good alternative to etcd for configuration stores that need real-time updates. Like Kubernetes. Many Kubernetes scaling issues are etcd-related. RethinkDB is dead-ish, and CockroachDB is treating their changefeeds as an enterprise feature that requires a Kafka instance to stream to :(
For kubernetes unless you’re past a couple of million keys it’s unlikely etcd is the issue, and other things would fall over first. However, if you’re at those levels it might be worth it to use something else. I’m not sure foundation would be able to do the full consistent list required in the current model though (someone above mentioned full consistent table scans being not possible in FDB). In etcd and cockroach…
If you’re referring to my comment, by “not possible”, I meant “subject to the 5s transaction duration limit.” etcd and ZK could be implemented on top of FDB.
Re: FoundationDB Record Layer
#35Has anyone ever used FoundationDB and not found it successful? All I read is "it supports RDMS + NoSQL and can be distributed". So what use cases doesn't it solve?
Re: FoundationDB Record Layer
#36Has anyone ever used FoundationDB and not found it successful? All I read is "it supports RDMS + NoSQL and can be distributed". So what use cases doesn't it solve?
The best way I can describe FoundationDB is it is like a file system. You can do just about whatever you’d like with files and a file system, in theory. You can implement just about any data model you can dream up in FDB.
But the current storage engine is not as well optimized as it could be.
It does have scalability limits, although they’re not relevant for 99.9% of use cases.
Upgrading a cluster to a new non-patch version will require a small (seconds) amount of downtime. A mitigating factor there is upgrading your client doesn’t have that limit, which is where all the interesting stuff is.
The minimum latency for a transaction is relatively high compared to systems which acknowledge writes before syncing to disk or only after syncing to a single disk.
I wouldn't say it doesn’t solve “use cases”. Rather, if you can live within the limitations (which means you need to know what they are), you can reduce the complexity and cost of designing a system for your use case by a lot.
Check out my talk from the FDB Summit for an example: https://youtu.be/SKcF3HPnYqg
Re: FoundationDB Record Layer
#37The preprint of the paper is now up on arXiv.org: https://arxiv.org/abs/1901.04452
Re: FoundationDB Record Layer
#38Does that mean FDB now supports secondary indexes?
If that's the case, how does FDB compare to ScyllaDB now that they both have secondary indexes?
Re: FoundationDB Record Layer
#39Seeing this soon after the AWS “wire compatible with Mongo” kerfuffle, it makes me think: it would be amazing if the cloud vendors would offer a managed FDB service. An open-source, cloud-agnostic, horizontally scalable, document-oriented transactional database would be an incredible tool. I know AWS is going in the opposite direction these days with proprietary “wire compatible” services but a guy can dream...
Re: FoundationDB Record Layer
#40Does that mean FDB now supports secondary indexes? If that's the case, how does FDB compare to ScyllaDB now that they both have secondary indexes?
FDB does not automatically index your data, but you can write a layer (like this one) to index your data.
In a transaction, you write a key like “users/1” with a value of “bob” and then write another key like “users/bob/1” with no value. Then you can do a range scan over the prefix “users/bob/“ and find all the primary keys. After that you do individual gets for the keys in the PK index to retrieve the full record if needed.
The comparison between the two is FDB “secondary indexes” are just like anything else in FDB. Namely, you update them in transactions and they are consistent immediately. Scylla does not AFAIK have this feature.