Myślę, że problem jest odwołać się do [1]. Replikacja Cloudant jest w 100% kompatybilna z CouchDB. W tej instancji , dzienniki TouchDB wskazują stos sieciowy iOS przekazany na niekompletnym JSON do TouchDB. Nie jest jasne, kto w tym przypadku był winny za niepowodzenie replikacji.
[1] https://github.com/couchbaselabs/TouchDB-iOS/issues/241
Na pytanie kosztów, jednorazowym ciągnąć replikacja spowoduje dostać się do paszy _changes każdym razem to się dzieje, a także innych wniosków potrzebnych do powtórzeniach. To żądanie _changes zostanie policzone jako prośba HTTP o jasną na Twoje konto Cloudant.
Jednak to, czy działa to jako więcej czy mniej żądań, ogólnie zależy od liczby zmian, które przychodzą ze zdalnego serwera.
Ważne jest również, aby pamiętać, że liczba _changes połączeń są bardzo małe względem liczby zaangażowanych innych połączeń (np uzyskiwanie zawartości zmian sami, a szczególnie jeśli istnieje wiele załączniki).
Choć kwestia ta jest specyficzna dla TouchDB i wspominam konkretnych zachowań tym kodzie odpowiedź ta dotyczy wniosków zaangażowany w replikacji między dwoma dowolnymi systemami mówiących protokół CouchDB replikacji [2].
[2] http://www.dataprotocols.org/en/latest/couchdb_replication.html
Weźmy przykład contrived: 1 zmiana na 10 sekund okno źródłowa baza danych do replikacji, gdzie baza TouchDB jest celem. Weźmy 5-minutową ankietę a ciągłą replikację. Dla uproszczenia liczenia połączeń, pobierzmy także załączniki z obrazu . Przyjmujemy również, że urządzenie ma stałe połączenie sieciowe.
W przypadku pracy ciągłej co dziesiąta karta TouchDB będzie otrzymywać aktualizację w kanale dla kanału _changes. Powoduje to zamknięcie połączenia longpoll. TouchDB następnie przechodzi przez zmiany, żądając aktualizacji ze źródłowej bazy danych ; jedno lub więcej żądań GET na serwerze zdalnym. Podczas gdy tak się dzieje, TouchDB musi otworzyć kolejne longpoll żądanie do _changes.Tak więc w ciągu pięciu minut kończy się być może około 30 połączeń do _zmian, plus wszystkie połączenia, aby uzyskać dokumenty i zapisać punkty kontrolne .
Należy to porównać z replikacją jednorazową co pięć minut. Otrzymasz powiadomienie o 30 aktualizacjach w jednym ciągu danych _changes. TouchDB wdraża optymalizację [3] przy czym będzie to nazwać _all_docs dostać aktualizowane dokumenty dla 1- obrotach, więc może skończyć z jednym wezwanie, aby wszystkie 30 dokumentów (niemożliwe w przypadku ciągłego jak ty otrzymałem pojedynczą zmianę). Następnie masz dokumenty punktu kontrolnego do zapisania. W najlepszym razie mniej niż 5 wywołań HTTP, co najwyżej jedna trzecia z ciągłego przypadku, ponieważ uniknąłeś dodatkowych żądań _changes.
[3] https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm#performance
Wszystko sprowadza się do częstotliwości aktualizacji można oczekiwać, aby źródła bazie. Replikacja jednokrotna prawdopodobnie zapewni lepszą krzywą cenową, ponieważ daje lepszą kontrolę nad liczbą żądań.
Kolejne pytanie brzmi, jak często połączenia będą spadać z powodu rozłączenia sieci , które rozłączają się regularnie z urządzeniami mobilnymi. Ciągłe replikacje TouchDB będą odpalane za każdym razem, gdy użytkownik wejdzie na linię (jeśli zostanie dodany przez bazę danych _replicator). Jest to dodatkowe źródło nieprzewidywalnych kosztów.
Jednak korzyści z bardziej natychmiastowej widoczności zmian mogą z pewnością być warte niepewności.
"Chmura nie jest kompatybilna z ciągłymi replikacjami TouchDB." Dlaczego nie? – garbados
Mike odniósł się do kwestii niezgodności w swojej odpowiedzi. Jest to otwarty problem, który nie został jeszcze rozwiązany. Ani autorzy TouchDB, ani obsługa Cloudant nie byli w stanie określić, z jakiego źródła pochodzi problem, ale udało nam się go odtworzyć z względną łatwością. – airpaulg