Làm cách nào để đồng bộ dữ liệu iPhone Core với máy chủ web, sau đó đẩy sang các thiết bị khác? [đóng cửa]

Tôi đã nghiên cứu một phương pháp để đồng bộ dữ liệu lõi được lưu trữ trong ứng dụng iPhone giữa nhiều thiết bị, chẳng hạn như iPad hoặc Mac. Không có nhiều khung đồng bộ hóa (nếu có) để sử dụng với Core Data trên iOS. Tuy nhiên, tôi đã suy nghĩ về khái niệm sau:

1. Một thay đổi được thực hiện cho kho dữ liệu lõi cục bộ và thay đổi được lưu. (a) Nếu thiết bị đang trực tuyến, nó sẽ cố gắng gửi bộ thay đổi đến máy chủ, bao gồm cả ID thiết bị của thiết bị đã gửi bộ thay đổi. (b) Nếu bộ thay đổi không đến được máy chủ hoặc nếu thiết bị không trực tuyến, ứng dụng sẽ thêm thay đổi được đặt vào hàng đợi để gửi khi nó trực tuyến.
2. Máy chủ, ngồi trên đám mây, hợp nhất các bộ thay đổi cụ thể mà nó nhận được với cơ sở dữ liệu chủ của nó.
3. Sau khi bộ thay đổi (hoặc hàng đợi của bộ thay đổi) được hợp nhất trên máy chủ đám mây, máy chủ sẽ đẩy tất cả các bộ thay đổi đó sang các thiết bị khác đã đăng ký với máy chủ bằng cách sử dụng một số hệ thống bỏ phiếu. (Tôi nghĩ sẽ sử dụng các dịch vụ Đẩy của Apple, nhưng rõ ràng theo các nhận xét thì đây không phải là một hệ thống khả thi.)

Có bất cứ điều gì lạ mắt mà tôi cần phải suy nghĩ? Tôi đã xem xét các khung công tác REST như ObjectiveResource , Core Resource và RestfulCoreData . Tất nhiên, tất cả đều hoạt động với Ruby on Rails, thứ mà tôi không bị ràng buộc, nhưng đó là nơi để bắt đầu. Các yêu cầu chính tôi có cho giải pháp của mình là:

1. Mọi thay đổi sẽ được gửi trong nền mà không tạm dừng luồng chính.
2. Nó nên sử dụng càng ít băng thông càng tốt.

Tôi đã nghĩ về một số thách thức:

1. Đảm bảo rằng ID đối tượng cho các kho dữ liệu khác nhau trên các thiết bị khác nhau được đính kèm trên máy chủ. Điều đó có nghĩa là, tôi sẽ có một bảng ID đối tượng và ID thiết bị, được gắn thông qua một tham chiếu đến đối tượng được lưu trữ trong cơ sở dữ liệu. Tôi sẽ có một bản ghi (DatabaseId [duy nhất cho bảng này], ObjectId [duy nhất cho mục trong toàn bộ cơ sở dữ liệu], Datafield1, Datafield2), trường ObjectId sẽ tham chiếu một bảng khác, AllObjects: (ObjectId, DeviceId, DeviceObjectId). Sau đó, khi thiết bị đẩy lên một bộ thay đổi, nó sẽ chuyển dọc theo Id thiết bị và objectId từ đối tượng dữ liệu cốt lõi trong kho lưu trữ dữ liệu cục bộ. Sau đó, máy chủ đám mây của tôi sẽ kiểm tra đối tượng Id đối tượng và thiết bị trong bảng AllObjects và tìm bản ghi để thay đổi trong bảng ban đầu.
2. Tất cả các thay đổi nên được đánh dấu thời gian, để chúng có thể được hợp nhất.
3. Thiết bị sẽ phải thăm dò máy chủ, mà không sử dụng quá nhiều pin.
4. Các thiết bị cục bộ cũng sẽ cần cập nhật mọi thứ được giữ trong bộ nhớ nếu / khi nhận được thay đổi từ máy chủ.

Có điều gì khác tôi đang thiếu ở đây? Những loại khung nào tôi nên xem xét để thực hiện điều này có thể?

Tôi đề nghị đọc kỹ và thực hiện chiến lược đồng bộ được thảo luận bởi Dan Grover tại hội nghị iPhone 2009, có sẵn ở đây dưới dạng tài liệu pdf.

