Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FoundationDB Record Layer

foundationdb.org

Post reply on HN
Print view View original

21–30 of 85 posts

Re: FoundationDB Record Layer

#21

Post by ryanworl »

dman wrote: post #18
ryanworl wrote: post #13

Earlier quoted context omitted.

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?

* Schema evolution and schema management. Keeping schema state updated transactionally for a single, high-traffic table is complicated. An FDB core feature I requested could make this easier. Basically managing the lifecycle of adding, building, using, and dropping indexes is the hard part.

* Full table scans on large tables in a R/W transaction would fail due to the 5s transaction duration restriction. This is obviously a bad idea regardless of database, but if you wanted to support SQL you would have to allow it

* Sorting and joins require (theoretically) the same amount of memory as your data size, or the ability to spill to disk. This isn't FDB specific, but offering this kind of feature in a scale-out, high-concurrency model would be tough for QoS.

There are plenty more, but those are the big ones I ran across during design. The actual SQL interface part is not hard, but you would have to disallow many useful constructs people normally expect to work.

Re: FoundationDB Record Layer

#23

Post by PhilippGille »

lima wrote: post #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 :(

Is TiKV an alternative?

Short overview and maybe good to know it's becoming part of the CNCF: https//www.cncf.io/blog/2018/08/28/cncf-to-host-tikv-in-the-sandbox/

Haven't worked with it myself yet, but maybe others can share their experience?

There have also been some HN threads in the past, about TiDB at least.

Re: FoundationDB Record Layer

#24

Post by nschiefer »

rdsubhas wrote: post #11
nathan_long wrote: post #10

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?

(I'm from the iCloud team that works on the Record Layer.) Both building a relational database and implementing a proper SQL interface on top of it are huge projects. The SQL spec is large and complicated, so achieving true compatibility (as opposed to superficial compatibility) is challenging. Even worse, once you have a SQL interface users expect to be able to throw any SQL that they give to, say, Postgres, and have it work just as well, which requires a ton of detailed work on the query optimizer.

The client/server distinction isn't terribly strong in the FDB world. The FDB client is unusual in that it's a (stateless) part of the FDB cluster itself. You could therefore embed it in the client itself or build an RPC service around it. The Record Layer takes the same approach---it's just a Java library---so you could either embed it in the client application or build some kind of wire protocol for accessing it. One could have an embedded SQL layer like SQLite or H2 with no additional server beyond the cluster or a separate SQL layer network server that acted more like Postgres or MySQL.

The Record Layer was designed for use cases that don't need a SQL interface, so we focused on building the layer itself. That said, the Record Layer exposes a ton of extension points so there's a fluid boundary between what needs to live in its main codebase and what can be implemented on top. There are almost certainly enough extension points to implement a SQL interface as another layer on top of the Record Layer. For example, you could add totally new types of indexes outside of the Record Layer's codebase, if that were needed for SQL support. It's still a lot of work, especially on the query optimizer. Perhaps the community is up to that challenge. :-)

Re: FoundationDB Record Layer

#25

Post by techie128 »

ddorian43 wrote: post #14
_y4bi wrote: post #9

Earlier quoted context omitted.

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

"Probably async"? Could you expand on it?

Re: FoundationDB Record Layer

#26

Post by nemothekid »

mathnode wrote: post #17

Does anyone know if FoundationDB is gaining ground over Cassandra at Apple?

I recall a couple years ago that it was rumored that Apple had bought FDB with the intention of replacing Cassandra (and I think, at the time, Apple had the largest Cassandra cluster ever known).

Combined with other statements in this thread, I think that may be true. I remember reading once that iMessage used to be served by Cassandra, but now its served by FDB.

This is all speculation though.

Re: FoundationDB Record Layer

#27

Post by seidoger »

nemothekid wrote: post #26
mathnode wrote: post #17

Does anyone know if FoundationDB is gaining ground over Cassandra at Apple?

I recall a couple years ago that it was rumored that Apple had bought FDB with the intention of replacing Cassandra (and I think, at the time, Apple had the largest Cassandra cluster ever known). Combined with other statements in this thread, I think that may be true. I remember reading once that iMessage used to be served by Cassandra, but now its served by FDB. This is all speculation though.

The FDB Record Layer white paper [0], section 8.1, does open with:

> 8.1 New CloudKit Capabilities

> CloudKit was initially implemented using Cassandra as the underlying storage engine.

So it seems this is what happened, for CloudKit at least.

[0] https://www.foundationdb.org/files/record-layer-paper.pdf

Re: FoundationDB Record Layer

#28

Post by shereadsthenews »

wwilson wrote: 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…

I think foundation excites a lot of people who have never read its code or tried to operate it and therefore have only these statements of hype to go on.

Re: FoundationDB Record Layer

#29

Post by ryanworl »

shereadsthenews wrote: post #28
wwilson wrote: 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…

I think foundation excites a lot of people who have never read its code or tried to operate it and therefore have only these statements of hype to go on.

FoundationDB is about as honest and up-front about its limitations and flaws as any system I've ever seen.

Have you had a negative experience with it you can share?

Post reply on HN