391–400 of 453 posts
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.
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 th…
You can mitigate by designing your key structure/data ordering to not have that property.
The memory engine requires your data to fit in memory (total across all your nodes, after replication). It writes interleaved snapshots and updates to disk, and reads the whole dataset back into memory when restarted.
You can do great modeling of time series data in FDB, though it will take some care and thought.
You should ask these questions on the forum. This article is falling off HN, I am going to lose track of it, and it doesn't look like the Apple team is answering questions here.
Earlier quoted context omitted.
MongoDB is AGPL or proprietary. Many companies have a policy against using AGPL licensed code. So, if you work at one of those companies, then open source MongoDB is not an option (at least for work projects), and proprietary may not be either (depending on budget etc). FoundationDB is now licensed under Apache 2, which is a much more permissive license, so most companies' open source policies allow it.
Unless people want to change the mongodb code that they would be using, using the agpl software should be a non issue and there are not problems with it. People should start understanding the available licenses instead of spreading fear.
I know that multiple other companies have a similar policy (either a complete ban on using AGPL-licensed software, or special approval required to use it), although unlike Google, they don't post their internal policy publicly.
If someone works at one of these companies, what do you want to do – spend your day trying to argue to get the AGPL ban changed, or a special exception for your project; or do you just go with the non-AGPL alternative and get on with coding?
Earlier quoted context omitted.
This kind of deep-inside-baseball from-the-horses-mouth interaction is what's so awesome about HN!
> deep-inside-baseball from-the-horses-mouth Does the horse choke on the baseball? Is there an equine version of the Heimlich maneuver to be performed on horses suffering from mixed-metaphorical-adage-induced asphyxiation?
I hadn't heard of FoundationDB before, so I did some digging into the features: https://apple.github.io/foundationdb/features.html . It seems to claim ACID transactions with serializable isolation, but also says later on that it uses MVCC, slower clients won't slow down operations, and that it allows true interactive queries. I didn't think an MVCC implementation could provide that level of isolation, and I'm not eve…
I mean, PostgreSQL is MVCC and it clearly supports serializable as an isolation level... have you tried using Google? https://wiki.postgresql.org/wiki/Serializable
This then causes people who aren't versed with the product or the technology to decrease their perception of the product, and puts the team behind it in a position of having to not just come to its defense but to do so quickly due to the perception concerns.
Meanwhile, if they just do a basic search for "MVCC serializable" they would find that they were wrong; which means that it took more time to leave this insulting comment than it would have taken them to learn how this can work.
As a community, we really really really really need to beat down on casual cynics like this, who like to lazily "call bullshit" or play the "citation needed" card as a way to undermine the credibilty of other peoples' products. We live in a future where the answers to these kinds of doubts are a moment away: this particular form of debate tactic needs to die.
It’s neat although there is no sql front end. Bloomberg’s comdb2 was open sourced recently https://github.com/bloomberg/comdb2 - it seems similar, but would be interesting to see comparison.
comdb2 is not a big data db per say. it compares more to mysql than foundationdb https://blog.dripstat.com/first-look-at-bloombergs-amazing-c...
Earlier quoted context omitted.
In some distributed databases the client just connects to some machine in the cluster and tells it what it wants to do. You pay the extra latency as it redirects these requests where they should go. In FDB's envisioned architecture, the "client" is usually a (stateless, higher layer) database node itself! So the client encompasses the first layer of distributed database technology, connects directly to services throu…
> but you had better have a good async RPC system! The microservices crew with their "our database is behind a REST/Thrift/gRPC/FizzBuzzWhatnot microservice" pattern is still catching up to the significance of this statement.
Earlier quoted context omitted.
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)
Yes :) it's the core of how Wavefront stores telemetry.
Earlier quoted context omitted.
Until recently, no. But apparently they got serious about making it work and now it actually does. See https://jepsen.io/analyses/mongodb-3-4-0-rc3 for verification. I realized this 2 months ago at https://news.ycombinator.com/item?id=16386129
That's Nostradamus-level crazytown. What next, PHP strongly enforcing a sound static type system with immutable defaults, GADTs and dependent types? Congrats to the MongoDB team!
Too funny!
Never heard about fdb but the concept is very intriguing. We know many nosql db on top kv store rocksdb or level db (like dgraph before moving to new storage engine). That it still needs more to write until it can be called distributed and scalable. By using foundation db we can skip many parts and focus on other part like query language and API. That's why I like the layer concept, unfortunately the is very little d…