Most iOS apps today use Core Data for persistence, but this isn’t always the right option, according to iOS developer and chief ‘codesplicer’ at Codesplice Sam Ritchie.
Ritchie spoke with Techworld Australia about the problems of using Core Data for iOS apps and evaluated NoSQL as an alternative. Ritchie is speaking today at the YOW! Connected conference in Melbourne on NoSQL for iOS apps.
“I’ve got a bit of a reputation of being a Core Data hater,” Ritchie said. “It just doesn’t seem the right tool for the job in building a data layer for an iPhone app.”
One of the main problems with Core Data is that performance issues can occur when you abstract too much from a relational database, as it pretends you are dealing with an object in memory rather than a database on disk, Ritchie said.
“It’s basically an object relational mapping tool and that’s sort of the well-known drawbacks within the enterprise software space,” Ritchie said.
“The issue with Core Data is that it tries to put too much abstraction over the top of the database so that you are pretending you are not using a database when in fact you are. And that causes problems in that things that are really easy to accomplish in SQL databases are actually quite hard to do by Core Data.”
Another problem with Core Data is that is doesn’t easily allow developers to pre-emptively specify particular data they need from different tables and pull it all together.
“You can actually do this through SQL. It’s a little bit more complicated, but you can do it so that you pull it all off the disk in one query. But Core Data doesn’t expose a particular way to specify that, it doesn’t work as well,” Ritchie said.
When it comes to offline syncing and merging change conflicts, Core Data can be difficult to work with, Ritchie said.Read more: Microsoft jumps into NoSQL market with new Azure data store
“Offline syncing is often what we want on a mobile device; we want to be able to make changes and sync offline. When we try and merge change conflicts – as in I’ve changed something on my iPad, I’ve changed the same thing on my iPhone – it starts getting really, really difficult to change in a robust way and merge the conflicts in a robust way because of the way the underlying data is stored at the row level.”
Core Data doesn’t handle multi-threaded scenarios particularly well, said Ritchie. Most mobile devices today tend to have multi-core CPUs, effectively having multiple threads of execution running concurrently.
“I know guys that do it and they curse and claim they are never going to touch Core Data again because it really doesn’t handle that sort of scenario very well where they are trying to do concurrent work on the same database - we are showing a UI at the front end and redoing some sort of a batch process at the back end. That’s something that Core Data doesn’t handle very well,” he said.
“It’s probably going to be easier for people to write code that does take advantage of multiple cores on a device.”Read more: New PostgreSQL guns for NoSQL market
Some of the problems with Core Data can be addressed with NoSQL, Ritchie said. For example, NoSQL can aggregate data across, say, 25 tables and the put it into a single document, whereas relational databases have to separate the data into many relational tables.
“With a relational table, you basically store all the data of the same type together. So you would store all the customers in one table and all of the orders in another table.
“In a document model, you would store probably an order as a document and it would contain in it some customer details, some product details, and that sort of thing. All the things that you would normally want to use to do work within your application you can pull out of the database in a single hit rather than the engine having to go off and join rows of data that are in all these different tables and different places on disk.”
It’s also easier to merge conflicts and do offline syncing with NoSQL, as it's a more document-based data model, Ritchie said.Read more: Scala: Productivity gains but complexity remains
“It’s easier to 'reason about' what’s going to happen when different, conflicting changes happen on different devices. And you can even usually test that within some automatic unit tests within your code, rather than [the way] the Core Data syncing works where weird and creepy stuff happens at run time and it’s pretty much impossible to reason about or troubleshoot.”
Duplication, however, can be an issue when aggregating with NoSQL, Ritchie pointed out.
“With the NoSQL model, you are going to store the same piece of data potentially in multiple places so that you don’t have to go off and retrieve it in different scenarios. What that means is you have duplicated that data in a couple places in your database.
“You just need to be aware that if you are using a technology where the indexing happens after the fact or not necessarily all the indexes are updated every time you change something - they will [usually] kick off and update in the background - what that means is if you make a change and then perform a query you might get back the old data.”
NoSQL also requires developers to “shift their thinking” when it comes to normalising the data, and they need to think about the types of queries upfront.
“They can’t just say, ‘I’m going to normalise the data and then I’ll worry about what queries I’m doing later.’ They have to think upfront about how they are going to be using this data and structuring the way they store it appropriately because that’s where it gets a lot of its speed. Rather than joining all these related tables, you are just going to store data that exactly answers a specific question that’s going to be asked in the future,” Ritchie said.