So we have a use case where we need to push certain JSON to a
large number of users 100s of thousands and potentially can be in
millions.
So we can have channels may be in 100s and those users can subscribe to
those channels, but then we would be in a situation to
subscribe/unsubscribe to those channels which you mentioned is an expensive
operations. So out of following two , which one is a better design for
this kind of use case.
1. Create channels may be in 100s or even in thousands, and then subscribe
those users to specific channels ,and then JSON docs can belong to those
channels, but JSON would only be associated with a ten of channels,
which is fine I think , but then we would have issue to subscribing and un
subscribing the user from those channels, which you mentioned is an
expensive operation, how to handle this situation here ?
Also is there any limit in how many user can subscribe to a channel
2. We create one channels for each user so we have Millions of channels ,
one for each user. Now in this case each JSON would need to be
associated with Millions of channels, is there any limit on how many
Channel a JSON doc can belongs to ?
Also a question , since I am not very familiar with what kind of User are
being talked about when Sync gateway docs refer to a users, are those App
users, of a Custom App maintained users ?
Thanks
On Wednesday, February 10, 2016 at 1:30:58 PM UTC-5, Adam Fraser wrote:
>
> Jens is correct that channels are fairly lightweight, but there are a few
> additional details you may want to take into consideration while evaluating
> your design:
>
> 1. Adding/removing users to/from channels is a more computationally
> expensive operation than adding/removing documents to/from a channel. When
> a user is added to a channel, a Couchbase view call is required to
> recalculate that user's channel access. When a document is added to a
> channel, it's just an in-memory operation to add that to the cache for that
> channel. Frequency subscription/unsubscription from a channel is going to
> be a relatively expensive operation.
> 2. Sync Gateway maintains an in-memory cache of recent changes to a
> channel. That cache retains at least 50 entries (entries beyond 50 will be
> expire out of the cache). If most of your channels are shallow (<50 docs),
> it means that Sync Gateway will be attempting to cache a large fraction of
> your total docs in memory. This will probably need to be considered when
> sizing your SG node(s).
> 3. Although channels are lightweight, I'd still expect you to see some
> increase in CPU requirements as you increase the number of channels per
> user, particularly as you get into thousands of channels per user. Each
> replication is making a _changes request that's going to need to check each
> of those channels for changes.
>
> I don't think any of these are barriers to your design as described, but I
> wanted to share the details as additional context.
>
> Thanks,
> Adam
>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/bc913a14-ae0f-428f-919f-e9902e97176f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
