Live data from Hacker News

FoundationDB Record Layer

foundationdb.org

11–20 of 85 posts

Re: FoundationDB Record Layer

#11
post #2

This is very cool! FoundationDB excites a lot of people because it's an extremely scalable and extremely reliable distributed database that supports ACID transactions, and which is both open-source and has Apple standing behind it. And yeah, all of that is pretty nice. But arguably the real power comes from the fact that it exposes a relatively low-level data model that can then be wrapped in one or more stateless "l…

This definitely sounds cool. > your SQL database They mention "a declarative query API", but as far as I can tell that's not actually SQL, right? So migrating from another relational db would require learning a new query language?

One could technically write an SQL translation layer on top of it, as a client-side library? Or does it need support on the server-side / record layer?

Re: FoundationDB Record Layer

#12
This 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 :(

Re: FoundationDB Record Layer

#13

Earlier quoted context omitted.

This definitely sounds cool. > your SQL database They mention "a declarative query API", but as far as I can tell that's not actually SQL, right? So migrating from another relational db would require learning a new query language?

One could technically write an SQL translation layer on top of it, as a client-side library? Or does it need support on the server-side / record layer?

It would be tough to implement every SQL construct on top of what is there today. I could explain why (I have tried and presumably ran into the same issues they did described in various areas in the docs and the paper), but the docs give an authoritative answer to save me typing :)

"In the future it is possible that the Record Layer may develop a formal query language, but it is unlikely that such a language would closely resemble the SQL standard." [0]

[0] https://foundationdb.github.io/fdb-record-layer/FAQ.html

Re: FoundationDB Record Layer

#14
post #9
post #7

Very 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?

Probably async

Re: FoundationDB Record Layer

#15
post #2

This is very cool! FoundationDB excites a lot of people because it's an extremely scalable and extremely reliable distributed database that supports ACID transactions, and which is both open-source and has Apple standing behind it. And yeah, all of that is pretty nice. But arguably the real power comes from the fact that it exposes a relatively low-level data model that can then be wrapped in one or more stateless "l…

Just wanted to say thanks for your testing distributed systems talk! That has been a huge help to me as I develop distributed systems and consider the problems inherent to them.

Is this the video you mention?

https://youtu.be/4fFDFbi3toc

Re: FoundationDB Record Layer

#16
I learned that basically all of Imessages and contacts are stored on foundation DB, it's pretty great this is making it into opensource. Thanks Apple!

Re: FoundationDB Record Layer

#18

Earlier quoted context omitted.

One could technically write an SQL translation layer on top of it, as a client-side library? Or does it need support on the server-side / record layer?

It would be tough to implement every SQL construct on top of what is there today. I could explain why (I have tried and presumably ran into the same issues they did described in various areas in the docs and the paper), but the docs give an authoritative answer to save me typing :) "In the future it is possible that the Record Layer may develop a formal query language, but it is unlikely that such a language would cl…

Could you briefly describe the challenges you ran into?

Re: FoundationDB Record Layer

#19
I had built a layer like this one for my startup Bagcheck called Havrobase[1] (it was on top of HBase/Solr, here is the motivating blog post[2]) that ultimately I put on top of MySQL/Solr and other stores. Later, when we started Wavefront, I ported that layer to FDB and that still powers their metadata. Really a good fit and very much like this record layer. I highly recommend this approach for 24/7 services as you never need to have maintainence windows for schema upgrades and the like.

[1] https://github.com/spullara/havrobase [2] https://javarants.com/havrobase-a-searchable-evolvable-entit...

Initially at Wavefront we were using HBase for telemetry, Zookeeper for the service mesh and MySQL Cluster for entity metadata. All that was moved on top of FDB with 3 different layers that we developed.

I'm excited that this kind of database is now going to be available more broadly and with the confidence that CloudKit is using the same technology since to date implementing something like this was basically a DIY project.

Re: FoundationDB Record Layer

#20
post #15

Earlier quoted context omitted.

Just wanted to say thanks for your testing distributed systems talk! That has been a huge help to me as I develop distributed systems and consider the problems inherent to them.

Is this the video you mention? https://youtu.be/4fFDFbi3toc

Yes it is! Sorry for not linking it and thank you for doing so!
Post reply on HN