Thanks Evgenii
I am just trying to outline pros & cons of each with respect to my own
requirements.
I am reiterating my requirements
1. Most of out ignite consumers can consume rest services only.
2. And, we are just OK to Ignite as simple data grid which is primarily
used to read and write data, no bulk processing, all it should serve is
quick reads (high read)
3. Through put for read should be around 20K and above
4. High Availability
1. REST API
Pros: Built-in REST API features to query the data from the cache (no need
of any external development).
Cons:
a. Need to build POJO classes for each table and keep refreshing them as
and when your table structure changes
b. PUT does not work with REST API incase the value is a custom object
c. No FT and NO load balancing features at the moment, we only have an
option to mention the discovery URL of one Ignite node as part of the URL
d. No idea how it performs compared with others protocols ??
2. Thin Driver
Pros: Everyone is comfortable with SQL, easy to code. Fully SQL compliant
Cons: Fail over is not possible, since we only can give one ignite node port
as part of the discovery URL.
3. Thick Driver
Pros: Same as thin driver, everyone is comfortable with SQL, easy to code,
but some SQL features are not available. Load balancing & FB are available,
since we use the config XML
Cons: Some of the SQL features are not available
4. Java API
Pros: Performance may be better compared to others.
Cons: Every time a new cache is created or existing cache is altered, we
need to refresh the POJOs and update the classed on all ignite nodes
classpath.
Can you please put some light on this and suggest me the right approach and
the best practices for building the solution around ignite.
And, wish you a very happy and prosperous new year to all the Igniters
Thanks
Naveen
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
