You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by nino martinez wael <ni...@gmail.com> on 2016/01/18 11:45:25 UTC

Would this be crazy?

Hi

We are considering using Ignite as a backend for our client / server
environment (for Ignites key/value store). IT's a telephony based
system, and the idea are that as a telephony CALL passes through the
system Ignite nodes will follow the call adding and manipulating data.
Each call would have it's own node cluster (as we don't need to share
data between calls). There could be a lot of concurrent calls, max
would probably be around 1000.

So the question are how does Ignite handle
* Cluster size of up to 1000 concurrent clusters (all based on a predicate)
* A cluster where nodes will come and go and probably are error-prone
* Realtime, it would be a problem if one node dies and the others have
to wait for confirmation of death etc
* OSGI, any issues?


Please ask if I need to rephrase some of my questions

-- 
Best regards / Med venlig hilsen
Nino Martinez

Re: Would this be crazy?

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Jan 18, 2016 at 3:45 AM, nino martinez wael <
nino.martinez.wael@gmail.com> wrote:

> Hi
>
> We are considering using Ignite as a backend for our client / server
> environment (for Ignites key/value store). IT's a telephony based
> system, and the idea are that as a telephony CALL passes through the
> system Ignite nodes will follow the call adding and manipulating data.
> Each call would have it's own node cluster (as we don't need to share
> data between calls). There could be a lot of concurrent calls, max
> would probably be around 1000.
>
> So the question are how does Ignite handle
> * Cluster size of up to 1000 concurrent clusters (all based on a predicate)
>

Most likely you mean 1000 nodes. Ignite has been known to be deployed in
1000+ node clusters. However, it sounds like you are trying to achieve data
isolation, so you may need to start up a cache per call, not a node per
call.

As Alexey suggested, once you describe your use case better, we will be
able to provide better suggestions.


> * A cluster where nodes will come and go and probably are error-prone
>

Ignite nodes can join and leave as needed. However, you should avoid
frequent topology changes, because likely there will be a background
rebalancing triggered every time a node joins or leaves.


> * Realtime, it would be a problem if one node dies and the others have
> to wait for confirmation of death etc
>

This generally does not happen in Ignite. Topology changes generally have
little effect on performance, as all the recovery and rebalancing happens
in the background and cluster continues to operate.


> * OSGI, any issues?
>

Ignite 1.5 added OSGI support. Not sure which issues you are concerned
with, but here are links to the documentation:

https://apacheignite.readme.io/docs/osgi-installation-in-karaf
https://apacheignite.readme.io/docs/osgi-supported-modules
https://apacheignite.readme.io/docs/osgi-starting-inside-a-container


>
> Please ask if I need to rephrase some of my questions
>
> --
> Best regards / Med venlig hilsen
> Nino Martinez
>

Re: Would this be crazy?

Posted by Alexey Goncharuk <al...@gmail.com>.
Nino,

Can you please elaborate why you want to start several nodes per call in
your architecture? Generally, the number of nodes is a factor of number of
machines you have, in rare cases you may need to start an Ignite client per
external call, however, usually it is not very effective.

If you describe your use-case in more details, the community may suggest
right architecture.

----
AG

Re: Would this be crazy?

Posted by nino martinez wael <ni...@gmail.com>.
The idea are that we will have 2 nodes per call in a telephony setup..
A primary node for external service calls and a secondary node to
follow the call around the system (agent/humans)..

This however can amount a lot..

On Mon, Jan 18, 2016 at 2:40 PM, Alexey Kuznetsov
<ak...@gridgain.com> wrote:
> Hi, Nino!
>
> I think it is quite crazy idea to setup 1000 concurrent clusters (if I
> understand you correctly).
> Starting 1000 nodes will be quite expensive.
>
> Could you please describe what business logic you are going to implement?
>
> It is not clear for me what are you expecting from Ignite and what Ignite
> components do you need.
>
> From first glance you need Ignite Compute (to do some computations with
> calls), but not need caching?
>
> If you need a compute only, I would recommend start 2-5 nodes and they will
> easily process such small number (1000) of tasks.
>
>
> On Mon, Jan 18, 2016 at 5:45 PM, nino martinez wael
> <ni...@gmail.com> wrote:
>>
>> Hi
>>
>> We are considering using Ignite as a backend for our client / server
>> environment (for Ignites key/value store). IT's a telephony based
>> system, and the idea are that as a telephony CALL passes through the
>> system Ignite nodes will follow the call adding and manipulating data.
>> Each call would have it's own node cluster (as we don't need to share
>> data between calls). There could be a lot of concurrent calls, max
>> would probably be around 1000.
>>
>> So the question are how does Ignite handle
>> * Cluster size of up to 1000 concurrent clusters (all based on a
>> predicate)
>> * A cluster where nodes will come and go and probably are error-prone
>> * Realtime, it would be a problem if one node dies and the others have
>> to wait for confirmation of death etc
>> * OSGI, any issues?
>>
>>
>> Please ask if I need to rephrase some of my questions
>>
>> --
>> Best regards / Med venlig hilsen
>> Nino Martinez
>
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com



-- 
Best regards / Med venlig hilsen
Nino Martinez

Re: Would this be crazy?

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Hi, Nino!

I think it is quite crazy idea to setup 1000 concurrent clusters (if I
understand you correctly).
Starting 1000 nodes will be quite expensive.

Could you please describe what business logic you are going to implement?

It is not clear for me what are you expecting from Ignite and what Ignite
components do you need.

>From first glance you need Ignite Compute (to do some computations with
calls), but not need caching?

If you need a compute only, I would recommend start 2-5 nodes and they will
easily process such small number (1000) of tasks.


On Mon, Jan 18, 2016 at 5:45 PM, nino martinez wael <
nino.martinez.wael@gmail.com> wrote:

> Hi
>
> We are considering using Ignite as a backend for our client / server
> environment (for Ignites key/value store). IT's a telephony based
> system, and the idea are that as a telephony CALL passes through the
> system Ignite nodes will follow the call adding and manipulating data.
> Each call would have it's own node cluster (as we don't need to share
> data between calls). There could be a lot of concurrent calls, max
> would probably be around 1000.
>
> So the question are how does Ignite handle
> * Cluster size of up to 1000 concurrent clusters (all based on a predicate)
> * A cluster where nodes will come and go and probably are error-prone
> * Realtime, it would be a problem if one node dies and the others have
> to wait for confirmation of death etc
> * OSGI, any issues?
>
>
> Please ask if I need to rephrase some of my questions
>
> --
> Best regards / Med venlig hilsen
> Nino Martinez
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com