Đây là một giải pháp khả thi và không khó thực hiện (Dan đã thực hiện điều này trong một số ứng dụng của nó), chồng chéo giải pháp được mô tả bởi Chris. Để có một cuộc thảo luận chuyên sâu, lý thuyết về đồng bộ hóa, hãy xem bài viết của Russ Cox (MIT) và William Josephson (Princeton):

Đồng bộ hóa tệp với các cặp thời gian Vector

áp dụng tốt như nhau cho dữ liệu cốt lõi với một số sửa đổi rõ ràng. Điều này cung cấp một chiến lược đồng bộ hóa đáng tin cậy và mạnh mẽ hơn nhiều, nhưng đòi hỏi nhiều nỗ lực hơn để được thực hiện chính xác.

BIÊN TẬP:

Có vẻ như tệp pdf của Grover không còn khả dụng (liên kết bị hỏng, tháng 3 năm 2015). CẬP NHẬT: liên kết có sẵn thông qua Way Back Machine tại đây

Khung Objective-C được gọi là ZSync và được phát triển bởi Marcus Zarra đã không được chấp nhận, vì cuối cùng iCloud dường như hỗ trợ đồng bộ hóa dữ liệu cốt lõi chính xác.

Tôi đã làm một cái gì đó tương tự như những gì bạn đang cố gắng làm. Hãy để tôi nói cho bạn biết những gì tôi đã học và làm thế nào tôi làm điều đó.

Tôi giả sử bạn có mối quan hệ một đối một giữa đối tượng Dữ liệu lõi của bạn và mô hình (hoặc lược đồ db) trên máy chủ. Bạn chỉ muốn giữ nội dung máy chủ đồng bộ với máy khách, nhưng máy khách cũng có thể sửa đổi và thêm dữ liệu. Nếu tôi hiểu đúng, thì hãy tiếp tục đọc.

Tôi đã thêm bốn trường để hỗ trợ đồng bộ hóa:

