Live data from Hacker News

Apple open-sources FoundationDB

foundationdb.org

311–320 of 453 posts

Re: Apple open-sources FoundationDB

#311

Earlier quoted context omitted.

If I recall correctly, the "SQL layer" you had in FDB before the Apple acquisition was a nice proof of concept, but lacked support for many features (joins in SELECT, for example). Is the SQL layer code from that time available anywhere to the public? (I'm not seeing it in the repo announced by OP.)

Perhaps it's this? https://github.com/jaytaylor/sql-layer

That has FoundationDB dependencies that don’t exist in the apple repo (SQL Parser, JDBC Driver, etc)

Re: Apple open-sources FoundationDB

#312

Earlier quoted context omitted.

And there we go...

I don’t see FreeBSD listed.

It's probably similar to GRPC just changing the compiler over to Clang in the Makefile like so: https://github.com/wolfspider/grpc-freebsd-examples/blob/mas...

Maybe these two would go good together? ;)

Re: Apple open-sources FoundationDB

#313

Earlier quoted context omitted.

What if the number of boxes are even? Or do you get around this by not deploying an uneven number of boxes?

This makes me wonder also what happens with multiple partitions, for example: 5 into 2, 2, and 1 7 into 3, 2, and 2

No majorities, I guess?

Re: Apple open-sources FoundationDB

#314

Earlier quoted context omitted.

I agree with voidmain’s comment as secondary indexes shouldn’t be any different than the primary KV in your case. Almost seems that you’re focusing on a SQL/Relational database architecture but storing your data demoralized anyways. Odd combination of thoughts.

I love the idea of demoralized data :)

Is that where the data sits around waiting, eager, to be queried into action while watching data around them being used over and over again.... But that time never comes, thus leaving them to question their very worth?

Re: Apple open-sources FoundationDB

#315
post #90

These days most people know Hadoop for a distributed storage. In my opinion, though CEPH [1] has the bigger potential. [1] https://ceph.com/

There are several distributed storage systems like Ceph and they all have problems. Ceph is not good because it's an object storage system trying to provide block storage and a filesystem on top, which will never work well.

Absolutely right - I wrote an object storage backed filesystem for Hadoop and synchronizing was a complete nightmare.

It certainly worked well within our required architecture - but as a general purpose system it would have several issues over typical network topologies.

As active volume size increases and/or changes, the object storage layer latency can bump up to minutes, or even hours. We stopped tested at 100TB volumes, as the object storage layer was backed up to hours.

Object Storage is very convenient, but the lack of good metadata and latencies involved basically means that it's only good as an archival backing store of active data. If your active datasource goes out - you could lose hours of data unless you have local copies.

Re: Apple open-sources FoundationDB

#316
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…

I echo what wwilson has said. I work at Snowflake Computing, we're a SQL analytics database in the cloud, and we have been using FoundationDB as our metadata store for over 4 years. It is a truly awesome product and has proven to be rock-solid over this time. It is a core piece in our architecture, and is heavily used by all our services. Some of the layers that wwilson is talking about, we've built them. metadata st…

That's impressive! Are you going to contribute your changes to foundationdb back?

Re: Apple open-sources FoundationDB

#317

Earlier quoted context omitted.

Thanks for the downvote. My question still remains.

Didn't downvote you, but I believe the excitement is over FoundationDB's ability to perform ACID compliant distributed transactions without sacrificing performance -which to my knowledge no current RDBMS or even NoSql can do.

> no current RDBMS can do

https://cloud.google.com/spanner/ ?

Re: Apple open-sources FoundationDB

#318
I am not a database expert by any means but have been curious about distributed data systems and had not heard of FoundationDB till now and was very excited to read about it. On reading through the documentation, I encountered a section on "Known Limitations"[1] which stated that keys could not be larger than 10kb and values cannot be larger than 100kb. This seems to be a major limitation. Am I missing something or is this strictly for storing text?

[1] https://apple.github.io/foundationdb/known-limitations.html#...

Re: Apple open-sources FoundationDB

#319
post #4
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…

Will said what I wanted to say, but: me too. I'm super happy about this and grateful to the team that made it happen! (I was one of the co-founders of FoundationDB-the-company and was the architect of the product for a long time. Now that it's open source, I can rejoin the community!)

Nice to see you are joining back!
Post reply on HN