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>
|
= Zakres teoretyczny <teoria>
|
||||||
== Systemy współdzielenia dokumentów w czasie rzeczywistym
|
== Systemy współdzielenia dokumentów w czasie rzeczywistym
|
||||||
== Architektura Peer-to-Peer w środowiskach mobilnych
|
=== Ewentualna zbieżność
|
||||||
== Algorytmy synchronizacji tekstu
|
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.
|
||||||
== Frameworki sieciowe udostępniane na platformach Apple
|
|
||||||
=== Multipeer Connectivity
|
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ę.
|
||||||
=== Network
|
|
||||||
== Analiza istniejących rozwiązań <analiza>
|
doi:10.1145/1435417.1435432
|
||||||
=== Aplikacje zcentralizowane
|
https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html#data-versioning
|
||||||
=== Aplikacje zdecentralizowane
|
https://learn.microsoft.com/en-us/sql/relational-databases/replication/transactional/peer-to-peer-transactional-replication?view=sql-server-ver17
|
||||||
=== Problemy w istniejących rozwiązaniach
|
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
|
#import "style.typ": definition, example, theorem, zut-template
|
||||||
|
|
||||||
#include "title_page.typ"
|
#include "title_page.typ"
|
||||||
|
|
||||||
#pagebreak(to: "odd")
|
#pagebreak(to: "odd")
|
||||||
|
|
||||||
#include "table_of_contents.typ"
|
#include "table_of_contents.typ"
|
||||||
|
#pagebreak()
|
||||||
|
|
||||||
|
#include "Chapters/1. Theoretical Scope.typ"
|
||||||
|
|||||||
Reference in New Issue
Block a user