Sincronizzazione dei dati nelle app mobili: più dispositivi, più utenti

Attualmente sto lavorando a un'app mobile / desktop / distribuita con esattamente gli stessi requisiti e problemi.

Prima di tutto, questi requisiti non sono inerenti alle app mobili di per sé, ma a qualsiasi transazione client-server disconnessa / distribuita (programmazione parallela, multithreading, si ottiene il punto). In quanto tali, naturalmente, sono i problemi tipici da affrontare nelle app mobili.

Generalmente, ciò a cui tutto si riduce è che si dispone di un potenziale record di dati che viene distribuito a n client, che possono modificarlo allo stesso tempo. Quello di cui hai bisogno è

1. un meccanismo di controllo / blocco della versione appropriato,
2. una corretta gestione dei diritti / degli accessi,
3. una corretta strategia di sincronizzazione / caching

Per (1) puoi applicare alcuni schemi: Esistono due strategie di blocco usate frequentemente: Blocco offline ottimizzato , e Blocco offline pessimistico . Alcuni di questi vengono applicati in diversi "modelli" di controllo di versione, come Controllo di concorrenza multiVersione (MVCC), che utilizza un contatore (una sorta di "time stamp" molto semplice) per ogni record di dati, che viene aggiornato ogni volta che viene modificato il record.

(2) e (3) sono argomenti molto generali, che devono essere trattati indipendentemente da (1). Alcuni consigli dalla mia esperienza:

• Utilizza una tecnologia client-server che astrae la maggior parte dei problemi per te. Consiglio vivamente alcune tecnologie web come CouchDb , che gestisce (1) tramite Optimistic Offline Locking + MVCC, (2) tramite Web API, e (3) tramite il caching Http molto bene.

• Cerca di non inventare le cose da solo se puoi contare su tecnologie e approcci collaudati. Credo che ogni ora trascorsa a ricercare e confrontare tecnologie / modelli esistenti sia molto meglio spesa che tentare di implementare il / i proprio / i sistema / i.

• Cerca di utilizzare tecnologie omogenee se possibile. Per "omogeneo" intendo tecnologie che sono state costruite con gli stessi principi in mente, ad es. scenari di utilizzo del web 2.0. Un esempio: l'utilizzo di un client CouchDb e REST (Web API) appropriato con una strategia di memorizzazione nella cache locale è una scelta migliore rispetto all'utilizzo di SQL per le app mobili.

• Consiglio vivamente contro l'uso di MySQL perché è una tecnologia che non è stata esplicitamente creata per tali scenari di utilizzo. Funziona, ma stai molto meglio con un sistema di database che abbraccia già la comunicazione web e lo stile di concorrenza (come molti database NoSQL).

A proposito, ho optato per CouchDb con un client locale personalizzato che lavora contro le API CouchDb, che funziona e scala magnificamente. Sono passato dall'utilizzo di MSQL + (N) Hibernate e ho pagato un prezzo elevato per non aver fatto la scelta giusta (il che significa non fare abbastanza ricerche) in primo luogo.

Per prima cosa hai menzionato sia un'API che un database (MySQL). Consiglio vivamente di utilizzare un'API e di non provare a comunicare direttamente tra i database. Quest'ultimo percorso non si ridimensionerà affatto.

Un buon punto di partenza che dovresti prendere in considerazione è usare Apache CouchDB . È senza schema, basato su HTTP e JSON e ha un ottimo meccanismo di replica. Lo usiamo per risolvere un problema simile.

Il meccanismo di replica di CouchDB utilizza la stessa API HTTP utilizzata da qualsiasi altro client. Quindi, in sostanza, fornisce la replica su un'API.

Per iOS, ti consiglio di utilizzare il progetto Couchbase Lite . Funziona molto bene per la sincronizzazione dei dati. Per Android, la stessa società che produce il già citato progetto Couchbase Lite sta lavorando a un'offerta simile: Couchbase Lite per Android . Non è completo come la versione iOS e ha ancora del lavoro da fare.

Tuttavia ci sono alcune cose da considerare con CouchDB.

1. Dovrai fornire la tua risoluzione dei conflitti. Fortunatamente, se si verificano conflitti, CouchDB mantiene le versioni e le scelte in conflitto e il conflitto arbitrario ma deterministico come versione principale. Quindi potresti considerare di ritardare la risoluzione dei conflitti per la tua versione iniziale.
2. Il meccanismo di replica è fatto per replicare i database, non per la sincronizzazione di per sé. Pertanto, se si dispone di molti documenti eliminati, la replica dal server al client richiederà più tempo. C'è un modo per evitare questo utilizzando "rotazione del database". In pratica rimuove le vecchie eliminazioni.
3. Non puoi controllare l'ordine di replica. Tuttavia, è possibile creare soluzioni intelligenti per migliorare le prestazioni della replica, ad esempio l'utilizzo della replica filtrata per ottenere prima alcuni documenti o persino l'accesso al server direttamente su richiesta.
4. La replica non avverrà in background su iOS. Puoi utilizzare l'SDK di iOS per fornire alcuni casi di replica in background.

Infine, se non vuoi usare CouchDB, puoi almeno usarlo come buon riferimento per come potresti creare un algoritmo di sincronizzazione usando un'API HTTP. Il mio suggerimento sarebbe quello di iniziare con CouchDB e poi, se hai bisogno di qualcosa di più personalizzato, considerare di far girare il tuo.