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

51–60 of 85 posts

Re: FoundationDB Record Layer

#51

Post by Nullabillity »

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…

> and has Apple standing behind it.

So far behind it that they already shut it down once.

Re: FoundationDB Record Layer

#52

Post by [deleted] »

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.

[deleted]

Re: FoundationDB Record Layer

#53

Post by ta7756 »

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.

Apple's Cassandra footprint has grown to over 100 PB (https://twitter.com/jjirsa/status/1071357976454316033)

Re: FoundationDB Record Layer

#55

Post by SloopJon »

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…

Do I understand correctly that the record layer is only usable by Java clients? That strikes me as a drawback of the layer approach: unless you supply a server protocol, like the document layer does, every language essentially reimplements the layer from scratch. That seems to be the case for the tuple layer, for example.

Re: FoundationDB Record Layer

#56

Post by ddorian43 »

techie128 wrote: post #25
ddorian43 wrote: post #14

Earlier quoted context omitted.

Probably async

"Probably async"? Could you expand on it?

To achieve "availability", cassandra lowers consistency, making dev's life extremely hard.

Long: https://docs.yugabyte.com/latest/comparisons/cassandra/

TLDR: google/fb/etc went the other way, using hbase,bigtable witch are strongly consistent.

Re: FoundationDB Record Layer

#57

Post by c4pt0r »

PhilippGille wrote: post #23
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.

TiDB developer here. Yes, I think TiKV is an alternative to FDB. Compare to FDB Record Layer, TiKV aims to provide a more atomic primitive, just including Get/Set/Transaction in key-value layer, so users can build customized distributed system around it. The main differences between TiKV/TiDB and FDB are:

1. TiKV uses Multi-Raft architecture, I think Raft provides more HA.

2. TiKV's transaction model is inspired by Google Percolator, it's a classical optimistic 2PC transaction model with MVCC support. I'm not a expert of FDB, but I think different transaction models fit for different application scenarios, TiKV's transaction model is good when your workload is mainly small transactions and with a low conflict rate.

3. TiDB is a full-featured SQL layer on top of TiKV, aims to provide a MySQL compatible solution, you know, most of the TiDB users are migrated from the MySQL, so the focus of TiDB will be how to be compatible with these legacy MySQL-based applications. For example, how to read MySQL binlog and then replay on TiDB in real time, let TiDB become a MySQL active replica, or how to support complex SQL queries like distributed join or groupby, you know, building a full-featured SQL optimizer is a huge project.

There are some case studies:

https://pingcap.com/success-stories/

https://pingcap.com/success-stories/tidb-in-meituan-dianping...

There are some quick-start documents you can start with:

https://pingcap.com/docs/op-guide/docker-compose/

https://pingcap.com/docs/v2.0/op-guide/migration/#migrate-da...

Re: FoundationDB Record Layer

#58

Post by aseipp »

jwr wrote: post #33
_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?

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…

FoundationDB does not support true geo-replicated multi-region distribution the way Cassandra, Spanner, Cockroach, etc do, at least not without paying huge latency/round trip costs. If you want to avoid that, the best you can have is a separate failover region, and, with FoundationDB 6, you can get closer-to-LAN latencies for failover deployments to separate regions (but only one region) while retaining ACID semantics. You could build truly global geo-distribution on top of it but that would have to be its own layer that implements 2PC/Paxos or something between regions. Ultimately you have to pay the toll somewhere in a truly consistent system like that if you want global availability (unless you're Spanner and have incredible hardware engineering that can be deployed across the globe).

Cassandra/Scylla are the only open source key value stores that do linear scalability by simply adding nodes even in huge, geo-distributed settings as far as I know, but they are ultimately AP systems. And Scylla just has absurd performance compared to Cassandra or FoundationDB. You just have to know what you're getting into. (But yes, ACID transactions are a good model for developers, and truly FDB's linearizable transactions and high scalability make it an obvious choice many CP systems, if you ask me.)

Re: FoundationDB Record Layer

#59

Post by Birch-san »

mbesto wrote: post #35

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

Even with the Record layer, it doesn't have support for JOINs in the same way as an RDBMS would.

Yes, the Record Layer helps you define and index into _hierarchies_ of entities, but I suspect it doesn't have an answer for other access patterns (e.g. producing "report" views that relate or aggregate non-hierarchical data).

You could retroactively construct a custom view _after the fact_, but only if you can do so within 5 seconds. And (if you want continued access to that view) you'll need to ensure that that view is maintained thereafter (you would have to define your own layer -- it cannot be entrusted to application logic unless you can atomically switch to a new version of your stack). Maintaining such a view is made more difficult if your data allows updates/deletes.

The same caveat affects schema migrations. You would need to be able to fit the migration into a 5 second transaction (or tell your applications to stop modifying the data for a while, and handle it as a series of smaller transactions).

My assessment is that if you have (non-hierarchical) relational use-cases at scale, FDB really requires you to plan your access patterns from day 1. Whereas a typical RDBMS fares far better at satisfying emergent needs. That said: FDB's model is brilliant for document store and key-value use-cases.

Re: FoundationDB Record Layer

#60

Post by Artemis2 »

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 :(

DynamoDB with strong consistency turned on works pretty nicely for us.
Post reply on HN