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

Apple open-sources FoundationDB

foundationdb.org

Post reply on HN
Print view View original

371–380 of 453 posts

Re: Apple open-sources FoundationDB

#371

Post by wenc »

catwell wrote: post #342
wwilson wrote: post #2

This is INCREDIBLE news! FoundationDB is the greatest piece of software I’ve ever worked on or used, and an amazing primitive for anybody who’s building distributed systems. The short version is that FDB is a massively scalable and fast transactional distributed database with some of the best testing and fault-tolerance on earth[1]. It’s in widespread production use at Apple and several other major companies. But the…

> In fact, our everyday testing was way more brutal than Jepsen, I gave a talk about it here: https://www.youtube.com/watch?v=4fFDFbi3toc Unrelated to the original topic, but I had never come across that talk and it is great. I use the same basic approach to testing distributed systems (simulating all non-deterministic I/O operations) and that talk is a very good introduction to the principle.

In reinforcement learning, the same approach (simulation) to addressing a data deficit is used, although the goal there is learning and not testing.

When certain events happen rarely, you have fake them deterministically so that you have reproducible coverage.

Re: Apple open-sources FoundationDB

#372

Post by wenc »

KyleBrandt wrote: post #230
wwilson wrote: post #2

This is INCREDIBLE news! FoundationDB is the greatest piece of software I’ve ever worked on or used, and an amazing primitive for anybody who’s building distributed systems. The short version is that FDB is a massively scalable and fast transactional distributed database with some of the best testing and fault-tolerance on earth[1]. It’s in widespread production use at Apple and several other major companies. But the…

Know of any ideas around using this for long term Time Series data? Wonder if maybe something like OpenTSDB but with this as backend instead of hbase (which can be a sort of operational hell)

Not quite the same but TimescaleDB is Postgres-based and is showing a lot of promise for time-series data.

Re: Apple open-sources FoundationDB

#373

Post by polskibus »

Is foundationdb capable of providing a linearizable data store? As I remember from Martin Kleppman's books Serializable Snapshot Isolation is not linearizable because the snapshot does not include writes more recent than itself.

Re: Apple open-sources FoundationDB

#374

Post by noahdesu »

manigandham wrote: post #350
catwell wrote: post #348

Earlier quoted context omitted.

> Block level is the lowest form of addressing bytes on devices. Filesystems are an abstraction on top of block devices. Object stores are an abstraction on filesystems. I don't agree with this, but I think you may be confused because "Object Storage" can mean several different things. "Object Store" in Ceph (as in RADOS - Reliable Autonomous Distributed Object Store) basically means key-value store. I typically say…

Sure, and key/value systems are at the similar level of object stores, meaning they are abstractions on filesystems (which are abstractions on block devices). This is the hierarchy. Using Ceph for block and file access is like using AWS S3 to emulate block devices and filesystems. It'll work, and there is software for it, but it will never be very good. And Ceph is far from S3.

> It'll work, and there is software for it, but it will never be very good

What are some examples of distributed file systems and block devices that _are_ very good?

Re: Apple open-sources FoundationDB

#375

Post by dangets »

boubiyeah wrote: post #139
PeCaN wrote: post #109

Earlier quoted context omitted.

Honest question, does MongoDB work?

MongoDB is pretty average at absolutely everything. It's fast to install on a dev machine though, lol.

For better or worse, many times UX is more important than functionality.

Re: Apple open-sources FoundationDB

#376

Post by aeorgnoieang »

chx wrote: post #159
wwilson wrote: post #105

Earlier quoted context omitted.

It doesn't look like Apple open-sourced the Document Layer, which is a slight bummer. But I echo what Dave said below: what we got is incredible, let's not get greedy! Also TBH now that I don't have commercial reasons to push interop, if I write another document database on top of FDB, I doubt I'd make it Mongo compatible. That API is gnarly.

> That API is gnarly. Out of the many MongoDB criticisms, this one is valid. This https://www.linkedin.com/pulse/mongodb-frankenstein-monster-... article is quite right about it (note: endorsing the article does not mean I endorse its author by far). Other than that, they totally did a fake it until you make it with MongoDB 3.4 passing Jepsen a year ago and MongoDB BI 2.0 containing their own SQL engine instead of wr…

What specifically are you trying to avoid endorsing about the author of the LinkedIn post to which you linked? I couldn't find anything from a cursory web search.

Re: Apple open-sources FoundationDB

#377

Post by eropple »

wll wrote: post #335
throwaway84742 wrote: post #291

Earlier quoted context omitted.

What do you mean by “forms”? Spanner is also layered. The bottom layer is basically a key-value store. On top of that there’s a full blown SQL layer, which, BTW can work with hierarchical records as well as flat tables. Both support transactions and guarantee global consistency.

They may refer to FoundationDB layers. [1] While Spanner may be built on a key-value store equivalent, Google does not expose it as a service. [1] https://apple.github.io/foundationdb/layer-concept.html

That's exactly what I was referring to. Thanks.

Re: Apple open-sources FoundationDB

#379

Post by oconnor663 »

pluma wrote: post #346
nlavezzo wrote: post #92

Earlier quoted context omitted.

FoundationDB at its core is not a graph database. You could build a graph database on top of it, using FoundationDB as a very strong and feature rich storage engine, however you'd like. It would be much simpler to do than building a new (especially a distributed) graph database from scratch.

So FDB's role is more comparable to that of, say, RocksDB or LevelDB than an application-level database like Postgres? I didn't really pay much attention to Foundation before Apple bought them and am unsure how it fits in the wider database ecosystem.

Yes, but with an important caveat: Getting ACID transactions to work correctly across multiple machines is the really hard part. FDB is providing a KV store (across multiple machines) kind of like RocksDB does (on one machine), but it's also solving that really hard problem for you. That puts it in kind of a different league.

Re: Apple open-sources FoundationDB

#380

Post by kindkid »

Very cool.

I noticed that all the write benchmarks in https://apple.github.io/foundationdb/benchmarking.html are for random writes. Is write throughput affected by highly-sequential writes (e.g. - time series) vs random writes? How do you avoid hot-spotting on recent ranges?

How efficient are range deletes?

On https://apple.github.io/foundationdb/performance.html I read "The memory engine is optimized for datasets that entirely fit in memory, with secondary storage used for durable writes but not reads." I'd like some clarification:

(1) Which memory does "entirely fit in memory" refer to? A single machine? Or SingleNodeMemory * Nodes / ReplicationFactor?

(2) If only recently-written data is likely to be queried, and all recently-written data fits entirely in memory, is that sufficient? If so, would an unexpected query of old data cause a huge impact on write throughput?

(3) What is the structure/format of the data stored on disk? How is it updated?

I'm wondering how well this could be used for time series data. I saw mention here that wavefront uses FoundationDB for this, but would like more details if any are available.

Post reply on HN