Synchronous replication and performance

[Shahar]

Hi,
I understand that replication in Hazelcast is synchronous, so for each
Map.put(k): k will be replicated n times (n = number of backups), sent
to the owner and backup nodes (which means n round trips in worst
case scenario) and only then the method call will return. Is that
correct? As a result latency becomes also a function of the number of
backups configured, and might be significantly degraded if number of
backups is high.

I presume that you chose to make replication synchronous to provide
greater consistency. But what about use cases where consistency is
less important (eventual consistency being good enough) and
performance is key? Is there a way to configure Hazelcast to perform
async. backup?

Thanks,
Shahar

[Shahar]

On second thought value-consistency has nothing to do with replication
because data is not read from backups by default. So the only
consistency in stake here is the one between the client (that inserts
\updates values) and the cluster, right? Anyway, my question still
holds because whatever the reason is for sync. replication,
performance is still affected.

Thanks,
Shahar

[Fuad Malikov]

Currently we don't support asynchronous backup. It is not about consistency, rather is about redundancy. If a single node failure we don't loose any data. As you said this is achieved by giving up from update performance. In the future we may add an option for asynchronous backup. It is not on our priority list yet.

Regards,

Fuad Malikov
Sent from Mobile

> --
> You received this message because you are subscribed to the Google Groups "Hazelcast" group.
> To post to this group, send email to haze...@googlegroups.com.
> To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.
>

[Shahar]

Thanks Fuad.

I understand from the documentation that it's possible to read entries
from backup nodes. I presume that it might boost performance, but can
you explain how it might affect consistency?

[Mehmet Dogan]

By default Hazelcast fetches data from owner node of entry, all requests related to that data are routed to owner.

If reading backup value is enabled  and node of local operation has backup of requested data, then instead of routing request to owner node, value is read from local backup.

Regarding consistency, there is possibility of reading stale data. Hazelcast's read operations are lock free (assuming transactions are not used). While an update operation is being executed, there might be a moment that a read is requested before backup data is updated to latest value. So, although value on the owning node is updated, one can read an older version of value on backup node in a short period.

@mmdogan

[Shahar]

Thanks. That makes perfect sense.

On Jan 8, 12:02 pm, Mehmet Dogan <meh...@hazelcast.com> wrote:
> By default Hazelcast fetches data from owner node of entry, all requests
> related to that data are routed to owner.
>
> If reading backup value is enabled  and node of local operation has backup
> of requested data, then instead of routing request to owner node, value is
> read from local backup.
>
> Regarding consistency, there is possibility of reading stale data.
> Hazelcast's read operations are lock free (assuming transactions are not
> used). While an update operation is being executed, there might be a moment
> that a read is requested before backup data is updated to latest value. So,
> although value on the owning node is updated, one can read an older version

> of value on backup node in a short *period*.