I don't know what it means right now, but in the near future it will mean that Apple invented modern Databases.
Last edited by a moderator:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Acquires 'Rock-Solid High-Performance' Database Company FoundationDB
- Thread starter MacRumors
- Start date
- Sort by reaction score
All this talk of iOS makes no sense. It's a nosql clusterable ACID database that has no problems with data coherency. Why would you want this on an iOS device?
This is a server side solution that's like BobW for sql/nosql. I wish I had heard about it before the acquisition, because now it's unavailable. I'd rather have used this than hacking together a mongo/redis distributed cluster, which is what I'm doing now.
This could allow Apple to actually scale out iCloud. It must have gone through one heck of an evaluation for Apple to decide that it was worth it to absorb, which is a bummer. Anything that makes scaling out coherently easier would be a benefit to everyone doing anything distributed.
This is a server side solution that's like BobW for sql/nosql. I wish I had heard about it before the acquisition, because now it's unavailable. I'd rather have used this than hacking together a mongo/redis distributed cluster, which is what I'm doing now.
This could allow Apple to actually scale out iCloud. It must have gone through one heck of an evaluation for Apple to decide that it was worth it to absorb, which is a bummer. Anything that makes scaling out coherently easier would be a benefit to everyone doing anything distributed.
Apple apparently felt for their needs it had to be a database that supports ACID transactions. Mongo might be a great database, but there are some things that it just should never be used for.
Totally a dick move on both FoundationDB's side and Apple's. They acquired TestFlight and left it online for nearly a year yet have already shunted all of FoundationDB's downloads and open source repos.
I hope to god paying customers using it in production have SLA's that will be maintained for at least a migration period. Those poor DB admins will be stressing for months to come.
I hope to god paying customers using it in production have SLA's that will be maintained for at least a migration period. Those poor DB admins will be stressing for months to come.
Same here, I could've saved much headaches if I heard about FoundationDB prior. Instead of creating Frankenstein SQL+NoSQL solutions to overcome Mongo's deficiencies. I feel your pain, lol.
@ no sense ... part of the difficulty is perceiving FoundationDB one way. Granted, I personally wouldn't want it in iOS as Core Data is sufficient. However, AppleSauce007 is correct in that many developers have complained about the limitations of Core Data and / or SQLite. In time I have seen it as a pain point for many learning developers. But I think those developers were just thinking inappropriately (wanting SQL, storing binary data in an SQLite store, or using nested contexts in UI blocking situations). And approaching a mobile space with non-mobile or antiquated thinking is inherently flawed.
FoundationDB's clustering is not really applicable to iOS, so that is irrelevant.
Such doesn't diminish the fact that FoundationDB addresses other issues (it is key-value, but also has an SQL layer that Core Data lacks and that is faster than SQLite, while handling JSON data becomes trivial and retaining Core Data's atomic transactions). Granted, it also creates new limitations (that I'm sure developers will complain about also), lol. Ultimately, I think it only makes sense if Apple is streamlining the disparaging iOS data logic with a single solution (because tacking on FoundationDB would be asinine).
Considering their desire to optimize iOS, it makes sense.
So, not using clustering isn't a waste. Ironically, there are valid ways that they could use clustering in a multi-core system with things in memory while other things are in less volatile storage. But that's unnecessary / overkill for a database that even without clustering is already faster than SQLite. -- Regardless, I'm actually with you on Big Data. I don't think iOS is really a concern for FoundationDB despite that I can see the merits. I think iOS would receive it by consequence at best.
We'll see when they release the optimized iOS, if they announce that Core Data is better than ever, we'll know what happened, lol.
I'm a bit confused. As almost everything you said was already addressed in my quote that you're replying to, "But I understand their need for fully Atomic operations." -- The "but" indicates that it is in contrast to what was said prior, and the sentence discloses that I understand Apple's need for full Atomicity which Mongo lacks (the lacking is indicated through "but"). And that indicates that there are things Mongo isn't appropriate for.
Basically you in essence rephrased to me, what I already conveyed.
Why are some people acting like this article is written in another language? I mean, it isn't that hard to guess what nanodollars are if you have some kind of mathematical knowledge...
Looking forward to what Apple will do with this but like other buys we won't really notice what comes from what purchase.
Looking forward to what Apple will do with this but like other buys we won't really notice what comes from what purchase.
jargon
I suspect the writer did not understand them. This article is little more than an assemblage of snippets from other sources.
One thing he did write, however, is not correct. Apple did not confirm, they merely responded with their standard reply.
I suspect the writer did not understand them. This article is little more than an assemblage of snippets from other sources.
One thing he did write, however, is not correct. Apple did not confirm, they merely responded with their standard reply.
Last edited:
I don't believe it points to anything new, just improvement of their backend in terms of performance, scale and ACID (the latter meaning in general terms, consistent, reliable data). Could be for iCloud (docs, files - especially in terms of dealing with concurrent access to documents/collaboration), content and meta data for the store/iTunes, maybe a Parse-like backend service for IOS dev, the list goes on
You are both assuming that Apple wasnt already using this. However, it is entirely possible that Apple has been using FoundationDB and decided to buy them out so they could develop the technology further without fear of the competition leveraging it.
I have no idea if my speculation is true, but a lot of companies I have heard Apple buy were companies they had worked with first, so this could be the case here too. Just a thought.
Apple bought a database company. Its product is very fast, can handle lots of data, and is low cost to run.
"In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee that database transactions are processed reliably. In the context of databases, a single logical operation on the data is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction."
Last edited:
When you quote from Wikipedia, please mark it as a quote. Otherwise it is plagiarism. http://en.wikipedia.org/wiki/ACID for anyone who wants to read the full article.
For all we know, they could already be using this technology - and only after rolling it out - decided it would be a good idea to purchase the brains behind the software.
On a tech blog the journalist has the right to assume that the reader understands basic math and units.
I had a whole different take on this . . .
Before thinking iTunes (which I hate) and iColud (which I won't use), I asked myself if Apple was going to come up with an industrial strength version of FileMaker Pro. The thought just stayed for a second, but it was the first thing that popped into my head.
Before thinking iTunes (which I hate) and iColud (which I won't use), I asked myself if Apple was going to come up with an industrial strength version of FileMaker Pro. The thought just stayed for a second, but it was the first thing that popped into my head.
"The Mac OS X version of the FoundationDB server and SQL Layer are intended for use on locally accessible development machines only. Other uses are not recommended."
I agree with both of you, as those are two of the realistic perspectives I was able to fathom. As, "I can't fathom why they wouldn't have leveraged it prior", means: I can and have fathomed that they would have leveraged it prior. -- But despite seeing the ways they could have endeavored into NoSQL prior, "oddly" (contrary to my imaginings) it still seems to me as if this is their first foray.
That's my fault, I didn't convey myself clearly enough. Ultimately I agree with you both. But it still seems to me as if this is their first foray.
iCloud mail's spartan view is a good thing...
Do you cringe at its simple layout/view or because you view it as subpar in its usability or power? I use it occasionally within a browser window and frankly enjoy its simplicity. But I typically avoid using a web browser for my main email client. I have general disdain for the browser clutter and that comes with the typical gmail or yahoo mail window. (Pokemon backgrounds don't increase the effectiveness of my daily email consumption.) Overall I don't understand the desire to use all applications within a browser.
Lastly, iCloud mail services have been essentially as reliable as any other mail services I have used or currently use. Just curious where your issue is...
Do you cringe at its simple layout/view or because you view it as subpar in its usability or power? I use it occasionally within a browser window and frankly enjoy its simplicity. But I typically avoid using a web browser for my main email client. I have general disdain for the browser clutter and that comes with the typical gmail or yahoo mail window. (Pokemon backgrounds don't increase the effectiveness of my daily email consumption.
) Overall I don't understand the desire to use all applications within a browser. Lastly, iCloud mail services have been essentially as reliable as any other mail services I have used or currently use. Just curious where your issue is...
After thinking about it overnight, FDB really could be the silver bullet that makes iCloud data actually work. To take a step back, building big, distributed, scalable, performant data stores is actually really hard. I remember a while back the bbedit guys had an article as to why core data was really broken - objects would go away, not be around, be inconsistent, etc. Apple probably rolled its own backend data store, because back then an object-relational distributed back-end wasn't really something that existed.
FDB solves all those problems, well, except for the object-relational part. But you can flatten all that object crap now, and that's easy compared to the rest of the problem. FDB's consistency isn't "just improvement", it's really something that's very, very hard to do.
Those jepsen tests take a clusterable solution, builds a big cluster, then breaks the cluster apart while still sending data to all the parts. He then puts the cluster back together and sees if it synchronizes the data correctly.
it sounds like you could easily build a big, distributed, fault-tolerant, and consistent data store easily.