6 ms·

> whether you pick an RDBMS or NoSQL solution is mostly a tooling issue. Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team c

> whether you pick an RDBMS or NoSQL solution is mostly a tooling issue. Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team copies of Eric Evans and ask them to design data schema and sharding scheme such that any given entity has a bounded context that doesn’t join across the network. Probably then using a Merkle-like structure for shard selection. However as you say there’s no need to start like that. A big fat server can do a lot. It may be cheaper just to run a multi-TB database server and do everything in memory, than invest in re-engineering and all the flow-on operational costs of a distributed store. For sure a DBA would have an easier time tuning it, even if NUMA is in the mix. And building out a distributed store without restricting your ability to pivot requires more experience than almost anyone but the big clouds possess. edit/addendum: when you take a bounded-context domain-specific approach to your data persistence you will probably will still need to join things, but the option arises to do so periodically rather than on-demand, and in batches i.e it has more of a reporting flavour than OLTP, and work can be managed for quiet times or offloaded to map-reduce spot instances or whatever you like. From the outside it looks like an eventually-consistent application but only with regards to the parts that don’t need to change instantly.

deleted 6y ago
[deleted]
balfirevic 6y ago
> Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team copies of Eric Evans and ask them to design data schema and sharding scheme such that any given entity has a bounded context that doesn’t join across the network. That will only help you scale out to N servers, where N is the number of bounded contexts. And it might end up being less helpful than it sounds, if the scaling needs are dominated by data in one or two bounded contexts. Still, it could be a useful approach.
- inopinatus 6y ago
  No, the dimension is in the other axis. Otherwise there’d be no need for sharding keys.
  - balfirevic 6y ago
    But if you have nice natural sharding keys for your data (the most common example is something like TenantId), how do bounded contexts help? EDIT: Perhaps you mean something different by bounded context than what is usually meant in the context of DDD, where they separate groups of entities not data within those entities.
    - inopinatus 6y ago
      No, I mean exactly that, but tenant_id sounds like a SaaS or a Shopify. Their pods don’t have this kind of scale to begin with, the datasets just don’t have more than a few billion entities. Assuming there’s a “nice natural sharding key” at all already limits scope to a subset of applications, most of which you can stick inside a single instance, rendering the point moot.

deleted 6y ago

[deleted]

balfirevic 6y ago

> Eh, when the time comes to scale I’d still very likely pick a RDBMS but hand my team copies of Eric Evans and ask them to design data schema and sharding scheme such that any given entity has a bounded context that doesn’t join across the network. That will only help you scale out to N servers, where N is the number of bounded contexts. And it might end up being less helpful than it sounds, if the scaling needs are dominated by data in one or two bounded contexts. Still, it could be a useful approach.

inopinatus 6y ago
No, the dimension is in the other axis. Otherwise there’d be no need for sharding keys.
- balfirevic 6y ago
  But if you have nice natural sharding keys for your data (the most common example is something like TenantId), how do bounded contexts help? EDIT: Perhaps you mean something different by bounded context than what is usually meant in the context of DDD, where they separate groups of entities not data within those entities.
  - inopinatus 6y ago
    No, I mean exactly that, but tenant_id sounds like a SaaS or a Shopify. Their pods don’t have this kind of scale to begin with, the datasets just don’t have more than a few billion entities. Assuming there’s a “nice natural sharding key” at all already limits scope to a subset of applications, most of which you can stick inside a single instance, rendering the point moot.