[
https://issues.apache.org/jira/browse/GEODE-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh updated GEODE-4079:
-------------------------------
Description:
As discussed on the user and dev list, we should deprecate the Hash Index and
the corresponding Hash Index APIs.
The proposal:
Currently the Hash Index name causes confusion. It is not a traditional hash
look up index, but more of memory savings index. The index does not store
index keys in memory and must hash the keys every time. The index synchronizes
on a backing array and when the backing array needs to be expanded, it
currently needs to rehash all elements in the array. This can be very
problematic for larger data sets.
There were improvements made to one of the functional indexes (compact range
index) prior to open sourcing. These improvements helped reduce the memory
consumption of that index and makes it very similar sized to a hash index, but
the keys still are stored in memory. Probably close enough to be a replacement
for the hash index in most cases. The read/write performance on it is also
faster than the hash index.
This works includes:
Deprecating the Hash Index Class
Deprecating the createHashIndex API's in query Service
Deprecating the Hash Index type in IndexTypes (if possible)
Deprecating the gfsh commands to create hash index and hash index types
was:
As discussed on the user and dev list, we should deprecate the Hash Index and
the corresponding Hash Index APIs.
The proposal:
Currently the Hash Index name causes confusion. It is not a traditional hash
look up index, but more of memory savings index. The index does not store
index keys in memory and must hash the keys every time. The index synchronizes
on a backing array and when the backing array needs to be expanded, it
currently needs to rehash all elements in the array. This can be very
problematic for larger data sets.
There were improvements made to one of the functional indexes (compact range
index) prior to open sourcing. These improvements helped reduce the memory
consumption of that index and makes it very similar sized to a hash index, but
the keys still are stored in memory. Probably close enough to be a replacement
for the hash index in most cases. The read/write performance on it is also
faster than the hash index.
> Deprecate Hash Index and Hash Index APIs
> ----------------------------------------
>
> Key: GEODE-4079
> URL: https://issues.apache.org/jira/browse/GEODE-4079
> Project: Geode
> Issue Type: Bug
> Components: docs, querying
> Reporter: Jason Huynh
> Fix For: 1.4.0
>
>
> As discussed on the user and dev list, we should deprecate the Hash Index and
> the corresponding Hash Index APIs.
> The proposal:
> Currently the Hash Index name causes confusion. It is not a traditional hash
> look up index, but more of memory savings index. The index does not store
> index keys in memory and must hash the keys every time. The index
> synchronizes on a backing array and when the backing array needs to be
> expanded, it currently needs to rehash all elements in the array. This can
> be very problematic for larger data sets.
> There were improvements made to one of the functional indexes (compact range
> index) prior to open sourcing. These improvements helped reduce the memory
> consumption of that index and makes it very similar sized to a hash index,
> but the keys still are stored in memory. Probably close enough to be a
> replacement for the hash index in most cases. The read/write performance on
> it is also faster than the hash index.
> This works includes:
> Deprecating the Hash Index Class
> Deprecating the createHashIndex API's in query Service
> Deprecating the Hash Index type in IndexTypes (if possible)
> Deprecating the gfsh commands to create hash index and hash index types
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
