Hi Eugene, Let me help you with that as much as I can. Please help me understand the following:
- Is the cluster supposed to be deployed outside of Kubernetes (on VMs or bare-metal)? Is this a private cloud (OpenShift, PCF) or a public environment (Azure, AWS, etc.)? - If you use primary keys to access the records, do you really need SQL for this type of operations? Or do you perform additional filtering of records with SQL operands? In the meantime, please check this page to understand the pros and cons of thick and thin clients: https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients - Denis On Wed, Jun 10, 2020 at 1:07 PM Eugene McGowan <[email protected]> wrote: > Hi Igniters, > Our company has recently started using Ignite and our team are now to it. > We would like to use Ignite as a Cache layer for an upcoming project > > Our use case is that we have an Ignite cluster that we want to interact > with , our client service is Springboot based and running in a Kubernetes > Cluster but not co located with our Ignite cluster , we anticipate our > service will receive *3000+ request per second* , the service will scale > based on the volume of requests, and we will need to query Ignite for each > of these requests. > The data we need to query is fairly straight forward , a single row from > either 1 or 2 caches based on primary key. > We are at the point where we are beginning to design the architecture. > > I have done some initial reading on Ignite and was wondering if someone > could > Verify my understanding is correct. > > I would also be interested to know what architectures other folks are > using for similar use cases > > *=======* > *Thin Client* > ======== > JDBC connection are not thread safe > https://apacheignite-sql.readme.io/docs/jdbc-driver > To use this approach we need to ensure non cuncurrent use of > Connections, Statements, and ResultSet perhaps using a locking mechanism. > > Key value operations or SQL Queries via the API over the thin client are > thread safe > Connection Pooling is not provided via the API , but it is possible to > implement your own connection pool. > If you implement your own connection pool you could keep connections > alive to reduce > the cost of establishing a connection to Ignite and reusing > the connections for various requests. > > > ========== > *Thick Client * > ========== > > Does not have a concept of Connection pooling > > When using either JDBC or the IGNITE API on the Thick Client > It is thread safe and can handle multiple concurrent threads > > Is part of the Ignite cluster > Ignite Servers can iniatate TCP connection needs to be reachable via a > TCP connection > If the Client is behind a firewall,NAT or Load Balancer it makes using > ,thick client challenging > > > > ========= > *Question on GRPC* > ============= > > The Thin Client TCP socket connection uses a Binary protocol > https://apacheignite.readme.io/docs/binary-client-protocol > > I may be mixing up network levels here but , is it possible to run this > over a GRPC connection >
