Thanks Gregory.  I will look this further.

      From: Gregory Green <ggr...@pivotal.io>
 To: dev@geode.apache.org 
 Sent: Tuesday, February 21, 2017 12:21 PM
 Subject: Re: [GitHub] geode pull request #404: Geode 2469
   
Hello Everyone,

I just wanted to clarify something with this pull request.

The main benefit of the pull request changes is the 99.9% performance
improvements for SET and HASH related Redis command processing.

FYI - In order to support HA as has previously implemented, the default
region type has to be set as a type that supports HA such as
PARTITION_REDUNDANT,
REPLICATE, etc.

If administrators start the adapter to indicate an HA default data type as
the following.

start server --name=server1 --redis-bind-address=localhost --redis-port=11211
--J=-Dgemfireredis.regiontype=PARTITION_REDUNDANT.

The default type if not set is PARTITION, which as no HA support.

This change does not fundamentally change the way the Redis adapter handles
the created regions, but it does limit the number of regions created. The
new pull request creates two new regions RediS_SET and RediS_HASH use the
same conventions used by the current adapter Redis_STRING, Redis_HLL, etc
used in Geode 1.1.0 and GemFire 9.0.1.

Previously, the Redis adapter created a region for each key provided in a
Redis SET or HASH related command. This convention causes issues when
non-standard region name characters such as ":" exists in the key. The main
problem is Redis uses ":" in its key to indicated the object that the key
belongs with the format "object:key". For example, HSET companies:1000
means the object name is companies and its key if 1000. The pull request
changes will only create a new region if Redis "object:key" convention is
used in the HASH keys (otherwise the RediS_HASH region is used). So HSET
companies:1000 ... will result in a new region companies region created
with an entry key=100. Administrators can pre-create the region (ex:
companies) with the desired attributes. If the region is not pre-created it
will be created on demand with using the default region type.

On Sat, Feb 18, 2017 at 11:22 PM, ggreen <g...@git.apache.org> wrote:

> GitHub user ggreen opened a pull request:
>
>    https://github.com/apache/geode/pull/404
>
>    Geode 2469
>
>    The updated Geode Redis Adapter now works with a sample Spring Data
> Redis Example
>    [GEODE-2469.pdf](https://github.com/apache/geode/files/
> 785580/GEODE-2469.pdf)
>
>    These changes are focused on the HASH and Set Redis Data Types to
> support Spring Data Redis sample code located at the following URL
>
>    https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/tree/person_example_sdg_Tracker139498217/redis/
> spring-data-redis-example/src/test/java/io/pivotal/redis/
> gemfire/example/repository
>
>    The Hash performance changes from this pull request had a 99.8%
> performance improvement.
>
>    This is based on the Hashes JUNIT Tests.
>
>    https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> HashesJUnitTest.java
>
>    This code executed in 12.549s against Gemfire 9.0.1 code. After the
> changes, the test executed in 0.022s with the GEODE-2469 pull request.
>
>    Redis Set related command performance had a 99.9% performance
> improvement.
>
>    See  https://github.com/Pivotal-Data-Engineering/gemfire9_
> examples/blob/person_example_sdg_Tracker139498217/redis/
> gemfire-streaming-client/src/test/java/io/pivotal/gemfire9/
> SetsJUnitTest.java
>
>    The previous Set Junit tests executed against GemFire 9.0.1 executed
> in 31.507 seconds. These same test executed in 0.036 seconds with the
> GEODE-2469 pull request changes.
>
>    The GemFire 9.0.1 Geode (1.1.0) version for the Geode Redis adapter
> created a Geode Region for each key provided in the Redis Hash or Set
> related command. Each Redis command to remove key entry previously
> destroyed the region. The big performance gain is based on using a new
> ReDiS_HASH and ReDiS_SET region. Note the changed will create or reuse an
> existing region with a matching name for Redis HASH commands references
> objects. For Redis HASH object's key will have a format of object:key
>
>    Please see https://redis.io/topics/data-types-intro HASH section on
> objects for information on Redis objects.
>
> You can merge this pull request into a Git repository by running:
>
>    $ git pull https://github.com/ggreen/geode GEODE-2469
>
> Alternatively you can review and apply these changes as the patch at:
>
>    https://github.com/apache/geode/pull/404.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
>    This closes #404
>
> ----
> commit 44b90c4f3f8e1ec4fdae63a8be126982d7c837a2
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-14T20:31:49Z
>
>    GEODE-2469 initial changes to support Redis objects
>
> commit 27d7600e85945a7134115630efe378ed43d980f8
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-17T00:26:11Z
>
>    GEODE-2469 changes to corrected introduced issue found during JUNIT
> runs
>
> commit a4ee164ddc944e8eed93c28d2db798c222a21cd4
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-17T00:27:55Z
>
>    Merge branch 'develop' into GEODE-2469
>
> commit d5191fb5cd10df1c9c2f34399b849d8bbf8c5bf7
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-18T21:14:02Z
>
>    GEODE-2469 add additional junit test coverage
>
> commit 0b3bf689b835628b8573a49e3f0bb2900d07ff1c
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-18T21:14:33Z
>
>    GEODE-2469 add additional junit test coverage
>
> commit 1958b1e129ab22be6dbb2d347fb189718fa5f8c4
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-18T21:15:44Z
>
>    Merge branch 'develop' into GEODE-2469
>
> commit 628f5093d32a272f7515bdd0953f90e91f559ec7
> Author: Gregory Green <ggreen@ggreenmac.local>
> Date:  2017-02-19T02:24:26Z
>
>    GEODE-2469 adding licenses to fix RAT issues
>
> ----
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>



-- 
*Gregory Green* (Senior Data Engineer)
ggr...@pivotal.io
201.736.1016


   

Reply via email to