diff --git a/Thesis/Chapters/1. Theoretical Scope.typ b/Thesis/Chapters/1. Theoretical Scope.typ index e1b6244..a0ecef5 100644 --- a/Thesis/Chapters/1. Theoretical Scope.typ +++ b/Thesis/Chapters/1. Theoretical Scope.typ @@ -1,21 +1,21 @@ +#include "../style.typ" + = Zakres teoretyczny == Systemy współdzielenia dokumentów w czasie rzeczywistym -=== Ewentualna zbieżność -Budując rozwiązania związane z równoczesnym tworzeniem i modyfikacją jakichkolwiek danych przez więcej niż jednego użytkownika, musimy rozważyć mechanizmy zapewniające conajmniej ewentualną zbieżność (eventual consistency), która gwarantuje, że każda kopia danych w naszym systemie będzie identyczna i zawierała najnowszą zmianę u każdego klienta po otrzymaniu wszystkich zdarzeń modyfikujących dane. +Budując rozwiązania związane z równoczesnym tworzeniem i modyfikacją tekstu przez więcej niż jednego użytkownika, musimy rozważyć wyzwania napotykane w aktualizacji tworzonego dokumentu, gdzie każdy klient posiada lokalną kopię i nanosi na nie własne zmiany, ale też w międzyczasie musimy nanieść zmiany od pozostałych klientów. W takim systemie mówimy wtedy o zbieżności danych@article-eventually_consistent - czyli zapewnieniu tego samego stanu między każdym klientem. W przypadku edycji tekstu skupię się na ewentualnej zbieżności, która uwzględnia posiadanie rozbieżnych kopii tego samego źródła danych u każdego z klientów przez pewien czas. Dopiero gdy zostanie zakończona edycja tekstu, zmiany zostają propagowane i nanoszone do pozostałych klientów. Finalnie każdy klient po czasie posiada identyczną kopię dokumentu. Ze strony doświadczeń użytkowania jest to skuteczna strategia ze względu na możliwość zapewnienia płynności interfejsu graficznego oraz z pomocą złożonych mechanizmów umożliwia rozwiązywanie konfliktów między kopiami. -Popularną strategią w takim podejściu jest Last-Write_wins (LWW). To podejście, gdzie każde otrzymane zdarzenia są ułożone w pewnej kolejności, zazwyczaj opartej o czasie. Rozstrzyga ona konflikty poprzez nanoszenie tylko tej zmiany, która jest uznawana jako ostatnia w kolejności zbioru konfliktujących operacji. Ustalanie kolejności nie jest jasno tutaj zdefiniowane. W systemach baz danych takich jak Cassandra oraz SQL Server P2P każdy zapis otrzymuje własny znacznik czasowy, na podstawie którego wybierany jest najmłodszy wpis i nim nadpisywane są zmiany w źródle danych. Zmiany ze starszymi znacznikami są porzucane. Zauważalną wadą LWW jest wysokie ryzyko utraty danych w czasie nanoszenia zmian, ponieważ wszystkie starsze zmiany nie są brane pod uwagę. +Wspomniany model nie jest bez wad. Największym problemem jest istnienie konfliktów, których rozwiązanie klienci muszą ustalić za pomocą dodatkowych strategii. Najeczęściej wykorzystywaną jest Last-Write-Wins (LWW). Rozstrzyga ona konflikty poprzez nanoszenie tylko tej zmiany, która jest uznawana jako ostatnia w kolejności zbioru konfliktujących operacji. Ustalanie kolejności nie jest jasno tutaj zdefiniowane. W systemach baz danych takich jak Cassandra@other-apache_cassandra_documentation oraz SQL Server P2P@other-microsoft_sql_server_p2p_replication_documentation każdy zapis otrzymuje własny znacznik czasowy, na podstawie którego wybierany jest najmłodszy wpis i nim nadpisywane są zmiany w źródle danych. Zmiany ze starszymi znacznikami są porzucane. Zauważalną wadą LWW jest wysokie ryzyko utraty danych w czasie nanoszenia zmian, ponieważ wszystkie konfliktujące starsze zmiany nie są brane pod uwagę. -doi:10.1145/1435417.1435432 -https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html#data-versioning -https://learn.microsoft.com/en-us/sql/relational-databases/replication/transactional/peer-to-peer-transactional-replication?view=sql-server-ver17 -Designing data intensive applications - ISBN 1491903112, 9781491903117 +W przypadku tekstu jako typu danych, istnieje specjalny wariant ewentualnej zbieżności - silna ewentualna zbieżność. Ten model wykorzystuje specjalne struktury danych, które zapewniają bezkonfliktowe nanoszenie zmian, a ich skuteczność opiera się na matematycznych dowodach@article-verifying_strong_eventual_consistency. -=== Silna zbieżność -W przypadku systemów oferujących współbieżną modyfikację tekstu, gdzie możliwość wystąpienia konfliktów zwiększa się znacząco - przez większą ilość klientów oraz łatwy dostęp do obszarów aktualnie edytowanych przez innych użytkowników - powinniśmy rozważyć mechanizmy silnej zbieżności. +Istnieje również model silnej zbieżności, gdzie każdy z klientów musi mieć tą samą kopię danych przez cały czas pracy systemu. Ze względu opóźnienia i potrzebę mechanizmu blokady klientów przed wprowadzaniem zmian, ten model został porzucony w dzisiejszych systemach, ponieważ wspomniane problemy skutkowały gorszą użytecznością w porównaniu do systemów wykorzystujących ewentualną zbieżność. Istnieją jednak prace, które wskazują na istnienie systemów opartych o model silnej zbieżności, które osiągają bardzo niskie czasy opóźnienia, co redukuje problem używalności takiego rozwiązania w rzeczywistych zastosowaniach.@other-paxos_document_editor -// === Reprezentacja danych +== Algorytmy zapewniające silną ewentualną zbieżność +Podejście do rozwiązania problemu synchronizacji stanów między każdym klientem wymaga zaprojektowania algorytmu od podstaw skupionego na tym zagadnieniu. Przedstawię dwa najczęściej wykorzystywane algorytmy rozwiązujące opisany problem. -// === Wygoda użytkowania interfejsu graficznego +Operational Transformation (OT) polega na zamianie każdej wykonanej operacji na kodowalny obiekt, który może być propagowany i nanoszony na kopie w innych replikach. Większość znanych implementacji zakłada też, że istnieje scentralizowany serwer określający kolejność każdej operacji zgłaszanej przez wszystkich klientów i dystrybujący wspomniane zmiany do pozostałych replik. W przypadku wystąpienia konfliktu, operacje są sortowane przez serwer, a następnie każda z nich jest transformowana tak, by uwzględnić zmianę poprzedniej w kolejności operacji. Przykładowymi propozycjami algorytmów OT, których skuteczność nie została obalona dowodami, są: Jupiter@other-windowing_in_jupiter, SOCT3/4@other-convergence_in_distributed_real_time_collaborative_environment oraz TTF@other-transformation_functions_consistency_ces. Jupiter oraz SOCT3/4 wymagają wcześniej wspomnianego scentralizowanego serwera. Google Docs początkowo korzystał z Operational Transformation@other-google_docs_ot. Ze względu na złożność implementacji większość systemów nie korzysta dziś z tych algorytmów do synchronizacji danych, gdzie przykładem takiej decyzji jest Figma@other-figma_multiplayer. + +Następcą Operational Transformation są bezkonfliktowe replikowane typy danych (Conflict-free replicated data types - CRDT). Pozwalają one na nanoszenie zmian na własne kopie przez klientów, bez potrzeby uzgadniania tego z innymi klientami. Tak jak każdy algorytm ewentualnej zbieżńości, pozwala na tymczasową rozbieżność między replikami, ale po otrzymaniu wszystkich zmian przez każdego klienta, dane zawsze pozostają zbieżne. Przykładowymi algorytmami są RGA@article-replicated_abstract_data_types, WOOT@other-data_consistency_p2p_collaborative_editing oraz TreeDoc@other-commutative_replicated_data_type. // == Architektura Peer-to-Peer w środowiskach mobilnych // == Algorytmy synchronizacji tekstu diff --git a/Thesis/main.pdf b/Thesis/main.pdf index f57500a..e3526d4 100644 --- a/Thesis/main.pdf +++ b/Thesis/main.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:0c5f0a9d5e0d09add29d1dbdeeb3fa1d328b9324c4f2535df1decce4b11c93ed -size 77354 +oid sha256:86f7b117ff202221cbf8adfd707cc385d08928819007afabda93915d6af701e2 +size 134622 diff --git a/Thesis/main.typ b/Thesis/main.typ index 37498e2..fe4ed9b 100644 --- a/Thesis/main.typ +++ b/Thesis/main.typ @@ -12,5 +12,8 @@ #include "table_of_contents.typ" #pagebreak() -#include "Chapters/1. Theoretical Scope.typ" +#zut-template([ + #include "Chapters/1. Theoretical Scope.typ" +]) + #include "Bibliography.typ"