hazelcast support

[deadjoe]

Any plan to support hazelcast?

Thanks

[busbey]

We are happy to add support for any data store that we get a contribution for. I have not seen any specific work for it though.

[deadjoe]

Thanks for reply, does it mean i should write my own implementation in YCSB for hazelcast cluster?

[busbey]

That would be wonderful, I'm fairly certain the current maintainers aren't familiar with it. We'd be happy to get a pull request with an implementation.

[bwzhang2011]

@busbey, any update with such issue ?

[busbey]

As far as I know, noone has created a hazelcast binding for YCSB yet. We'd still be happy to get one.

[bwzhang2011]

@busbey, it's better to be achieved officially as hazelast became much popular during data grid framework.

[gokhanoner]

We want to create a Hazelcast binding with my colleague(we're from Hazelcast). Updating this thread so everyone interested can see.

Just one question: We see different implementations of update method. Redis client just writes the map to the Redis (replace the old map with the new one), Infinispan client get the old values & update only the filed in the map, without touching the other fields. We believe this is the correct implementation but wanted to be sure before starting the implementation.

Thanks

[busbey]

Hi @gokhanoner are y'all still up for adding a hazelcast binding?

Unfortunately, as you noted the current bindings are inconsistent. I'd agree that the Infinispan implementation you mention is the correct one. I'm not sure if our "validate the data written" mode currently will catch implementations that aren't maintaining the unmodified fields.

[gokhanoner]

@busbey, sure I already created a Hazelcast binding & testing. I’ll create a PR shortly

[busbey]

yay!

[iamankit1995]

any new update on this @gokhanoner ?

[gokhanoner]

@iamankit1995 yes, trying to complete my tests so I can send the PR. I believe next week I'll send it.

[gokhanoner]

A question to the interested parties:

I nearly finished the implementation but:

• Starting with Hazelcast 3.6, all members are backward/forward compatible. So you can connect to 3.6 cluster using 3.10 client or vice-versa.
• To get the benefit or newer Hazelcast features, I introduced Partial update & Partial Read, which will only return the necessary information from members instead of returning all & filtering on the client side. But for that to work, you need to add the ycsb-hazelcast.jar to members classpath (for HAzelcast clusters < 3.9) or enable User Code Deployment feature on the members (>= 3.9)
• Also, partial update uses a feature called EntryProcessor which is introduced in 3.0, with another optimization which introduced in 3.8.1.

I don't want to create 2-3 different Hazelcast packages just for that. So I can limit it for Hazelcast >= 3.9 for the partial update & partial read.

What is your idea?

[busbey]

Since we haven't released any versions with Hazelcast support before, I think whatever version compatibility you want to provide is fine provided we document it.

[gokhanoner]

Perfect. I'll finish the tests quickly, create the Readme & create the PR this week, as promised.

[gokhanoner]

Just returned from the Labor day weekend & working on this to complete.

[DominicRoehm]

@gokhanoner I was looking to benchmark hazelcast with YCSB. Is your code anywhere available?