WIP - Theoretical Scope - Eventual Consistency
This commit is contained in:
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"soft_wrap": "editor_width",
|
||||
"project_name": "Praca dyplomowa inżynierska"
|
||||
}
|
||||
@@ -1,11 +1,28 @@
|
||||
= Zakres teoretyczny <teoria>
|
||||
== Systemy współdzielenia dokumentów w czasie rzeczywistym
|
||||
== Architektura Peer-to-Peer w środowiskach mobilnych
|
||||
== Algorytmy synchronizacji tekstu
|
||||
== Frameworki sieciowe udostępniane na platformach Apple
|
||||
=== Multipeer Connectivity
|
||||
=== Network
|
||||
== Analiza istniejących rozwiązań <analiza>
|
||||
=== Aplikacje zcentralizowane
|
||||
=== Aplikacje zdecentralizowane
|
||||
=== Problemy w istniejących rozwiązaniach
|
||||
=== 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.
|
||||
|
||||
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ę.
|
||||
|
||||
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
|
||||
|
||||
=== 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.
|
||||
|
||||
// === Reprezentacja danych
|
||||
|
||||
// === Wygoda użytkowania interfejsu graficznego
|
||||
|
||||
// == Architektura Peer-to-Peer w środowiskach mobilnych
|
||||
// == Algorytmy synchronizacji tekstu
|
||||
// == Frameworki sieciowe udostępniane na platformach Apple
|
||||
// === Multipeer Connectivity
|
||||
// === Network
|
||||
// == Analiza istniejących rozwiązań <analiza>
|
||||
// === Aplikacje zcentralizowane
|
||||
// === Aplikacje zdecentralizowane
|
||||
// === Problemy w istniejących rozwiązaniach
|
||||
|
||||
LFS
BIN
Binary file not shown.
+3
-1
@@ -1,7 +1,9 @@
|
||||
#import "style.typ": definition, example, theorem, zut-template
|
||||
|
||||
#include "title_page.typ"
|
||||
|
||||
#pagebreak(to: "odd")
|
||||
|
||||
#include "table_of_contents.typ"
|
||||
#pagebreak()
|
||||
|
||||
#include "Chapters/1. Theoretical Scope.typ"
|
||||
|
||||
Reference in New Issue
Block a user