모바일 앱의 데이터 동기화-여러 장치, 여러 사용자

첫 번째 모바일 앱을 구축하려고합니다. 응용 프로그램의 핵심 기능 중 하나는 여러 장치 / 사용자가 동일한 데이터에 액세스 할 수 있으며 모든 장치에 CRUD 권한이 있다는 것입니다.

아키텍처에는 모든 데이터가 저장되는 중앙 서버가 포함되어야한다고 생각합니다. 장치는 API를 사용하여 서버와 상호 작용하여 데이터 작업 (예 : 레코드 추가, 레코드 편집, 레코드 삭제)을 수행합니다.

데이터 동기화가 문제가되는 시나리오를 상상해보십시오. 인터넷에 연결되어 있지 않을 때 응용 프로그램이 작동해야하므로이 중앙 서버와 통신 할 수 없다고 가정하십시오. 그래서:

1. 사용자 A가 오프라인 상태이며 레코드 # 100을 편집합니다.
2. 사용자 B가 오프라인 상태이며 레코드 # 100을 편집합니다.
3. 사용자 C가 오프라인 상태이며 레코드 # 100을 삭제합니다.
4. 사용자 C가 온라인 상태가 됨 (아마도 레코드 # 100이 서버에서 삭제되어야 함)
5. 사용자 A와 B가 온라인 상태이지만 편집 한 레코드가 더 이상 존재하지 않습니다.

위와 비슷한 모든 종류의 시나리오가 나타날 수 있습니다.

이것은 일반적으로 어떻게 처리됩니까? MySQL을 사용할 계획이지만 그러한 문제에 적합하지 않은지 궁금합니다.

저는 현재 정확히 동일한 요구 사항과 문제로 모바일 / 데스크톱 / 분산 앱을 개발 중입니다.

우선, 이러한 요구 사항은 모바일 앱 자체에 국한된 것이 아니라 연결이 끊어 지거나 분산 된 클라이언트-서버 트랜잭션 (병렬 프로그래밍, 멀티 스레딩, 요점)에 있습니다. 따라서 모바일 앱에서 해결해야 할 일반적인 문제입니다.

일반적으로이 모든 것의 요약은 n 개의 클라이언트에 배포 될 수있는 잠재적 인 데이터 레코드가 있으며 동시에 편집 할 수 있다는 것입니다. 필요한 것은

1. 적절한 버전 관리 / 잠금 메커니즘
2. 적절한 권한 / 액세스 관리
3. 적절한 동기화 / 캐싱 전략

(1)의 경우 일부 패턴을 적용 할 수 있습니다. 자주 사용되는 잠금 전략에는 낙관적 오프라인 잠금 과 비관적 오프라인 잠금의 두 가지가 있습니다 . 이들 중 일부는 레코드가 변경 될 때마다 업데이트되는 모든 데이터 레코드에 대해 카운터 (매우 간단한 "타임 스탬프"정렬)를 사용하는 MVCC ( MultiVersion Concurrency Control) 와 같은 다른 버전 제어 "패턴"에 적용됩니다. .

(2)와 (3)은 (1)과 독립적으로 처리해야하는 매우 광범위한 문제입니다. 내 경험에 대한 조언 :

• 대부분의 문제를 추상화하는 클라이언트-서버 기술을 사용하십시오. (1) 낙관적 오프라인 잠금 + MVCC를 통해 (2) 웹 API를 통해 (3) Http 캐싱을 통해 잘 처리하는 CouchDb 와 같은 일부 웹 기술을 강력히 권장 합니다.

• 입증 된 기술과 접근 방식에 의존 할 수있는 경우 직접 발명하지 마십시오. 기존 기술 / 패턴을 연구하고 비교하는 데 시간을 투자하는 것이 자신의 시스템을 구현하는 것보다 훨씬 낫습니다.

• 가능하면 동종 기술을 사용하십시오. "균질"이란 웹 2.0 사용 시나리오와 같이 동일한 원칙을 염두에두고 구축 된 기술을 의미합니다. 예 : 로컬 캐싱 전략과 함께 적절한 CouchDb 및 REST 클라이언트 (웹 API)를 사용하는 것이 모바일 앱용 SQL을 사용하는 것보다 낫습니다.

• MySQL은 그러한 사용 시나리오를 위해 명시 적으로 만들어지지 않은 기술이기 때문에 MySQL 사용을 강력히 권장합니다. 작동하지만 웹 통신 및 동시성 스타일 (예 : 많은 NoSQL 데이터베이스)을 이미 수용하는 데이터베이스 시스템을 사용하는 것이 훨씬 좋습니다.

그건 그렇고, CouchDb API에 대해 작동하는 사용자 정의 로컬 클라이언트와 함께 CouchDb에 정착했습니다 .CouchDb API는 아름답게 작동하고 확장됩니다. 나는 MSQL + (N) Hibernate를 사용하지 않고 처음부터 올바른 선택을하지 못해서 (연구가 충분하지 않음) 높은 가격을 지불했습니다.

먼저 API와 데이터베이스 (MySQL)를 모두 언급했습니다. API를 사용하고 데이터베이스간에 직접 통신하려고 시도하지 않는 것이 좋습니다. 후자의 경로는 전혀 확장되지 않습니다.

고려해야 할 좋은 출발점 중 하나는 Apache CouchDB를 사용하는 것 입니다. HTTP 및 JSON을 기반으로하는 스키마가 없으며 매우 우수한 복제 메커니즘이 있습니다. 우리는 비슷한 문제를 해결하기 위해 그것을 사용합니다.

CouchDB의 복제 메커니즘은 다른 클라이언트가 사용하는 것과 동일한 HTTP API를 사용합니다. 본질적으로 API를 통한 복제를 제공합니다.

iOS의 경우 Couchbase Lite 프로젝트를 사용하는 것이 좋습니다 . 데이터 동기화에 매우 효과적입니다. Android의 경우, 앞서 언급 한 Couchbase Lite 프로젝트를 만드는 동일한 회사가 유사한 오퍼링 인 Android 용 Couchbase Lite를 개발하고 있습니다 . iOS 버전만큼 완벽하지는 않으며 달성해야 할 작업이 남아 있습니다.

그러나 CouchDB에는 몇 가지 고려해야 할 사항이 있습니다.

1. 자신의 갈등 해결을 제공해야합니다. 운 좋게도 충돌이 발생하면 CouchDB는 충돌하는 버전과 선택 및 임의적이지만 결정적인 충돌을 메인 버전으로 유지합니다. 따라서 초기 버전의 충돌 해결 지연을 고려할 수 있습니다.
2. 복제 메커니즘은 동기화 자체가 아닌 데이터베이스 복제를 위해 만들어졌습니다. 따라서 삭제 된 문서가 많은 경우 서버에서 클라이언트로 복제하는 데 시간이 오래 걸립니다. "데이터베이스 회전"을 사용하여이를 피할 수있는 방법이 있습니다. 이것은 기본적으로 오래된 삭제를 제거합니다.
3. 복제 순서를 제어 할 수 없습니다. 그러나 필터링 된 복제를 사용하여 일부 문서를 먼저 가져 오거나 주문형 서버에 직접 액세스하는 등 복제 성능을 향상시키는 영리한 솔루션을 만들 수 있습니다.
4. iOS의 백그라운드에서는 복제가 수행되지 않습니다. iOS SDK를 사용하여 일부 백그라운드 복제 사례를 제공 할 수 있습니다.

마지막으로 CouchDB를 사용하지 않으려면 적어도 HTTP API를 사용하여 동기화 알고리즘을 만드는 방법에 대한 좋은 참조로 CouchDB를 사용할 수 있습니다. 내 제안은 CouchDB로 시작한 다음 더 많은 사용자 정의가 필요한 경우 자신의 롤링을 고려하는 것입니다.