Hi Luca, My proposal was aimed to have more clear database clustering levels that can be fully controlled by the database developer. It will be better to have the classes that can be arbitrary grouped by clusters but clusters further can be arbitrary grouped among nodes and their CPU's. For now I see that current approach has some limitations and mess :
- the clusters and their distribution became dependent from nodes and CPU's but not the database developer aims - the different classes cant belong to the same cluster though they have the cluster CRUD part (?) - the clusters selection is mystery with some predefined numbers - the clusters numbers space leaks the classes number space, making database applications less flexible BTW, what will happen if somebody will replace the 8 core CPU with say 16 cores (or 4) at the same node and restart the OrientDB ? среда, 27 апреля 2016 г., 3:08:08 UTC+3 пользователь l.garulli написал: > > Hi Scott and Sfinx, > > In v2.2 we create 1 cluster per core, so if you have 8 cores, they will be > 8. Now, if you run distributed, in full-replica mode (no sharding) those 8 > clusters will be distributed between those 8 nodes. You can define that the > cluster "client_usa" will be sticked to the USA server, otherwise it will > be OrientDB that will decide automatically who of these 8 nodes is the > owner. > > The owner is important just for creation of records (see the docs). > > Starting from v2.1 we ended up to restrict the usage of clusters to put > anything inside of it, but rather to rely each cluster to a class > (actually, they can still be binary clusters with no class). > > Sfinx, what the syntax above, what was your goal? > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB <http://orientdb.com/> > > > On 26 April 2016 at 19:40, Sfinx <[email protected] <javascript:>> > wrote: > >> 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] <javascript:>. >> 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.
