Re: [orientdb] Best way to host many orient databases

[scott molinari]

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, is 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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

In a multi-tenant system, which this thread is about, the data between 
tenants must be partitioned. That is the kind of partitioning we are 
talking about. Not a logical differentiation, but rather, physical 
separation. 

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.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

And thinking some more about the user permissions as a way to partition the 
user service data, unfortunately that won't work either. The limit of 
classes/ clusters would mean a limit on tenants, despite the ability to 
partition their vertexes and edges.

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.

Re: [orientdb] Best way to host many orient databases

[Jan Plaček]

Doesn't it already in a way of classes and clusters?

Dne sobota 17. října 2015 10:59:41 UTC+2 scott molinari napsal(a):
>
> Would OrientDB also support graph partitioning in some way, like TitanDB 
> offers, through Tinkerpop's Blueprint PartitionGraph?
>
> https://github.com/tinkerpop/blueprints/wiki/Partition-Implementation
>
> 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.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

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.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

I also just found this in the documentation about graph partitioning.

http://orientdb.com/docs/last/Partitioned-Graphs.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.

Re: [orientdb] Best way to host many orient databases

[Jan Plaček]

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.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

Well, the whole idea of partitioning is to arrive at data separation. So 
clearly, if you want a graph to be homogenic, it can't be partitioned. 

Reading the ODB partitioning section, partitioning through the user 
permissions system sounds like a pretty good answer to the problem. In 
fact, for our "user service", I've been wondering how we can partition the 
user data, but still have all users available for global (above the tenant 
level) querying purposes, as we want to also have a user "network" across 
all tenants (which is a tricky situation, I know). The user role system 
sounds like a great fit for this.

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.

Re: [orientdb] Best way to host many orient databases

[scott molinari]

Would OrientDB also support graph partitioning in some way, like TitanDB 
offers, through Tinkerpop's Blueprint PartitionGraph?

https://github.com/tinkerpop/blueprints/wiki/Partition-Implementation

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.

Re: [orientdb] Best way to host many orient databases

[Luigi Dell'Aquila]

Hi Michael,

there is not general rule, just because it depends a lot on how many
requests per second will every db have, how many data it will contain, how
complex your queries are and so on.
As a rule of thumb, I would not go over a few tens of (small) databases per
instance, just because CPU, RAM, IO and disk are limited resources and they
have to be shared.

Thanks

Luigi


2015-10-14 23:43 GMT+02:00 Michael MacFadden :

> Hello,
>
> For our architecture we are contemplating something like multi-tenancy.
> In our approach each tenant would get their own database.  When I say
> database, I don't mean server.  I mean a database within an OrientDB server.
>
> The question is... Is there a best practice way to do this.  The three
> options we see are:
>
> 1) Stand up an entire OrientDB server to host a single database.
> This seems inefficient.  Especially since we are going to look towards a
> clustered / replicated architecture.
>
> 2) Put multiple databases into a single OrientDB Server
> Here I am curious as to scalability.  Is there a practical limit to how
> many databases a single OrientDB cluster can hold?  Each tenant may make
> many connections to the database.  If say each tenant makes 20 or so
> database connections and we have 1,000 tenants, I now have 20,000
> connections going to the database.  Obviously we would have many servers
> supporting this load so that would be distributed.
>
> 3) Some middle ground where we have a certain number of tenants hosted in
> each clustered instance of OrientDB
> Not sure how to draw the line here.
>
> Just wondering if there are best practices around this?  Thanks and keep
> up the good work.
>
> --
>
> ---
> 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.
>

-- 

--- 
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.

[orientdb] Best way to host many orient databases

[Michael MacFadden]

Hello,

For our architecture we are contemplating something like multi-tenancy.  In 
our approach each tenant would get their own database.  When I say 
database, I don't mean server.  I mean a database within an OrientDB server.

The question is... Is there a best practice way to do this.  The three 
options we see are:

1) Stand up an entire OrientDB server to host a single database.  
This seems inefficient.  Especially since we are going to look towards a 
clustered / replicated architecture.

2) Put multiple databases into a single OrientDB Server
Here I am curious as to scalability.  Is there a practical limit to how 
many databases a single OrientDB cluster can hold?  Each tenant may make 
many connections to the database.  If say each tenant makes 20 or so 
database connections and we have 1,000 tenants, I now have 20,000 
connections going to the database.  Obviously we would have many servers 
supporting this load so that would be distributed.

3) Some middle ground where we have a certain number of tenants hosted in 
each clustered instance of OrientDB
Not sure how to draw the line here.

Just wondering if there are best practices around this?  Thanks and keep up 
the good work.

-- 

--- 
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.