Core Data, External Binary Data Storage, and Migration
I have benchmarked the difference between migration using binary data with external storage and using just a unique identifier. The sample project is on GitHub.
The test creates 1000 objects, each with a unique identifier and (optionally) a video file of 165KB as binary data. By adding a data model version with a new attribute, lightweight migration is performed on the next application launch.
When using binary data with external storage, migration took 37.5 seconds.
When not using binary data with external storage, migration took just 0.6 seconds.
It’s clear to see that storing large files in the file system with a naming scheme is the way to go. I have already begun working on an on-disk cache instead of using binary attributes.
External BLOB storage is important because storing BLOBs as linked lists in the database can be inefficient. When Core Data added -setAllowsExternalBinaryDataStorage:, this sounded like a good solution to the problem, but various problems were reported in early versions. It sounds like there are still issues, which is unfortunate because this sort of feature (commonly needed, tricky to do well) should be a selling point for a more full-featured framework like Core Data.
1 Comment RSS · Twitter
[…] Previously: Core Data, External Binary Data Storage, and Migration. […]
