or Apple could be using this for they own search engine technology
It is possible that the AppleWatch+Siri could displace the Google homepage as the primary means of search for many people in the not to distant future.
Apple is in lots of [SIZE=24px]BIG DATA[/SIZE] areas.
Health
Maps
AppStore
iTunes Store
iBooks Store
iCloud Drive
iCloud Photo Library
Retail
AppleCare
Supply Chain Management
and the list goes on and on...
It will not get attention like the Beats acquisition did but I have a feeling this is going to be one of the most significant acquisitions they have made as it will touch almost everything Apple does operationally.
Yes!
Using Siri on Apple Watch, Apple will have access to Watson from Apple's [tic] IBM Subsidiary ...
^ I always thought that the Apple Store goes down for dramatic effect rather than any technical reason.
If memory serves, the Apple Store was down the most of an entire day. That is simply unheard of.
My take is that Apple purposely took it down for a major scheduled maintenance.
I understand that Apple uses Cassandra DB heavily and they plan to replace that with FoundationDB.
These outages may have been just that. We should find out more at the WWDC.
Here's an example of a swap of a live running FoundationDB from one Cloud Service to another:
Finally, I'm an old RDBMS user -- so I never bothered with Core Data on OS X or iOS. I took some tutorials to get up to speed on Core Data. Here's some interesting findings:
Using Core Data, Bindings * and Storyboards/IB -- you can create a quite sophisticated app without writing any lines of code! For example, a multi-colum table where each column can be sorted, resized, rearranged and [un]hidden.
Rows can be added, deleted or edited.
Core Data automatically provides persistant data (retained between app executions) and Undo/Redo for UEX.
Core Data is fully implemented in Swift
Core Data uses a Key/Value construct as the data model
The underlying data store can be SQLite or other custom datastore **
* Bindings are not, yet, available in iOS ... So, today, you must write some lines of code -- quite straight forward using Swift.
** It appears that the Core Data data model and data store could easily be replaced with FoundationDB with not too much effort on Apple's part.
The benefits would be profound: ACIDity; Transactional; Performant; Distributed; Fault-tolerant; Scalable (up and down);
Other DBMS constructs, such as SQL, can be implemented as a layer on top of FoundationDB -- and automatically gain all the underlying benefits.
As I understand it, with a Core Data/FoundationDB implementation for Apple's Online store -- Apple could have multiple versions (current and new) of their DB running on their servers ... Then, during a keynote, when Tim clicked for the slide showing price/availablity -- the Apple Stores would immediately switch to the new version of the DB.
Boom!
Edit: I sure wish I could get my hamds on a copy of the OS X FoundationDB -- it would be interesting to see how it performs, compares with Core Data and can be programmed with Swift.
There is a rather obvious missing platform ,,, 64-bit iOS.
I suspect we'll see iOS devices, real soon now, that meet the hardware requirements * -- Apple TV/Hub/Home Server and iPad Pro come to mind.
* and that there will be a scaled [down] version for smaller iDevices.
By and large bindings are a maintenance nightmare. And Core Data is a beast of an API. It's not as easy as you pretend.
And look, swift isn't changing anything about how you work with the Cocoa API. The barrier to entry for Mac or ios Dev is the sheer size of the frameworks.
By and large bindings are a maintenance nightmare.
I have not maintained apps with bindings over time -- but I suspect that they are difficult to maintain. Likely, much of this is due to the implementation: poor or no defaults; lack of "how to" documentation; and the fact that required bits and pieces are all over the place. I suspect that this is why bindings are currently unavailable in iOS -- they want to implement it in a better way.
And Core Data is a beast of an API. It's not as easy as you pretend.
I am new to Core Data ... Here, too, some of the defaults are poor, and the UI coding unnecessarily difficult ... But for someone experienced interfacing traditional RDBMS', implementing Core Data appears to be equal or less complex -- and provides more.
From what I've read, the early implementations of Core Data, especially for iCloud, were buggy and difficult to get working. AFAICT, recent improvements have made Core Data more reliable and easier to implement and maintain. For example Core Data provides powerful tools * to migrate and version the database -- maintenance apps that you would have to program and maintain with other data management systems.
* according to several tutorial examples
And look, swift isn't changing anything about how you work with the Cocoa API. The barrier to entry for Mac or ios Dev is the sheer size of the frameworks.
Here, we differ ... IMO, Swift changes everything (sometimes in each new Version of Swift :roll eyes: ). The language allows you to do things that are impractical or impossible in Obj-C. Many of the Cocoa APIs and frameworks are being rewritten to take advantage a modern, more-powerful language.
I have been programming a little OS X and mostly iOS (since its first release). IMO, Swift makes it a lot faster, easier and fun.
To sum up: I'm an optimist. I look around at Swift, Storyboards, Playgrounds, REPL, Compiler, Bindings, Core Data and, now FoundationDB -- and see the potential for at least an order of magnitude improvement in programming -- over what existed 7 - 10 years ago.
In terms of maintenance hidden obscure links in IB ( not outlets but the bindings), particularly those that have little or no documentation can totally obscure the maintaining of a code base. Objective C is verbose enough to be self-documenting. A bindings project ( just download one from Apple) is full of hidden bits which need the coder to write a few page of documentation in their own project to explain what is going on, which most don't. In the absence of doing that people who take over flounder about. Some iOS devs don't even use IB at all.
As for foundationDB, what I really want from a database is something which is thread safe to call
array.serialiseWithKey(key).
array = NSArray.deserialiseFromKey(key)
The array and all items having to conform to some serialisation key.
The NSCoder stuff is almost there but is expensive and isn't recommended for complex items, and isn't built into objects.
However CoreData isn't really a relationalDB and manages to be both too complex for a simple persistent graph, and too simple to scale.
With functional programming in swift I could imagine additions like
In terms of maintenance hidden obscure links in IB ( not outlets but the bindings), particularly those that have little or no documentation can totally obscure the maintaining of a code base.
I totally agree with that! As I said earlier, bindings are poorly implemented, and documented ...
But that does't mean it has to be that way. I would like to see a higher-level of specifying bindings for a project -- maybe a checkbox to use bindings when creating a project similar to "Use Core Data". Then some intelligent automatic generation of defaults -- for example when using IB, Bindings and Core Data -- IB could generate and populate an Array Controller with commonly-used bindings for managed objects / Arranged Objects (couldn't these be combined), Table Content View, Sort Descrtptors, Undo/Redo, Default SQLite or FoundationDB Store (instead of XML) ...
Something like this:
Objective C is verbose enough to be self-documenting.
IMO, one of the most difficult programming languages to learn is Obj-C -- and the verbosity makes it difficult to read. It has gotten better over the years -- but every programmer seems to have his own style ...
To me, the conciseness of Swift code (with a few comments where necessary) provides better self-documented code.
A bindings project ( just download one from Apple) is full of hidden bits which need the coder to write a few page of documentation in their own project to explain what is going on, which most don't. In the absence of doing that people who take over flounder about. Some iOS devs don't even use IB at all.
Consistent, automatically-generated defaults for common usage, as described above, would alleviate much of this burden. Also, it would be great for Apple to allow developers to add annotations to IB Storyboards and XIBS to describe unusual uses .... then allow built-in screen captures ... Or, maybe even have Xcode automatically create an editable log of what the developer does to setup the data model and UI ...
As for foundationDB, what I really want from a database is something which is thread safe to call
array.serialiseWithKey(key).
array = NSArray.deserialiseFromKey(key)
The array and all items having to conform to some serialisation key.
The NSCoder stuff is almost there but is expensive and isn't recommended for complex items, and isn't built into objects.
From what I've read, FoundationDB is thread safe.
Some of the serialization you describe may be built in. FoundationDB uses an ordered Key/Value model -- Basically a dictionary. Ordering provides the ability to quickly access slices or ranges of data. Under the covers, it appears that they implement some sort of transparent key uniquifyers so that duplicate keys can exist. The value can be a scalar or an array, dictionary ... It looks quite flexible.
You can identify a process as a Transaction. AFAICT, this timestamps each data request. When you commit these are processed in the order requested and the transaction commits or fails (is retried) on an all-or-nothing basis.
This avoids things like the fatal embrace
However CoreData isn't really a relationalDB and manages to be both too complex for a simple persistent graph, and too simple to scale.
I suspect you are correct about Core Data. But FoundationDB could be used to reimplement/replace Core Data.
First, FoundationDB was built to scale ... maybe overbuilt for small dbs such as those on iDevices. Core Data does faulting to minimize RAM requirements while running an embedded db. I suspect that an embedded implementation of FoundataionDB could be scaled down (minimum RAM and Storage) and could implement faulting.
Second, FoundationDB has a layer built on top of its data model that provides SQL capability (and all the underlying scalling, fault-tolerance, transactions, etc. to the SQL user).
In one of the FoundationDB videos they mention that the newest SQLite (version 4) exposes it's underlying data model ... and it is very similar to the key/value store used by FoundationDB. In fact, a temp hire, with a few days work, shimmed a FoundationDB replacement into the SQLite data model. It worked! And they were able to run multiple concurrent processes against the SQLite DB.
With functional programming in swift I could imagine additions like
array = NSArray.deserialiseFromKey(key).map(a,b) { return a >b }
or let perdicate = NSPredicate.predicateWith.... let array = NSArray.deserialiseFromKey(key).arrayWithPredicate(predicate).
Someone do that.
I looked at some of the FoundationDB coding examples and I can visualize that it would quite easy to extend Swift with language constructs and APIs to allow it to perform as a superior low-level and high-level database manipulation language.
Comments
Yes!
Using Siri on Apple Watch, Apple will have access to Watson from Apple's [tic] IBM Subsidiary ...
^ I always thought that the Apple Store goes down for dramatic effect rather than any technical reason.
If memory serves, the Apple Store was down the most of an entire day. That is simply unheard of.
My take is that Apple purposely took it down for a major scheduled maintenance.
I understand that Apple uses Cassandra DB heavily and they plan to replace that with FoundationDB.
These outages may have been just that. We should find out more at the WWDC.
Here's an example of a swap of a live running FoundationDB from one Cloud Service to another:
[VIDEO]https://foundationdb.com/videos/foundationdb-hot-cloud-swap[/VIDEO]
This demonstrates fault tolerance of FoundationDB.
If you are correct about Apple using Cassandra and replacing it with FoundationDB -- this explains some of the advantages:
http://pages.foundationdb.com/cassandra_vs_foundationdb
Finally, I'm an old RDBMS user -- so I never bothered with Core Data on OS X or iOS. I took some tutorials to get up to speed on Core Data. Here's some interesting findings:
* Bindings are not, yet, available in iOS ... So, today, you must write some lines of code -- quite straight forward using Swift.
** It appears that the Core Data data model and data store could easily be replaced with FoundationDB with not too much effort on Apple's part.
The benefits would be profound: ACIDity; Transactional; Performant; Distributed; Fault-tolerant; Scalable (up and down);
Other DBMS constructs, such as SQL, can be implemented as a layer on top of FoundationDB -- and automatically gain all the underlying benefits.
As I understand it, with a Core Data/FoundationDB implementation for Apple's Online store -- Apple could have multiple versions (current and new) of their DB running on their servers ... Then, during a keynote, when Tim clicked for the slide showing price/availablity -- the Apple Stores would immediately switch to the new version of the DB.
Boom!
Edit: I sure wish I could get my hamds on a copy of the OS X FoundationDB -- it would be interesting to see how it performs, compares with Core Data and can be programmed with Swift.
Mmm ...
There is a rather obvious missing platform ,,, 64-bit iOS.
I suspect we'll see iOS devices, real soon now, that meet the hardware requirements * -- Apple TV/Hub/Home Server and iPad Pro come to mind.
* and that there will be a scaled [down] version for smaller iDevices.
By and large bindings are a maintenance nightmare. And Core Data is a beast of an API. It's not as easy as you pretend.And look, swift isn't changing anything about how you work with the Cocoa API. The barrier to entry for Mac or ios Dev is the sheer size of the frameworks.
I have not maintained apps with bindings over time -- but I suspect that they are difficult to maintain. Likely, much of this is due to the implementation: poor or no defaults; lack of "how to" documentation; and the fact that required bits and pieces are all over the place. I suspect that this is why bindings are currently unavailable in iOS -- they want to implement it in a better way.
I am new to Core Data ... Here, too, some of the defaults are poor, and the UI coding unnecessarily difficult ... But for someone experienced interfacing traditional RDBMS', implementing Core Data appears to be equal or less complex -- and provides more.
From what I've read, the early implementations of Core Data, especially for iCloud, were buggy and difficult to get working. AFAICT, recent improvements have made Core Data more reliable and easier to implement and maintain. For example Core Data provides powerful tools * to migrate and version the database -- maintenance apps that you would have to program and maintain with other data management systems.
* according to several tutorial examples
Here, we differ ... IMO, Swift changes everything (sometimes in each new Version of Swift :roll eyes: ). The language allows you to do things that are impractical or impossible in Obj-C. Many of the Cocoa APIs and frameworks are being rewritten to take advantage a modern, more-powerful language.
I have been programming a little OS X and mostly iOS (since its first release). IMO, Swift makes it a lot faster, easier and fun.
To sum up: I'm an optimist. I look around at Swift, Storyboards, Playgrounds, REPL, Compiler, Bindings, Core Data and, now FoundationDB -- and see the potential for at least an order of magnitude improvement in programming -- over what existed 7 - 10 years ago.
In terms of maintenance hidden obscure links in IB ( not outlets but the bindings), particularly those that have little or no documentation can totally obscure the maintaining of a code base. Objective C is verbose enough to be self-documenting. A bindings project ( just download one from Apple) is full of hidden bits which need the coder to write a few page of documentation in their own project to explain what is going on, which most don't. In the absence of doing that people who take over flounder about. Some iOS devs don't even use IB at all.
As for foundationDB, what I really want from a database is something which is thread safe to call
array.serialiseWithKey(key).
array = NSArray.deserialiseFromKey(key)
The array and all items having to conform to some serialisation key.
The NSCoder stuff is almost there but is expensive and isn't recommended for complex items, and isn't built into objects.
However CoreData isn't really a relationalDB and manages to be both too complex for a simple persistent graph, and too simple to scale.
With functional programming in swift I could imagine additions like
array = NSArray.deserialiseFromKey(key).map(a,b) {
return a >b
}
or
let perdicate = NSPredicate.predicateWith....
let array = NSArray.deserialiseFromKey(key).arrayWithPredicate(predicate).
Someone do that.
I totally agree with that! As I said earlier, bindings are poorly implemented, and documented ...
But that does't mean it has to be that way. I would like to see a higher-level of specifying bindings for a project -- maybe a checkbox to use bindings when creating a project similar to "Use Core Data". Then some intelligent automatic generation of defaults -- for example when using IB, Bindings and Core Data -- IB could generate and populate an Array Controller with commonly-used bindings for managed objects / Arranged Objects (couldn't these be combined), Table Content View, Sort Descrtptors, Undo/Redo, Default SQLite or FoundationDB Store (instead of XML) ...
Something like this:
IMO, one of the most difficult programming languages to learn is Obj-C -- and the verbosity makes it difficult to read. It has gotten better over the years -- but every programmer seems to have his own style ...
To me, the conciseness of Swift code (with a few comments where necessary) provides better self-documented code.
Consistent, automatically-generated defaults for common usage, as described above, would alleviate much of this burden. Also, it would be great for Apple to allow developers to add annotations to IB Storyboards and XIBS to describe unusual uses .... then allow built-in screen captures ... Or, maybe even have Xcode automatically create an editable log of what the developer does to setup the data model and UI ...
From what I've read, FoundationDB is thread safe.
Some of the serialization you describe may be built in. FoundationDB uses an ordered Key/Value model -- Basically a dictionary. Ordering provides the ability to quickly access slices or ranges of data. Under the covers, it appears that they implement some sort of transparent key uniquifyers so that duplicate keys can exist. The value can be a scalar or an array, dictionary ... It looks quite flexible.
You can identify a process as a Transaction. AFAICT, this timestamps each data request. When you commit these are processed in the order requested and the transaction commits or fails (is retried) on an all-or-nothing basis.
This avoids things like the fatal embrace
I suspect you are correct about Core Data. But FoundationDB could be used to reimplement/replace Core Data.
First, FoundationDB was built to scale ... maybe overbuilt for small dbs such as those on iDevices. Core Data does faulting to minimize RAM requirements while running an embedded db. I suspect that an embedded implementation of FoundataionDB could be scaled down (minimum RAM and Storage) and could implement faulting.
Second, FoundationDB has a layer built on top of its data model that provides SQL capability (and all the underlying scalling, fault-tolerance, transactions, etc. to the SQL user).
In one of the FoundationDB videos they mention that the newest SQLite (version 4) exposes it's underlying data model ... and it is very similar to the key/value store used by FoundationDB. In fact, a temp hire, with a few days work, shimmed a FoundationDB replacement into the SQLite data model. It worked! And they were able to run multiple concurrent processes against the SQLite DB.
I looked at some of the FoundationDB coding examples and I can visualize that it would quite easy to extend Swift with language constructs and APIs to allow it to perform as a superior low-level and high-level database manipulation language.