I have an extension to this question. I have the need for seperation of data not so much because of multi-tenancy and security but because the data is logically separable and would have a huge impact on performance if I can control the volume of data the queries have to refer to. Currently I have three solutions all with problems.
I can use separate databases as that's the best way to visualise the logical "partitions" I'm talking about but I have thousands of "projects" that need to be partitioned which would create scalability issues within the same server. Then the second is to have separate sets of classes for each partition with some naming convention for tagging the classes against each partition. Both of these solutions will add overhead in terms of managing schema and I'm keen to find out how many classes OrientDB can support in a single DB. The third option of using a cluster within each class for each project seems the most natural but fails since we cannot have cluster level indexes in OrientDB. Will the performance benefits of using clusters be lost by not having cluster level indexes? Any advice will be highly appreciated. This is a very common scenario in cloud based and/or high-scalable systems design. Ideally I need a light weight partitioning/clustering mechanism that does not require you to make compromises. On Tuesday, October 20, 2015 at 8:44:31 PM UTC+5:30, scott molinari wrote: > > Tenant data separation is a standard and huge main security concern, when > dealing with cloud computing infrastructure and that same concerns has to > be covered by the database as well. It isn't a specific need, it is a > necessity. > > 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.
