The more important thing here is that "cluster" semantic can't be used anymore for generic grouping as this stated in the docs but means the node "thing" now. The main disadvantage is that it is impossible to group several classes inside some cluster even in local (non-distributed) mode. I'd prefer more clear definitions where clusters is not related to nodes, storage or so - it is just grouping term. It will be good to have the command like :
CREATE CLUST clust1 at NODES all NODESELECTION round-robin Next all needed classes can be tied to appropriately created cluster - it is much more clear than the current CPU's, nodes and default-distributed-db-config.json complex mess. вторник, 26 апреля 2016 г., 19:40:03 UTC+3 пользователь scott molinari написал: > > So, in distributed and with 2.2, the default is one cluster per node, per > class on master nodes. > > And on a single master and with 2.2, the default is one cluster per cpu > core per class. > > Is that correct??? What is the purpose of spreading out of a class with > more clusters per cpu core in a single master instance? > > Scott > -- --- 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.
