Load balancing

[Pavel Kudrin]

As i understood multiple ShareJS servers can use shared database as common storage.

What about synchronization?
How another server undestand in same time, that document is changed, if OT request gone to first server through load balancer?

[David Greisen]

Hi,

ShareJS 0.7 uses redis's pub/sub functionality for this (http://redis.io/topics/pubsub). if two servers are both serving the same doc, they will both subscribe to and publish changes to that document through redis.

David

--
You received this message because you are subscribed to the Google Groups "ShareJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sharejs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Pavel Kudrin]

Ok, it fully explaines my question. Many thanks!

[Antony Chaporgin]

Hi! Are there any other scenarios of installation? You see, I cannot use redis, because I have a multi datacenter installation (redis is uppropriate here).

I am thinking about Kafka to use as a pub sub (cause I already have it installed), but it may be an overkill and may be there is something more appropriate.

среда, 31 июля 2013 г., 15:00:26 UTC+4 пользователь David Greisen написал:

[Joseph Gentle]

Not right now. Aside from pubsub, the OT model requires an ultimate source of truth to exist somewhere when deciding on the order of operations. I did however get a proof of implementation of livedb working built on top of foundationdb - github.com/josephg/livedb-foundation . Foundationdb has excellent scaling & replication properties, its is an excellent fit for the ShareJS data model and you can drop that in as a replacement. However, if you want to use it you'll need to do a bit of work first - its not ready for prime time:

- There are probably bugs
- The query code hasn't been ported across (this should be mostly a copy paste job from the original)
- it doesn't currently reuse watches (subscriptions) across multiple clients which are subscribed to the same document
- bulkSubscribe and bulkFetch haven't been implemented.

If you care enough, maturing the foundationdb implementation is your best bet if you want multi server scalability.

-J

[Antony Chaporgin]

Thanks for the quick answer! 

I am very new to this topic. 

As far as I understand from this paper: http://hal.upmc.fr/docs/00/55/55/88/PDF/techreport.pdf, the condition of ultimate source of truth is not obligatory, as long as all the ops are commutative. So you can have replicas, which eventually become consistent.

This is how I was looking at OT: you got a few processes, which listen to some queue (ops can be received partially ordeded) and they store the ops in their local storage (be it local memory/redis/mongodb/foundationdb... any of your choice). And the schema is the same is in mongodb installation of 0.6: ops collection and snapshots collection. Does this sound sane? Why is single source of truth obligatory?

And also, I liked the shema with mongodb as persistent storage and redis as op log (from 0.6). It's a pity, you decided to drop it. But it seems that it was caused by difficulties with the scalability requirement.

четверг, 21 ноября 2013 г., 0:42:24 UTC+4 пользователь Joseph Gentle написал:

[Joseph Gentle]

0.6 didn't support having the oplog & snapshots stored in different
places. That report is on CRDTs, which are a different set of
algorithms from the OT algorithms which sharejs uses. CRDTs have their
own set of tradeoffs - they don't require transformation and they work
better in distributed environments, but documents have to store
per-character metadata in perpetuity (even after the characters have
been deleted) - which adds bloat.

Dominic Tarr has a CRDT implementation in nodejs if you want to take a
look at it, but thats not how sharejs works.

-J

[Antony Chaporgin]

четверг, 21 ноября 2013 г., 3:37:21 UTC+4 пользователь Joseph Gentle написал:

0.6 didn't support having the oplog & snapshots stored in different
places. That report is on CRDTs, which are a different set of
algorithms from the OT algorithms which sharejs uses. CRDTs have their
own set of tradeoffs - they don't require transformation and they work
better in distributed environments, but documents have to store
per-character metadata in perpetuity (even after the characters have
been deleted) - which adds bloat.

As far as I know this is handled by sessions: you close session and delete all the history and replace it with a single op: "add all".

 

Dominic Tarr has a CRDT implementation in nodejs if you want to take a
look at it, but thats not how sharejs works.

Thank you for clearing that for me. It would took days to understand. So, Dominic's solution is not applicable for me too, because he has only three datatypes: a sequence of rows. This is not what I seek for: storing text documents in a row of chars would be not a good design.