1. sync_status - Chỉ thêm trường này vào mô hình dữ liệu cốt lõi của bạn. Nó được ứng dụng sử dụng để xác định xem bạn có thay đổi đang chờ xử lý đối với mặt hàng đó không. Tôi sử dụng các mã sau: 0 có nghĩa là không có thay đổi, 1 có nghĩa là nó được xếp hàng để được đồng bộ hóa với máy chủ và 2 có nghĩa là nó là một đối tượng tạm thời và có thể bị xóa.
2. is_delatted - Thêm phần này vào mô hình dữ liệu lõi và máy chủ. Xóa sự kiện không thực sự xóa một hàng khỏi cơ sở dữ liệu hoặc từ mô hình máy khách của bạn vì nó không để bạn đồng bộ hóa lại. Bằng cách có cờ boolean đơn giản này, bạn có thể đặt is_delatted thành 1, đồng bộ hóa nó và mọi người sẽ rất vui. Bạn cũng phải sửa đổi mã trên máy chủ và máy khách để truy vấn các mục không bị xóa với "is_delatted = 0".
3. last_modified - Thêm phần này vào máy chủ và mô hình dữ liệu cốt lõi. Trường này sẽ tự động được cập nhật với ngày và giờ hiện tại của máy chủ mỗi khi có bất cứ điều gì thay đổi trên bản ghi đó. Nó không bao giờ nên được sửa đổi bởi khách hàng.
4. hướng dẫn - Thêm một id duy nhất toàn cầu (xem http://en.wikipedia.org/wiki/Globally_unique_identifier ) vào mô hình dữ liệu lõi và máy chủ. Trường này trở thành khóa chính và trở nên quan trọng khi tạo bản ghi mới trên máy khách. Thông thường khóa chính của bạn là số nguyên tăng dần trên máy chủ, nhưng chúng tôi phải lưu ý rằng nội dung có thể được tạo ngoại tuyến và được đồng bộ hóa sau này. GUID cho phép chúng tôi tạo một khóa trong khi ngoại tuyến.

Trên máy khách, thêm mã để đặt sync_status thành 1 trên đối tượng mô hình của bạn bất cứ khi nào có gì đó thay đổi và cần được đồng bộ hóa với máy chủ. Các đối tượng mô hình mới phải tạo GUID.

Đồng bộ hóa là một yêu cầu duy nhất. Yêu cầu chứa:

• Dấu thời gian MAX cuối cùng được sửa đổi của các đối tượng mô hình của bạn. Điều này cho biết máy chủ bạn chỉ muốn thay đổi sau dấu thời gian này.
• Một mảng JSON chứa tất cả các mục có sync_status = 1.

Máy chủ nhận được yêu cầu và thực hiện điều này:

• Nó lấy nội dung từ mảng JSON và sửa đổi hoặc thêm các bản ghi mà nó chứa. Trường last_modified được tự động cập nhật.
• Máy chủ trả về một mảng JSON chứa tất cả các đối tượng có dấu thời gian Last_modified lớn hơn dấu thời gian được gửi trong yêu cầu. Điều này sẽ bao gồm các đối tượng mà nó vừa nhận được, đóng vai trò xác nhận rằng bản ghi đã được đồng bộ hóa thành công với máy chủ.

Ứng dụng nhận được phản hồi và thực hiện điều này:

• Nó lấy nội dung từ mảng JSON và sửa đổi hoặc thêm các bản ghi mà nó chứa. Mỗi bản ghi được đặt sync_status bằng 0.

Tôi hy vọng điều đó sẽ giúp. Tôi đã sử dụng bản ghi từ và mô hình thay thế cho nhau, nhưng tôi nghĩ rằng bạn có ý tưởng. Chúc may mắn.

Nếu bạn vẫn đang tìm cách để đi, hãy nhìn vào Couchbase di động. Điều này về cơ bản làm tất cả những gì bạn muốn. ( http://www.couchbase.com/nosql-database/couchbase-mobile )

Tương tự như @Cris Tôi đã triển khai lớp để đồng bộ hóa giữa máy khách và máy chủ và đã giải quyết tất cả các sự cố đã biết (gửi / nhận dữ liệu đến / từ máy chủ, hợp nhất các xung đột dựa trên dấu thời gian, xóa các mục trùng lặp trong điều kiện mạng không đáng tin cậy, đồng bộ hóa dữ liệu lồng nhau và tập tin vv ..)

Bạn chỉ cần cho lớp biết thực thể nào và cột nào sẽ đồng bộ hóa và máy chủ của bạn ở đâu.

M3Synchronization * syncEntity = [[M3Synchronization alloc] initForClass: @"Car"
                                                              andContext: context
                                                            andServerUrl: kWebsiteUrl
                                             andServerReceiverScriptName: kServerReceiverScript
                                              andServerFetcherScriptName: kServerFetcherScript
                                                    ansSyncedTableFields:@[@"licenceNumber", @"manufacturer", @"model"]
                                                    andUniqueTableFields:@[@"licenceNumber"]];


syncEntity.delegate = self; // delegate should implement onComplete and onError methods
syncEntity.additionalPostParamsDictionary = ... // add some POST params to authenticate current user

[syncEntity sync];

Bạn có thể tìm nguồn, ví dụ hoạt động và hướng dẫn thêm tại đây: github.com/knagode/M3Synyncization .

Thông báo người dùng để cập nhật dữ liệu thông qua thông báo đẩy. Sử dụng một luồng nền trong ứng dụng để kiểm tra dữ liệu cục bộ và dữ liệu trên máy chủ đám mây, trong khi thay đổi xảy ra trên máy chủ, thay đổi dữ liệu cục bộ, ngược lại.

Vì vậy, tôi nghĩ phần khó nhất là ước tính dữ liệu ở phía nào không hợp lệ.

Hy vọng điều này có thể giúp bạn

Tôi vừa đăng phiên bản đầu tiên của API đồng bộ hóa đám mây dữ liệu lõi mới, được gọi là SynCloud. SynCloud có rất nhiều điểm khác biệt với iCloud vì nó cho phép giao diện đồng bộ nhiều người dùng. Nó cũng khác với các api đồng bộ hóa khác vì nó cho phép dữ liệu quan hệ nhiều bảng.

Vui lòng tìm hiểu thêm tại http://www.syncloudapi.com

Xây dựng với SDK iOS 6, nó được cập nhật kể từ ngày 27/9/2012.

Tôi nghĩ rằng một giải pháp tốt cho vấn đề GUID là "hệ thống ID phân tán". Tôi không chắc thuật ngữ chính xác là gì, nhưng tôi nghĩ đó là những gì mà tài liệu máy chủ MS SQL đã sử dụng để gọi nó (SQL sử dụng / sử dụng phương thức này cho cơ sở dữ liệu phân tán / đồng bộ hóa). Nó khá đơn giản:

Máy chủ chỉ định tất cả ID. Mỗi khi đồng bộ hóa được thực hiện, điều đầu tiên được kiểm tra là "Tôi còn lại bao nhiêu ID trên máy khách này?" Nếu máy khách sắp hết, nó sẽ yêu cầu máy chủ cung cấp một khối ID mới. Sau đó, khách hàng sử dụng ID trong phạm vi đó cho các bản ghi mới. Điều này hoạt động tốt cho hầu hết các nhu cầu, nếu bạn có thể chỉ định một khối đủ lớn để nó "không bao giờ" hết trước khi đồng bộ hóa tiếp theo, nhưng không lớn đến mức máy chủ hết thời gian. Nếu ứng dụng khách đã hết, việc xử lý có thể khá đơn giản, chỉ cần nói với người dùng "xin lỗi bạn không thể thêm nhiều mục cho đến khi bạn đồng bộ hóa" ... nếu họ đang thêm nhiều mục đó, họ không nên đồng bộ hóa để tránh dữ liệu cũ có vấn đề gì không?

Tôi nghĩ rằng điều này tốt hơn so với việc sử dụng GUID ngẫu nhiên vì GUID ngẫu nhiên không an toàn 100% và thường cần dài hơn nhiều so với ID tiêu chuẩn (128 bit so với 32 bit). Bạn thường có các chỉ mục theo ID và thường giữ số ID trong bộ nhớ, vì vậy điều quan trọng là phải giữ chúng nhỏ.

Không thực sự muốn đăng dưới dạng câu trả lời, nhưng tôi không biết rằng bất kỳ ai cũng sẽ xem như một nhận xét và tôi nghĩ nó quan trọng đối với chủ đề này và không bao gồm trong các câu trả lời khác.

Trước tiên, bạn nên suy nghĩ lại về việc bạn sẽ có bao nhiêu dữ liệu, bảng và quan hệ. Trong giải pháp của tôi, tôi đã triển khai đồng bộ hóa thông qua các tệp Dropbox. Tôi quan sát các thay đổi trong MOC chính và lưu các dữ liệu này vào các tệp (mỗi hàng được lưu dưới dạng json được nén). Nếu có kết nối internet hoạt động, tôi kiểm tra xem có bất kỳ thay đổi nào trên Dropbox không (Dropbox cung cấp cho tôi các thay đổi delta), tải xuống và hợp nhất (chiến thắng mới nhất) và cuối cùng đặt các tệp đã thay đổi. Trước khi đồng bộ hóa, tôi đặt tệp khóa trên Dropbox để ngăn các máy khách khác đồng bộ hóa dữ liệu không đầy đủ. Khi tải xuống các thay đổi, sẽ an toàn khi chỉ tải xuống một phần dữ liệu (ví dụ: mất kết nối internet). Khi quá trình tải xuống kết thúc (đầy đủ hoặc một phần), nó bắt đầu tải các tệp vào Dữ liệu lõi. Khi có các mối quan hệ chưa được giải quyết (không phải tất cả các tệp được tải xuống), nó sẽ dừng tải các tệp và cố gắng hoàn tất tải xuống sau đó. Mối quan hệ chỉ được lưu trữ dưới dạng GUID, vì vậy tôi có thể dễ dàng kiểm tra tệp nào sẽ tải để có toàn vẹn dữ liệu. Đồng bộ hóa đang bắt đầu sau khi thay đổi dữ liệu cốt lõi được thực hiện. Nếu không có thay đổi, thì nó sẽ kiểm tra các thay đổi trên Dropbox cứ sau vài phút và khi khởi động ứng dụng. Bổ sung khi các thay đổi được gửi đến máy chủ Tôi gửi truyền phát đến các thiết bị khác để thông báo cho họ về các thay đổi, để họ có thể đồng bộ hóa nhanh hơn. Mỗi thực thể được đồng bộ hóa có thuộc tính GUID (hướng dẫn cũng được sử dụng làm tên tệp cho các tệp trao đổi). Tôi cũng đã đồng bộ hóa cơ sở dữ liệu nơi tôi lưu trữ bản sửa đổi Dropbox của từng tệp (tôi có thể so sánh nó khi Dropbox delta đặt lại trạng thái của nó). Các tệp cũng chứa tên thực thể, trạng thái (đã xóa / không xóa), hướng dẫn (giống như tên tệp), sửa đổi cơ sở dữ liệu (để phát hiện di chuyển dữ liệu hoặc để tránh đồng bộ hóa với các phiên bản ứng dụng không bao giờ) và tất nhiên là dữ liệu (nếu hàng không bị xóa). vì vậy tôi có thể dễ dàng kiểm tra những tập tin nào để tải để có toàn vẹn dữ liệu. Đồng bộ hóa đang bắt đầu sau khi thay đổi dữ liệu cốt lõi được thực hiện. Nếu không có thay đổi, thì nó sẽ kiểm tra các thay đổi trên Dropbox cứ sau vài phút và khi khởi động ứng dụng. Bổ sung khi các thay đổi được gửi đến máy chủ Tôi gửi truyền phát đến các thiết bị khác để thông báo cho họ về các thay đổi, để họ có thể đồng bộ hóa nhanh hơn. Mỗi thực thể được đồng bộ hóa có thuộc tính GUID (hướng dẫn cũng được sử dụng làm tên tệp cho các tệp trao đổi). Tôi cũng đã đồng bộ hóa cơ sở dữ liệu nơi tôi lưu trữ bản sửa đổi Dropbox của từng tệp (tôi có thể so sánh nó khi Dropbox delta đặt lại trạng thái của nó). Các tệp cũng chứa tên thực thể, trạng thái (đã xóa / không xóa), hướng dẫn (giống như tên tệp), sửa đổi cơ sở dữ liệu (để phát hiện di chuyển dữ liệu hoặc để tránh đồng bộ hóa với các phiên bản ứng dụng không bao giờ) và tất nhiên là dữ liệu (nếu hàng không bị xóa). vì vậy tôi có thể dễ dàng kiểm tra những tập tin nào để tải để có toàn vẹn dữ liệu. Đồng bộ hóa đang bắt đầu sau khi thay đổi dữ liệu cốt lõi được thực hiện. Nếu không có thay đổi, thì nó sẽ kiểm tra các thay đổi trên Dropbox cứ sau vài phút và khi khởi động ứng dụng. Bổ sung khi các thay đổi được gửi đến máy chủ Tôi gửi truyền phát đến các thiết bị khác để thông báo cho họ về các thay đổi, để họ có thể đồng bộ hóa nhanh hơn. Mỗi thực thể được đồng bộ hóa có thuộc tính GUID (hướng dẫn cũng được sử dụng làm tên tệp cho các tệp trao đổi). Tôi cũng đã đồng bộ hóa cơ sở dữ liệu nơi tôi lưu trữ bản sửa đổi Dropbox của từng tệp (tôi có thể so sánh nó khi Dropbox delta đặt lại trạng thái của nó). Các tệp cũng chứa tên thực thể, trạng thái (đã xóa / không xóa), hướng dẫn (giống như tên tệp), sửa đổi cơ sở dữ liệu (để phát hiện di chuyển dữ liệu hoặc để tránh đồng bộ hóa với các phiên bản ứng dụng không bao giờ) và tất nhiên là dữ liệu (nếu hàng không bị xóa).

Giải pháp này đang làm việc cho hàng ngàn tệp và khoảng 30 thực thể. Thay vì Dropbox tôi có thể sử dụng kho khóa / giá trị như dịch vụ web REST mà tôi muốn làm sau này, nhưng không có thời gian cho việc này :) Hiện tại, theo tôi, giải pháp của tôi đáng tin cậy hơn iCloud và, điều này rất quan trọng, Tôi có toàn quyền kiểm soát cách thức hoạt động của nó (chủ yếu vì đó là mã của riêng tôi).

Một giải pháp khác là lưu các thay đổi MOC khi giao dịch - sẽ có ít tệp được trao đổi với máy chủ hơn, nhưng khó hơn để tải ban đầu theo thứ tự thích hợp vào dữ liệu lõi trống. iCloud đang hoạt động theo cách này và các giải pháp đồng bộ hóa khác cũng có cách tiếp cận tương tự, ví dụ TICoreDataSync .

- CẬP NHẬT

Sau một thời gian, tôi đã di chuyển đến Ensembles - Tôi khuyên bạn nên giải pháp này trên reinventing the wheel.