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

FoundationDB: A distributed, unbundled, transactional key value store [pdf]

foundationdb.org

Post reply on HN
Print view View original

51–60 of 103 posts

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#51

Post by [deleted] »

gregwebs wrote: post #33
rubyn00bie wrote: post #21

Here's one of my favorite articles on FoundationDB, where it (FDB) passes Jepsen first try: https://web.archive.org/web/20150312112556/http://blog.found... > I ran FoundationDB Key-Value Store through every nemesis in Jepsen - including those that found failures in other databases - and FoundationDB passed all of them with flying colors. FoundationDB is one of the coolest pieces of technology I've used in the past de…

That's great that you are doing your own resiliency testing. Having someone other than those officially on the Jepsen project run the Jepsen test is a good start. However, many databases have claimed to run the Jepsen tests themselves and pass, but when there is an actual paid engagement for a distributed database there are always issues that are found. That's generally true even for unpaid official runs as well alth…

[deleted]

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#52

Post by eloff »

cwp wrote: post #49
eloff wrote: post #42

Earlier quoted context omitted.

Those are two completely non overlapping use cases. If you can use pgsql for your problem, you have no business trying to use a distributed key value store instead. That would be at least as dumb as driving screws with a hammer.

Yeah, but there are quite a few efforts out there to extend PG into a distributed DB of one flavor or another. Some examples are YugabyteDB, CockroachDB, Aurora and Citus. It's a reasonable approach, but it's also reasonable to come at it from the other direction - build a SQL engine on top of a solid distributed key-value store. Contrafactuals are always dicey, but FDB vanishing behind the Apple wall of silence sure…

> Some examples are YugabyteDB, CockroachDB, Aurora and Citus.

Of those the first two are not PG, they just share the wire protocol and try to be compatible at a SQL level. Aurora is not really distributed, it's replicated for availability and durability six ways at the block storage level. Citus is distributed as I understand it though.

> but it's also reasonable to come at it from the other direction - build a SQL engine on top of a solid distributed key-value store.

Sure, that's possible. I'm not talking about the wisdom of building your own relational database as the end goal, just that a distributed key value database and a SQL database don't have overlapping problem sets.

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#53

Post by maxmcd »

kendallgclark wrote: post #39
georgelyon wrote: post #4

