Re: Sync Services for Multi-machine Core Data App?
Re: Sync Services for Multi-machine Core Data App?
- Subject: Re: Sync Services for Multi-machine Core Data App?
- From: Steve Steinitz <email@hidden>
- Date: Sat, 23 Apr 2011 19:54:08 +1000
(Apologies - I found this in my drafts folder - better late than never?)
Hi Nick,
On 7/03/11, Nick Zitzmann wrote:
My question: is [using Sync Services for a large Core Data database] a good idea?
No.
Thanks for that clear answer.
Sync Services scales poorly and works best with up to a few thousand
small records. Creating multi-megabyte records, or millions of small
records, will cause syncing to take a looooong time
Thanks for that helpful rule of thumb.
Our database is neither: a couple hundred thousand small records
and perhaps 30K new records per year. Would that be any more feasible?
(especially if you have identity properties set),
Really? Identity properties slow it down? I thought it would
be the opposite.
and probably take several gigabytes of RAM just to run a session.
Thanks for sharing your real-world experience. I was under the
impression that Leopard brought performance improvements to Sync Services.
That aside, an occasional 3-gigabyte of ram for a full pull from
The Truth would be fine. Only a hundred or two records change
per day.
We make a sync client, and before we built it for X86-64, we had
several users crash it by attempting to sync too much data.
Are you saying the X86-64 version works better? Works well?
If you need a multi-machine database-driven application, then you
should use ODBC, not CoreData, with either MySQL or PostgreSQL or some
commercial engine on the back end.
Your advice is likely good but it doesn't sound much fun. I
like Core Data. And I'd dislike life if I had to write SQL.
Worst case, I'll just keep my NAS shared database.
Besides possible performance issues are there other serious Sync
Services issues?
I suppose I should post a similar question on Apple's Sync
Services forum and see if I get as unequivocal an answer as your 'No'.
Cheers,
Steve
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden