Re: Warning about java.time.Ser

Alexey, Yes, that does make sense. Thanks! -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Warning-about-java-time-Ser-tp2693p2717.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

Andrey, I'm not sure I understand the use case. What is physical and logical data model? How do they differ from each other? How will Ignite know where to execute the query if even the application doesn't know? It would be great if you provide a small example of such a data model and a query that

Re: Sql query performance with partitioned caches

Hi Valentin, The proposed option is not suitable. In most cases, the application does not know on which node and in which partition the data resides, as it is the physical layer of data model, which can change over time (application only knows the logical data model). The application simply exec

Re: Warning about java.time.Ser

I think it makes sense to add a native binary marshaller support for such types (at least for platform interoperability standpoint). I will create a ticket. 2016-01-26 3:31 GMT+03:00 vkulichenko : > Agree. I made a fix in master to ignore JDK classes when printing out this > warning. > > -Val > >

Re: Warning about java.time.Ser

Agree. I made a fix in master to ignore JDK classes when printing out this warning. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Warning-about-java-time-Ser-tp2693p2713.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Is there a way to get cache metrics for all the nodes in cluster combined

Hi Vinay, Here are my answers on your questions: 1. As Denis mentioned, metrics are collected from all nodes and they are sent in heartbeat messages. So it's possible that metrics for servers are not updated immediately on the client, but they will sync up eventually. If you add a sleep for 1-2 s

Re: Sql query performance with partitioned caches

Good point, Valentin! I will add that if you don’t have an affinity key, but simply know which node owns the data, you can also simply create a cluster group for that node and send a computation to it which will run the local query. On Mon, Jan 25, 2016 at 1:23 PM, vkulichenko wrote: > Hi Andrey

Re: Cross join bug for partitioned caches

Andrey, There is only one limitation in the current implementation: you have to make sure that joined entries are collocated and are stored on the same nodes. There are two ways to achieve this: 1. Using affinity [1]. Take a look at query example [2], it joins Person and Organization types both s

Re: Sql query performance with partitioned caches

Hi Andrey, In case you know that all required data is stored on a single node, you can send a closure to that node that will execute a local query: // Execute a callable on a node where myAffinityKey is mapped. ignite.compute().affinityCall("my-cache", myAffinityKey, new IgniteCallable>>() {

Re: Cross-cache query between replicated and partitioned caches

Hi, You must start(attach) your query on partition cache not replicated. cache.query() // cache must be partition cache -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cross-cache-query-between-replicated-and-partitioned-caches-tp2698p2707.html Sent from the Ap

Re: Sql query performance with partitioned caches

Hi Dmitriy, How about query that returns or scans less 1% of the rows (or only one row), and the rows that satisfy the query predicates all resides on one node? When we add nodes, such queries become slowly. Are there any plans for implementing for sql queries any kind of partitions or/and nodes

Re: Sql query performance with partitioned caches

Yes, this is correct, but this is not a performance issue, this is a performance gain. Your data set is split across the nodes and the indexes are also split in the same way. So, if you have 100GB of data and 10 nodes, then each node will end up with about 10GB of data. In this case, Ignite will e

Re: Is there a way to get cache metrics for all the nodes in cluster combined

On Mon, Jan 25, 2016 at 2:59 AM, Denis Magda wrote: > Hi, > > Metrics/statistics information is delivered from each node to another > across > the cluster with TcpDiscoverySpi.setHeartbeatFrequency. The default > frequency value is 2 seconds. So before acquiring cache.metrics( Grp>) from some nod

Re: Sql query performance with partitioned caches

Correct. Sergi 2016-01-25 18:39 GMT+03:00 Andrey Nestrogaev : > Hi All, > > Is any sql query, executed with partitioned cache, will always be executed > on every node where cache is deployed, irrespectively which predicates are > used or what indexes are created? > > > > -- > View this message i

Re: Cross join bug for partitioned caches

