web-dev-qa-db-fra.com

Synchronisation des données dans les applications mobiles - plusieurs appareils, plusieurs utilisateurs

Je cherche à créer ma première application mobile. L'une des principales caractéristiques de l'application est que plusieurs appareils/utilisateurs auront accès aux mêmes données - et tous auront des droits CRUD.

Je crois que l'architecture devrait impliquer un serveur central où toutes les données sont stockées. Les appareils utiliseront une API pour interagir avec le serveur pour effectuer ses opérations de données (par exemple, ajouter un enregistrement, modifier un enregistrement, supprimer un enregistrement).

J'imagine un scénario où la synchronisation des données deviendra un problème. Supposons que l'application doit fonctionner lorsqu'elle n'est pas connectée à Internet et ne peut donc pas communiquer avec ce serveur central. Donc:

  1. L'utilisateur A est hors ligne et modifie l'enregistrement # 100
  2. L'utilisateur B est hors ligne et modifie l'enregistrement # 100
  3. L'utilisateur C est hors ligne et supprime l'enregistrement # 100
  4. L'utilisateur C se connecte (probablement, l'enregistrement # 100 devrait être supprimé sur le serveur)
  5. Les utilisateurs A et B se connectent, mais les enregistrements qu'ils ont modifiés n'existent plus

Toutes sortes de scénarios similaires aux précédents peuvent apparaître.

Comment est-ce généralement géré? Je prévois d'utiliser MySQL, mais je me demande si ce n'est pas approprié pour un tel problème.

databasemysqldatamobile
43
ProgrammerNewbie

Je travaille actuellement sur une application mobile/de bureau/distribuée avec exactement les mêmes exigences et problèmes.

Tout d'abord, ces exigences ne sont pas inhérentes aux applications mobiles en soi, mais à toutes les transactions client-serveur déconnectées/distribuées (programmation parallèle, multithreading, vous obtenez le point). En tant que tels, il s'agit bien sûr de problèmes typiques à résoudre dans les applications mobiles.

En général, tout cela se résume à ce que vous avez un enregistrement de données potentiel qui est distribué à n clients, qui peuvent le modifier en même temps. Ce dont vous avez besoin c'est

  1. un mécanisme de contrôle/verrouillage de version approprié,
  2. une bonne gestion des droits/accès,
  3. une bonne stratégie de synchronisation/mise en cache

Pour (1), vous pouvez appliquer certains modèles: Il existe deux stratégies de verrouillage fréquemment utilisées: Verrouillage hors ligne optimiste et Verrouillage hors ligne pessimiste . Certains d'entre eux sont appliqués dans différents "modèles" de contrôle de version, tels que MultiVersion Concurrency Control (MVCC), qui utilise un compteur (sorte de "timbre temporel" très simple) pour chaque enregistrement de données, qui est mis à jour chaque fois que l'enregistrement est modifié.

(2) et (3) sont des questions très larges elles-mêmes, qui doivent être traitées indépendamment de (1). Quelques conseils de mon expérience:

  • Utilisez une technologie client-serveur qui résume la plupart des problèmes pour vous. Je recommande fortement certaines technologies Web telles que CouchDb , qui gère (1) via Optimistic Offline Locking + MVCC, (2) via l'API Web et (3) via la mise en cache Http.

  • Essayez de ne pas inventer les choses vous-même si vous pouvez compter sur des technologies et des approches éprouvées. Je crois que toute heure passée à rechercher et à comparer les technologies/modèles existants est bien mieux dépensée que d'essayer de mettre en œuvre votre propre système (s).

  • Essayez d'utiliser des technologies homogènes si possible. Par "homogène", j'entends des technologies qui ont été construites avec les mêmes principes à l'esprit, par ex. scénarios d'utilisation du Web 2.0. Un exemple: l'utilisation d'un CouchDb approprié et d'un client REST (API Web) avec une stratégie de mise en cache locale est un meilleur choix que d'utiliser SQL pour les applications mobiles.

  • Je déconseille fortement l'utilisation de MySQL car c'est une technologie qui n'a pas été explicitement conçue pour de tels scénarios d'utilisation. Cela fonctionne, mais vous êtes beaucoup mieux avec un système de base de données qui embrasse déjà le style de communication Web et de concurrence (comme de nombreuses bases de données NoSQL).

Soit dit en passant, je me suis installé pour CouchDb avec un client local personnalisé fonctionnant avec les API CouchDb, qui fonctionne et évolue à merveille. J'ai abandonné l'utilisation de MSQL + (N) Hibernate et payé un prix élevé pour ne pas avoir fait le bon choix (c'est-à-dire ne pas faire assez de recherche) en premier lieu.

32
Sebastian

Tout d'abord, vous avez mentionné à la fois une API et une base de données (MySQL). Je vous recommande vivement d'utiliser une API et de ne pas essayer de communiquer directement entre les bases de données. Cette dernière voie ne sera pas du tout bien adaptée.

Un bon point de départ que vous devriez considérer est d'utiliser Apache CouchDB . Il est sans schéma, basé sur HTTP et JSON, et possède un très bon mécanisme de réplication. Nous l'utilisons pour résoudre un problème similaire.

Le mécanisme de réplication de CouchDB utilise la même API HTTP que tout autre client utilise. Donc, en substance, il fournit une réplication sur une API.

Pour iOS, je recommande d'utiliser le projet Couchbase Lite . Cela fonctionne très bien pour la synchronisation des données. Pour Android, la même société qui réalise le projet Couchbase Lite susmentionné travaille sur une offre similaire - Couchbase Lite pour Android . Elle n'est pas aussi complète que la version iOS et a encore du travail à accomplir.

Il y a cependant quelques points à considérer avec CouchDB.

  1. Vous devrez fournir votre propre résolution de conflit. Heureusement, si des conflits se produisent, CouchDB conserve les versions et les choix conflictuels et les conflits arbitraires mais déterministes à avoir comme version principale. Vous pouvez donc envisager de retarder la résolution des conflits pour votre version initiale.
  2. Le mécanisme de réplication est conçu pour répliquer des bases de données, pas pour la synchronisation en soi. Donc, si vous avez beaucoup de documents supprimés, votre réplication du serveur vers le client prendra de plus en plus de temps. Il existe un moyen d'éviter cela en utilisant la "rotation de la base de données". Cela supprime essentiellement les anciennes suppressions.
  3. Vous ne pouvez pas contrôler l'ordre de réplication. Vous pouvez cependant proposer des solutions intelligentes pour améliorer les performances de réplication, telles que l'utilisation de la réplication filtrée pour obtenir certains documents en premier, ou même accéder directement au serveur à la demande.
  4. La réplication ne se fera pas en arrière-plan sur iOS. Vous pouvez utiliser le SDK iOS pour fournir certains cas de réplication en arrière-plan.

Enfin, si vous ne souhaitez pas utiliser CouchDB, vous pouvez au moins l'utiliser comme une bonne référence pour savoir comment créer un algorithme de synchronisation à l'aide d'une API HTTP. Ma suggestion serait de commencer avec CouchDB et ensuite, si vous avez besoin de quelque chose de plus personnalisé, d'envisager de lancer le vôtre.

10
David V