Thanks for the details Luca. Just out of curiosity, are you planning to phase out HZ over time or are you generally satisfied with this solution?
Of course the challenge with load-balancing in a distributed environment (and probably moreso with a writeQuroum < totalNodes) is the trade-off between speed and "overhead" between nodes. In my experience, this is something that almost has to be left to the application (i.e. settable on a per-connection or maybe per-request basis), because without understanding what the application is trying to do with the underlying data, there really isn't any way for the database to make the decision. Is this your position as well, or do you feel that there is a better approach that can come closer to "automating" this? You say "it's straightforward implementing the reads that wait for locked resources in order to guarantee a stale record is never read". Is this something I can do now in my code or something that could be done within ODB or the orientjs driver? --Eric On Sun, May 8, 2016 at 12:51 PM, Luca Garulli <[email protected]> wrote: > On 8 May 2016 at 14:49, Eric24 <[email protected]> wrote: > >> Ah, very good. Thanks for that link (I don't think I had seen that page >> before). A couple of questions about some of those 2.2 details: >> 1) Is Hazelcast no longer used at all or are Hazelcast queues just not >> used for intra-node communications? >> > > We still use HZ for: > > - discovery of nodes > - configuration (HZ maps) > - distributed locks > > But for intra-communications we drop them in favour of something custom: > our binary protocol. Performance with 3 nodes are about 10x in v2.2 in > comparison to v2.1! > > 2) Is client-side load balancing supported on the node.js driver >> (orientjs)? >> > > OrientJs driver supports HA, so in case of crash it's able to > automatically switch to another available node, but load-balancing is not > yet implemented. > > >> 3) In a distributed application (say, 3 ODB nodes) where multiple >> end-client requests need to access and modify the same data (something like >> a session object in a multi-server web application), I'm concerned about >> consistency (i.e. end-client A updates a record when connected to node 1, >> then end-client B queries that record when connected to node 2, but gets >> stale data from before end-client A's update). I realize this is a common >> problem for any distributed system, but I don't fully understand ODB's >> consistency "guarantees". Assuming that writeQuorum is "majority", if node >> 1 and 2 both successfully commit the update, it is my understanding that >> end-client B will get the updated data (just as if it had connected to node >> 1), but what if node 2 fails the update (but node 3 successfully commits, >> thereby satisfying the writeQuorum)? What other scenarios should I watch >> out for (I'm keying on the comment about consistency mentioned in relation >> to per-request round-robin, but not per-connection round-robin, and I'm not >> sure why this would be particularly different)? Also, if the update is to >> just one record, is an explicit transaction of any kind needed here? >> > > You're free to use or not transactions, so single create/update/delete can > be executed distributed without transactions. > > Now in the scenario you pictured, a client could read a stale data during > distributed transaction commit/rollback. We decided to leave it like this > to avoid slowing down too much reads, but it's straightforward implementing > the reads that wait for locked resources in order to guarantee a stale > record is never read. > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB <http://orientdb.com/> > > >> >> >> On Sunday, May 8, 2016 at 4:55:26 AM UTC-5, l.garulli wrote: >>> >>> In v2.2 is not supported anymore in the meaning that hotAlignment is >>> ALWAYS on, look at: >>> https://github.com/orientechnologies/orientdb-docs/blob/master/Release-2.2.0.md#distributed >>> . >>> >>> Best Regards, >>> >>> Luca Garulli >>> Founder & CEO >>> OrientDB <http://orientdb.com/> >>> >>> >>> On 7 May 2016 at 17:35, Eric24 <[email protected]> wrote: >>> >>>> Is hotAlignment working now in 2.2? >>>> >>>> On Wednesday, April 29, 2015 at 2:02:07 AM UTC-5, l.garulli wrote: >>>>> >>>>> Hi, >>>>> Unfortunately hotAlignment is still not working, in the meaning that >>>>> cannot guarantee 100% consistency of database. >>>>> >>>>> We are working with Hazelcast team for a more efficient solution (more >>>>> reliable and much faster). This will be available in 2.2 (June 2015) or >>>>> lately 3.0 (summer 2015). >>>>> >>>>> Lvc@ >>>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Luca Garulli >>>>> CEO at Orient Technologies LTD >>>>> the Company behind OrientDB >>>>> http://about.me/luca.garulli >>>>> >>>>> >>>>> On 28 April 2015 at 23:34, S. Monkey <[email protected]> wrote: >>>>> >>>>>> The documentation for distributed architecture ( >>>>>> http://orientdb.com/docs/last/Distributed-Architecture.html) states >>>>>> that hotAlignment should be set to false as true can lead to >>>>>> inconsistency. >>>>>> >>>>>> Is this still the case in version 2.0.X (2.0.8 specifically)? >>>>>> >>>>>> If so, what is the correct way to configure a distributed database? >>>>>> If autoDeploy is set to true then it appears that whenever starting a >>>>>> node >>>>>> that joins a distributed cluster, the database is automatically deployed, >>>>>> even if the node was previously a member of the cluster. For a large >>>>>> database this could be problematic, but it seems this would be necessary >>>>>> without a mechanism like hotAlignment. >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OrientDB" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OrientDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/5NCen4Zxfjs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
