3 ms·

It's not SQL that is slow, but when you try and distribute a relational database you lose Referential integrity, Transactions, Unique Indexes and other such key

It's not SQL that is slow, but when you try and distribute a relational database you lose Referential integrity, Transactions, Unique Indexes and other such key features which are why you actually chose a relational database in the first place. I'm yet to see a database which does all of that and still is truly distributed.

jhugg 10y ago
VoltDB lets you keep transactions, and the strong consistency lets you enforce many constraints (though some in stored procedure code). Cluster-wide uniqueness has some limitations, but there are lots of tools we offer that are way better than nothing. Much of what you get in a relational DB, you can keep, and you can scale.
eterm 10y ago
I sometimes wonder if the "cloud first" mentality has led people to distributing databases way way before the need for it. I get that "big data" is in the in thing right now, but non-distributed databases still scale to huge amounts of data. I suspect there are plenty of services running over distributed servers instead of a couple of appropriately sized principal/witness servers. Beyond that, it's better to distribute by splitting databases across services or uses, so instead of having a mono-database running over a cluster, it's better for example to have an OLTP database and a separate OLAP database for reporting. It's easy to split those out to different servers rather than having a mono-database distributed over a cluster. Going beyond that, data partitioning is more sane, so you partition the data so that different sets of non-interacting data are in different places. So you can for example partition by customer, then each of those partitions can be arranged to different servers where appropriate for load. There shouldn't be a need to have transactions hitting more than one partition at once when partitioned correctly. And none of that breaks referential integrity.
- jhugg 10y ago
  Well, even for smaller use cases, systems with peer-to-peer clustering over a lan have better high-availability profiles than primary/secondary replication systems.

jhugg 10y ago

VoltDB lets you keep transactions, and the strong consistency lets you enforce many constraints (though some in stored procedure code). Cluster-wide uniqueness has some limitations, but there are lots of tools we offer that are way better than nothing. Much of what you get in a relational DB, you can keep, and you can scale.

eterm 10y ago

I sometimes wonder if the "cloud first" mentality has led people to distributing databases way way before the need for it. I get that "big data" is in the in thing right now, but non-distributed databases still scale to huge amounts of data. I suspect there are plenty of services running over distributed servers instead of a couple of appropriately sized principal/witness servers. Beyond that, it's better to distribute by splitting databases across services or uses, so instead of having a mono-database running over a cluster, it's better for example to have an OLTP database and a separate OLAP database for reporting. It's easy to split those out to different servers rather than having a mono-database distributed over a cluster. Going beyond that, data partitioning is more sane, so you partition the data so that different sets of non-interacting data are in different places. So you can for example partition by customer, then each of those partitions can be arranged to different servers where appropriate for load. There shouldn't be a need to have transactions hitting more than one partition at once when partitioned correctly. And none of that breaks referential integrity.

jhugg 10y ago
Well, even for smaller use cases, systems with peer-to-peer clustering over a lan have better high-availability profiles than primary/secondary replication systems.