FDB is an awesome and unique piece of software (I attribute quite a bit of Snowflake's success to FDB). I've also had the pleasure of meeting some folks from the original team and they are true engineers. Does anyone know if/when Redwood (the new storage engine) has landed / will land?

Founders are building a distributed systems simulation product now called Antithesis. My data fabric startup, Stardog, is a happy Antithesis early adopter customer. It’s helping us reproduce and fix non-deterministic bugs deterministically. Good stuff.

Fascinating: https://antithesis.com/

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#54

Post by jng »

jFriedensreich wrote: post #47
agency wrote: post #43

Earlier quoted context omitted.

I’m curious about this as well. Is anyone working on building text search on top of FDB? It’s kind of astounding to me that last time I checked Elasticsearch was still essentially the only game in town.

its pretty hard to catch up with lucene, there is just so much work, features and brainpower in there at this point. as many features of foundationdb such as the transaction guarantees and reliability are not super important for fulltext search i cannot imagine any company even apple or ibm being able to justify that gigantic investment, instead im sure nearly any soluion willcontinue to use lucene under the hood for…

Lucene is Java, right? There should be space for a native implementation, like ScyllaDB is doing to Cassandra (and DynamoDB, though the gap is not of the same shape in the last case). Or am I missing something?

I used ElasticSearch and run one cluster in production in the past and found it horrible. Maybe I'm missing something, since they're so successful even as a public company...

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#55

Post by adamfeldman »

jwr wrote: post #36

I just implemented a database with changefeeds using FoundationDB (in Clojure), to eventually replace RethinkDB in my system. Very impressed so far.

That’s awesome! I’m interested specifically in using FDB with Clojure.

Did you look at Crux as well? (DB written in Clojure, has primitives to build changefeeds, opencrux.com).

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#56

Post by cwp »

eloff wrote: post #52
cwp wrote: post #49

Earlier quoted context omitted.

Yeah, but there are quite a few efforts out there to extend PG into a distributed DB of one flavor or another. Some examples are YugabyteDB, CockroachDB, Aurora and Citus. It's a reasonable approach, but it's also reasonable to come at it from the other direction - build a SQL engine on top of a solid distributed key-value store. Contrafactuals are always dicey, but FDB vanishing behind the Apple wall of silence sure…

> Some examples are YugabyteDB, CockroachDB, Aurora and Citus. Of those the first two are not PG, they just share the wire protocol and try to be compatible at a SQL level. Aurora is not really distributed, it's replicated for availability and durability six ways at the block storage level. Citus is distributed as I understand it though. > but it's also reasonable to come at it from the other direction - build a SQL…

Sure quibble about the details. The point is, these are all attempts to make PG more scalable. Around the time these projects got started Foundation looked like abandonware. If it hadn't, it's possible that "how can we have really scalable SQL databases?" might have had Foundation as part of the answer.

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#57

Post by mirker »

jFriedensreich wrote: post #46
e12e wrote: post #17

This seems like a good place to ask - are there any new and exiting FOSS "application" worth checking out? I recall from the initial publication of the source - there was references to a great sql layer? I don't know if a FOSS work-a-like ever materialized? Other things I'd hoped for was a network filesystem/blob layer, like maybe s3/nfs/webdavfs compatible? What are people building on top of foundationdb today? Ed:…

large unstructured blobs and large files are among the things not well suited to foundationdb and couchdb 4 actually reduced supported blob size in the transition to foundationdb. it looks like object/blob storage systems are at the moment rather seperating more from key/value and document storage than growing together. but this is a good thing because the tradeoffs are very different and it allows each system to foc…

Can you elaborate on what requirements these blob systems should have?

My understanding is object stores are typically “flat” by design to scale well (in contrast to a tree structure found in filenames).

For content addressing, are people using the keys in sophisticated ways or are the values being indexed? Any reason to push this complexity into the storage layer as opposed to composing the functionality?

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#58

Post by sigstoat »

vvern wrote: post #50
sigstoat wrote: post #18

Earlier quoted context omitted.

this is limited by your creativity and willingness to make tradeoffs. the only really general statement i can think of is that the "larger"/"longer" your transactions are, the harder a time you'll have getting it to cooperate with FDB. "small"/"fast" transactions will be easier to fit into its model. (to likely replies: this isn't an absolute, see all the quotes. yes things like redwood will alleviate some of this, b…

IIRC fdb is fully optimistic concurrency control. It doesn't do any locking. If you have workloads which are highly contended, you'll need to do something in the layer above to coordinate. Otherwise, performance will be unbearable. This may be out-dated, please let me know if the story has evolved here.

if your transactions are conflicting heavily with each other, yeah, you'll have a bad time. and if everything synchronizes on some small set of keys, you'll have a really bad time. monitoring the transaction conflict rate on your cluster is important.

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#59

Post by vosper »

jng wrote: post #54
jFriedensreich wrote: post #47

Earlier quoted context omitted.

its pretty hard to catch up with lucene, there is just so much work, features and brainpower in there at this point. as many features of foundationdb such as the transaction guarantees and reliability are not super important for fulltext search i cannot imagine any company even apple or ibm being able to justify that gigantic investment, instead im sure nearly any soluion willcontinue to use lucene under the hood for…

Lucene is Java, right? There should be space for a native implementation, like ScyllaDB is doing to Cassandra (and DynamoDB, though the gap is not of the same shape in the last case). Or am I missing something? I used ElasticSearch and run one cluster in production in the past and found it horrible. Maybe I'm missing something, since they're so successful even as a public company...

There’s a lot to Lucene, and there’s also a lot to ElasticSearch. And I think they’re fairly tightly coupled.

But I do think that a well-funded and skilled startup team could take a run at ES. They’re a monopoly in their niche. There has to be money in disrupting them.

Re: FoundationDB: A distributed, unbundled, transactional key value store [pdf]

#60

Post by maxpert »

monstrado wrote: post #34

Have nothing but praise for FoundationDB. It has been by far the most rock solid distributed database I have ever had the pleasure of using. I used to manage HBase clusters, and the fact that I have never once had to worry about manually splitting "regions" is such a boon for administration...let alone JVM GC tuning. We run several FDB clusters using 3-DC replication and have never once lost data. I remember when we…

How would it compare to say something like hosted Redis, or if you wanna be more fancy ElasticSearch. I have been looking into FDB for pretty long time and have been looking for a perfect opportunity to use it. Would be helpful if you can describe your usage scenario (kind of data you are storing).
Post reply on HN