I will explore the possibility of adapting the sql based applications to use the ignite as a database. Therefore, I need to understand what sql can be used as is, and what the limitations and consequences and what you need to completely rewrite or replace with native api calls. -- View this mes

Re: Cross join bug for partitioned caches

If you need an ability to run ad-hoc SQL, then you're right and you need to have one PARTITIONED cache and all others should be REPLICATED. However, if you know your SQL queries in advance, usually you can some up with a collocation strategy for multiple PARTITIONED caches. I believe the community

Sql query performance with partitioned caches

Hi All, Is any sql query, executed with partitioned cache, will always be executed on every node where cache is deployed, irrespectively which predicates are used or what indexes are created? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-

Re: Cross join bug for partitioned caches

Collocation exactly means "to have all the joined entries on the same node". So basically you are right, for cross join it implies having all the data in replicated caches except one partitioned cache. Sergi 2016-01-25 18:08 GMT+03:00 Andrey Nestrogaev : > Hi Alexey, > > "Cross Join" doesn't imp

Re: Cross join bug for partitioned caches

Hi Alexey, "Cross Join" doesn't imply predicates for table joins, so how can collocation help with this type of join? Only workaround is to have all caches in repliacted mode except one. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cross-join-bug-for-partiti

Re: Cross join bug for partitioned caches

Hi Andrey, You need to properly collocate your data in order to have correct join results when using partitioned caches (it does not matter whether you join tables within one partitioned cache or join tables across different partitioned caches). Please refer to documentation [1] and example [2]. N

Re: Is there a way to get cache metrics for all the nodes in cluster combined

Hi Denis, Thanks for inputs. I took another run by putting thread sleep before printing metric and numbers are good now but issue 3 and 4 are still there. is keeping these numbers 0 in combined metrics from cluster intentional due to some reason? Vinay wrote > 3) putAvgTimeNanos=getAvgTimeNanos=

Cross join bug for partitioned caches

Hi all! Testing ignite 1.5. Seems, cross join on partitioned caches, when started more then 1 server node return incorrect result (part of the rows is missing). When started only one server node or caches in replicated mode all work correctly. -- View this message in context: http://apache-i

Warning about java.time.Ser

Hi, We are using Java 8 and when we define a cache that uses some of the new classes in the java.time package, so you get the warning: Class "java.time.Ser" cannot be written in binary format because it either implements Externalizable interface or have writeObject/readObject methods. Please... I

Re: Metrics for backup caches

Hi, CacheMetrics that are retrieved via cache.metrics() doesn't group statistics by backup and primary partitions. However, if you need to get size of backup data stored on a particular you can use the following call cache.size(CachePeekMode.BACKUP). -- Denis -- View this message in context:

Re: cache.getCacheManager() returns null.

I couldn't find any useful example on this. However, you can refer to this test that showcases how it works in practice https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachingProviderSelfTes

Re: Is there a way to get cache metrics for all the nodes in cluster combined

Hi, Metrics/statistics information is delivered from each node to another across the cluster with TcpDiscoverySpi.setHeartbeatFrequency. The default frequency value is 2 seconds. So before acquiring cache.metrics() from some node you should consider this delay. Please make a Thread.sleep() call an

Re: Sql Query using Map as value for cache

Hi Val, BinaryObject is what I was looking for. I've tested it and it suits for my task. Thank you very mach! -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-Query-using-Map-as-value-for-cache-tp2668p2688.html Sent from the Apache Ignite Users mailing list

Re: does DataStreamerImp addData method saves value in DataSource as well

Hi, Streamer just streams the data into a cache. If the cache has a data source configured then the streamed data (already received by the cache) will be propagated to the underlying storage as well. -- Denis On 1/25/2016 11:38 AM, Saurabh Sharma wrote: Hi, I would like to know if addData

does DataStreamerImp addData method saves value in DataSource as well

Hi, I would like to know if addData method of DataStreamerImpl class also saves value from cache to dataSource configured? Thanks, Saurabh