Hi Ignite experts,
Does Ignite support to query and index the embedded object column?
For example, I have a POJO "Organization" with a embedded object "Address"
as a column.
Below is the simple code to demo my thought.
public class Organization {
@QuerySqlField(index = true)
private Long id;
Tom,
I am not sure there is a memory leak at all because I have no idea what you
code is doing. I'm just guessing here, but without success so far. Looking
through code didn't give anything useful as well, it looks correct. So if
you need my help further, please provide something that will help
How about this OOME?
http://apache-ignite-users.70518.x6.nabble.com/Ignite-1-6-0-suspected-memory-leak-from-GridDhtPartitionMap2-td9504.html
We found it on another client node in the same cluster, however it seems to
exhibit a different pattern of memory leak.
- Tom
--
View this message in
Thanks Val,
That's a great feature. It will give some convenience like in HBase and
Cassandra.
-邮件原件-
发件人: vkulichenko [mailto:valentin.kuliche...@gmail.com]
发送时间: 2016年12月20日 9:23
收件人: user@ignite.apache.org
主题: Re: schemaless support
Hi Shawn,
You can dynamically change the schema
Hi Shawn,
You can dynamically change the schema when using binary format (default
format for storing data in Ignite):
https://apacheignite.readme.io/docs/binary-marshaller
However, with SQL this is not currently possible. DDL support is currently
in progress and will be ready sometime
Well, I need to reproduce it to investigate further. I tried to dig up in the
code, but do not see anything that can lead to memory leak, and even to so
many instances of CacheConfiguration in this map. Is it possible for you to
create a reproducer for this? That would be really helpful.
-Val
Hi,
Does ignite support "schemaless"?
For example, I just create an empty object with key and put an arbitrary
field to the object dynamically. The cache also can be queried with SQL.
Thanks
Shawn
Hi,
It looks like you're not subscribed to the list. Please properly subscribe
to the mailing list so that the community can receive email notifications
for your messages. To subscribe, send empty email to
user-subscr...@ignite.apache.org and follow simple instructions in the
reply.
As for the
I would also create indexes on 'id' fields at least. And do not forget to
check the execution plan [1] to make sure everything works as expected.
[1] http://apacheignite.gridgain.org/docs/performance-and-debugging
-Val
--
View this message in context:
Hi Randy,
There is no "must" for having indexes, but indexes in many cases can speed
up the execution. If you remove index from 'salary' field in the example, it
will still work, but will imply full scan. However, sometimes there can be
queries that do not benefit from any indexes. Like
Thanks, Alex. I understand that any SQL query relying on indexed data
would need to block until the data is loaded, else it could miss index
entries for important rows.
Do I understand that all Ignite SQL queries must use some index? In
context of a classic example scenario (
Hi Randy,
Currently, indexes are built only based on what is in cache - i.e.
contents of the backing store not present in cache are not presented
in index in any way, and hence yes, indexing blocks scanning.
Moreover, even non indexed columns in Ignite tables contain only data
actually loaded to
HI,
are there any recommendations (other than affinity) for complex queries
like below.
SELECT DISTINCT b.id, b.filename, a1.name
FROM a a1
JOIN b
ON b.id = a1.id
LEFT JOIN (select a.id, max(rank) latest from a group by a.id) a2
ON a2.id = a1.id
Thanks.
I do not see an memory issues at the model, but you should always remember
about cache overhead[1]
Size of any entry should be bigger than the 200 bytes.
[1]:
https://apacheignite.readme.io/docs/capacity-planning-bak#calculating-memory-usage
--
View this message in context:
14 matches
Mail list logo
