FoundationDB uncloaks ACID-compliant NoSQL beta Skeptical developers can now get their hands on a NoSQL database that supports ACID-compliant transactions, a handy tech for web applications that expect their usage to take off like a rocket. A beta version of the FoundationDB NoSQL database became available for download on Monday. It differs from other NoSQL systems in that …
You've been able to have Enterprise grade high availability and ACID compliant transactions (and not just at the limited single document level, like some) on a NoSQL database in MarkLogic for the last 10 years. Do you think the average Enterprise will trust FoundationDB, Mongo et al on live, business critical applications without serious built in features like ACID transactions, HA/DR and Roles Based Access Control (RBAC)? Of course not. Also, putting data in is one thing, how to provide sophisticated querying over it is quite another, and that is what you need on a very large data set. MarkLogic can provide database, search and app server in a single install, over a cluster of nodes, in a single binary. No contest when compared to these 'science project' implementations.
The article quotes some guy called Bradford Stevens as saying developers don't care about ACID. I dunno, maybe if they are a bunch of NCGs who've never had to maintain code over any period of time (and there are a lot of companies in silicon valley where that describes the entire engineering staff). But for the rest of us, not needing to have special case checks to recover when your operation only partially succeeds (atomicity), not worrying about the impact of other storage clients when accessing the store (consistency and isolation), and being damn sure that your data makes it to disk (durability) is hugely important.
Let's suppose you do a typical startup half-ass approach to development and you tolerate lots of weird partial transactions because hey, you're not operating on credit card data. At some point, some pointy haired person is going to get the brilliant idea that there's gold in them there logs. Now you're going to need to build some sort of ETL flow to get that data into a nice, easily queriable form. And then you're going to find that you need shit-tons of special case logic to coerce all those different botched transactions, each of which is going to take significant time to detect, track down, and support.
But hey, by that time your NCGs will probably have moved on to other, shinier, newer, pursuits. So maybe they don't care after all.
I wouldn't call that a rant, NickLavezzo, whenever it provides so much invaluable instruction for successful master pilot missions.
Imagine you operate a web application in which users both generate posts and receive posts from other users. All posts are maintained in a back-end database. Management has asked you to build a dashboard for doing some basic analytics. Although your data store is read-write, the dashboard is initially intended to perform read-only queries. The data is just for analysis, so if results are sometimes a bit out-of-date, nobody will notice in the UI. Overall, you see no need for transactions. You put together some great data visualizations that allow your company to analyze and view posts in new ways.On the up side, the dashboard proves very popular. On the down side, you start hearing demands for new features: users want the dashboard to support editing and moderation of the posts found using the analytics. Also, the ad-serving division wants access to the dashboard data via an API to drive their billing system. You now have a situation where the simple read-only model of the dashboard has gone out the window, and your new API needs to be able to provide strong guarantees about the results it is delivering.
This sort of evolution of requirements is a natural and frequently occurring pattern. Transactions make the difference between being able to easily add these features and throwing out large parts of your code and starting over. … FoundationDB … The Transaction Manifesto
Those three paragraphs describe quite admirably that which is provided by the Register and its commentards, for the Register and its commentards, some/many of whom are off the scale smart and therefore able to be extremely disruptive and constructive ….. and even catastrophically destructive too if there be serious personal issues in need of addressing and/or redress ….. or one is just plain evil and stupid when decidedly so, or by malignant intelligence design, for such utility will always generate a competitive and expanding and increasingly more powerful opposition rather than effortlessly delivering an overwhelmingly further sighted, leading progress and a singular absolute superiority in all fields of physical endeavour and virtual enterprise.
Nice concise white paper, btw, FoundationDB. A quite perfect enough descriptor with operands for New Orderly Worlds and New World Order freaks …… Real Virtual Power Elites? But then ACID always has demonstrated that power to open up new fields to and with fab players since ever it arrived on the scene and changed everything in an instant.
Yes, this article was pretty close to content-free. The earlier piece the Reg did on Google Spanner at least had some technical details - enough to figure out how Spanner restores consistency after partitions are reunited. FoundationDB is likely doing something very similar, but waffling on about a magical programming language which "the machines in a cluster use to talk to one another to perform transaction processing and conflict resolution" is not informative.
And, seriously, "net-orientated applications"?!! Why not "net-orientationalizificated", while we're at it? And what is a "net-oriented application" anyway? One that processes HTTP requests, apparently. Gosh, that's a useful discriminator.
Binary download only. Licence agreement to sign.
Website says "FoundationDB Beta 1 is ready for production use" but licence says "for test purposes only in a non-production environment and solely for your internal business purposes to evaluate the functionality of the Software."
Presumably a production licence exists - it just doesn't say how to get one or how much it costs.
Even Oracle/Mysql is more transparent than this.
The FAQ says that only the APIs and outer layers will be open source, but later talks about a free "community edition". So I enquired as to what this meant.
They confirmed that the core will remain closed-source.
"Community edition" means that it is free for developers to build their applications with - not that the database itself is open to code contributions from the community.
What we're trying to do here is not even build a database per se, we're tring to build a transactional storage substrate that can then be used to expose a variety of different data models," FoundationDB cofounder David Rosenthal told The Register.
That sounds like a zeroday vulnerability exploiting engine with smarter driver input to output capabilities, DR. A real spooky virtual weapon which has no present day defence systems to attack and/or thwart its pumping of info and novel intel.
Be proficient in attractive product generation with that, and everyone and everything will react to supply provided/sweet sticky tales delivered uncovered, raw and naked. But it is a very competitive field and unless one is at least a thoroughbred, will one always be recognised as the donkey and/or drey in the field that one is then.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
