ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Ignite Client Affinity Questions
Date Fri, 26 Jul 2019 21:25:46 GMT
Folks, let me copy and paste a section from the new docs GridGain is
working on and will launch soon. That section compares thick vs thin
clients. Hopefully, it clarifies a lot.

*Ignite/GridGain clients come in several different flavors, each with
various capabilities. Thick and thin clients go beyond SQL capabilities and*
*support many more APIs. Finally, ORM frameworks like Spring Data or
Hibernate are also integrated with GridGain and*
*can be used as an access point to your cluster.*

*Let's review the difference between thick and thin clients by comparing
their capabilities.*

**Thick* clients (aka. standard clients) join the cluster via an internal
protocol, receive all of the cluster-wide*
*updates such as topology changes, are aware of data distribution, and can
direct a query/operation to a server node*
*that owns a required data set. Plus, thick clients support all of the
Ignite and GridGain APIs.*

**Thin* clients (aka. lightweight clients) connect to the cluster via a
public TCP/IP protocol with a well-defined*
*message format. This type of client supports a limited set of APIs
(presently, key-value and SQL operations only) but*
*in return:*

*- Makes it easy to enable programming language support for GridGain and
Ignite. Java, .NET, C++, Python, Node.JS, and*
*  PHP are supported out of the box.*

*- Doesn't have any dependencies on JVM. For instance, .NET and C++ _thick_
clients have a richer feature set but*
*  start and use JVM internally.*

*- Requires at least one port opened on the cluster end. Note, that more
ports need to be opened if*
*  partition-awareness is used for a thin client.*


--
Denis Magda


On Fri, Jul 26, 2019 at 6:21 AM Igor Belyakov <igor.belyakov.s@gmail.com>
wrote:

> Hi Nick,
>
> Yes, client node has up to date information regarding affinity and will
> use it to send request to the proper server node.
>
> If you're comparing client node to thin client then client node has more
> overhead since it's starting cluster node and processes discovery and
> communication events in the cluster, due to that it has information
> regarding affinity. On the other hand, the thin client sends all requests
> to the same server node and after that the request will be redirected to
> other nodes if it's necessary.
>
> Regards,
> Igor
>
>
>
> On Thu, Jul 25, 2019 at 6:37 PM milkywayz <nporillo@bandwidth.com> wrote:
>
>> Hello, I plan on using an Ignite node topology as follows:
>> 1) Application configured as an Ignite Client that handles distributing
>> requests to the correct server node.
>> 2) 3+ Partitioned Server nodes that handle cache storage and processing of
>> requests.
>> 3) Each server node has two caches which use AffinityKey for pinning
>> entries
>> in the two caches to one node for a given key.
>>
>> Questions:
>> 1) Will the client have up to date access to the AffinityFunction for the
>> two caches?
>> 2) What sort of overhead is associated with running as client mode? I want
>> to make it as dumb as possible, so it would only just be aware of topology
>> changes and always have the latest AffinityFunction for the partitioned
>> server node topology.
>>
>> Thank you, Nick.
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

Mime
View raw message