I didn't say it should be used as a solution for multitenancy. I am just saying it can be used the same way as Tinkerpop's PartitionGraph.
The thing is, one shouldn't partition any GRAPH database, because it's basically impossible from the nature of graph (well it's possible but one woudn't really benefit from that). We use graph to represent very coherent data with complicated relations. We assume that all data in graph are (or can be at some point) related and can be effectively queried based on those relations. This assumption makes any partitioning problematic, because we can't predict how many partition will need to be involved in query (potentially all of them). Sure we can identify some subgraphs with higher cohesion than other parts of graph, but any time we would place that subgraph in separate partition, we would make queries involving more of those subgraphs a lot less effective. Adding parititon could enchance performance in one place, but it will horribly affect performance in other places. That might be bareble to some extend and for those situations there are clusters/PartitionGraph. It might happend that adding a partition, actually woudn't hurt a performance in any place, but that would imply that our data are incoherent and it's pointless to place those data in the same graph or use graph db whatsoever. Dne neděle 18. října 2015 13:13:53 UTC+2 scott molinari napsal(a): > > With clusters, maybe. When I think about it, you might be right. I am just > not sure how to create a class and a predefined cluster (for the customer) > at the same time. That would need to be possible, to do multi-tenancy. > > There is also a limit on the number of clusters, so that also means a > limit on the number of customers possible in one database. I'd also think > clustering at customer level should be possible too, so they can also take > advantage of the distribution of data. So, say each customer could have 100 > clusters available to them. That would allow 320 customers on a single > database. And let's say, one ODB server allows 50 databases only (keeping > with Luigi's suggestion), that would be 1600 customers on one ODB instance. > That could work, but for very small customers. Then we'd need to have a > scale up plan. Thus, why I'd like to keep it to one db per customer and > avoid the complication. > > I don't think classes would help partition data for multi-tenant purposes. > I'd also like to leave that feature to tenants, so each customer can work > with their own classes. > > One thing also open in my mind is if there is a limit on the number of > classes available. Is this congruent to the number of clusters available? > There is no mention of the number of classes available in a database on the > limits page. > > http://orientdb.com/docs/last/Limits.html > > 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
