Discussion:
Multi-tenancy via partitions in Datomic
Dave Dixon
2017-08-07 16:08:40 UTC
Permalink
It's been recommended to us that we handle multi-tenancy by putting each
customer in a dedicated partition. Does anybody have suggested code or
patterns for dealing with multi-tenancy, particularly on the transaction
side, for instance, ensuring that the logged in customer only transacts to
eid's in their partition. We have some code that does this, just curious
how it compares with best practices etc.

Dave
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Daniel Compton
2017-08-13 22:32:16 UTC
Permalink
Hi Dave

I can't remember where I saw this, but I think I've seen a recommendation
if you're using partitions like this, to make a fixed number of partitions
(32?), and then choose the partition you store to based on the hash of your
customer id, modulo 32.

The Datomic docs on partitions
<http://docs.datomic.com/indexes.html#partitions> say "These partitions act
as a coarse-grained grouping mechanism for entities, much as file cabinets
act as a coarse-grained grouping mechanism for paper files." Much like you
probably wouldn't buy a new file cabinet for each customer, you probably
don't need a new partition for each customer.

I'm not sure about the more general multi-tenancy aspect of Datomic, other
than to say I don't think it's possible to guarantee isolation without
transaction functions.

I wonder if you'd be better off creating a separate database for each
customer, if you don't have too many customers? My understanding of
partitions is that they are only an optimisation for data locality, not a
security mechanism, or one to build business logic around.

--
Daniel
Post by Dave Dixon
It's been recommended to us that we handle multi-tenancy by putting each
customer in a dedicated partition. Does anybody have suggested code or
patterns for dealing with multi-tenancy, particularly on the transaction
side, for instance, ensuring that the logged in customer only transacts to
eid's in their partition. We have some code that does this, just curious
how it compares with best practices etc.
Dave
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Stuart Sierra
2017-09-10 17:09:59 UTC
Permalink
Hi Dave,

The number of partitions is limited. Stuart Halloway has stated publicly
that Datomic will commit to supporting only up to 100,000 partitions
<https://groups.google.com/d/msg/datomic/3APx_6Shse4/_7hOA7vWsUkJ>,
although the current implementation appears to have room for up to 2^20.

There are no access constraints related to partitions: Any Peer can
transact in any partition, and entities can be linked via ref attributes to
entities in any partition. It really is just an optimization for storage.
But it is a useful optimization for multi-tenant applications, when
combined with load-balancing that directs each tenant to a consistent Peer
or set of Peers. That will maximize the benefit for each tenant of the
Peer-local ObjectCache.

If you have a small number of customers, you could create a partition for
each customer, otherwise you could create a fixed number of partitions and
group customers into them, as Daniel suggested.

--
Stuart Sierra
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hari Krishnan
2017-12-13 20:50:58 UTC
Permalink
H Stuart,

Thanks for the clarification. Question for you - how about creating a
database for each customer? Is it a better option? Or any downside to it?

Thanks for the response..

--Hari
Post by Stuart Sierra
Hi Dave,
The number of partitions is limited. Stuart Halloway has stated publicly
that Datomic will commit to supporting only up to 100,000 partitions
<https://groups.google.com/d/msg/datomic/3APx_6Shse4/_7hOA7vWsUkJ>,
although the current implementation appears to have room for up to 2^20.
There are no access constraints related to partitions: Any Peer can
transact in any partition, and entities can be linked via ref attributes to
entities in any partition. It really is just an optimization for storage.
But it is a useful optimization for multi-tenant applications, when
combined with load-balancing that directs each tenant to a consistent Peer
or set of Peers. That will maximize the benefit for each tenant of the
Peer-local ObjectCache.
If you have a small number of customers, you could create a partition for
each customer, otherwise you could create a fixed number of partitions and
group customers into them, as Daniel suggested.
--
Stuart Sierra
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...