e.g. what to store on the primary and secondary replica. On the primary replica the full data will be there, on the secondary replica only summary data will be stored (as well as cached query results).
My internal memory structure included big byte array blobs (or off-heap memory blobs) which I will be appending to via an insert as well as separate dictionaries to make sense of the binary blobs during queries. thanks, Gareth On Tue, Feb 16, 2016 at 4:07 PM, vkulichenko [via Apache Ignite Users] <ml-node+s70518n3045...@n6.nabble.com> wrote: > Hi Gareth, > > gcollins wrote > I guess the SpiQuery can help me part of the way potentially, but it > doesn't give me the control to manage internal memory structure, > replication, custom persistence etc. > > What kind of control do you expect? Can you give an example? In general, > almost everything in Ignite is customizable and pluggable. E.g., to > customize backup node assignments you can implement your own > AffinityFunction, for custom persistence implement CacheStore interface. > > Can you clarify what you mean by "internal memory structure"? Can you create > an Ignite cache (or caches) under the hood and provide your own APIs and/or > services around it? > > -Val > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://apache-ignite-users.70518.x6.nabble.com/Migrating-From-Hazelcast-Service-Interface-To-Apache-Ignite-Service-Interface-tp2970p3045.html > To unsubscribe from Migrating From Hazelcast Service Interface To Apache > Ignite Service Interface, click here. > NAML -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Migrating-From-Hazelcast-Service-Interface-To-Apache-Ignite-Service-Interface-tp2970p5812.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
