11–20 of 44 posts
Earlier quoted context omitted.
There's cockroachdb which is roughly open source spanner you can deploy on your own systems.
Which has still horrible join performance, and several other tradeoffs. (see https://www.cockroachlabs.com/blog/cockroachdbs-first-join/ ) Maybe in a year, or two. But not today.
Earlier quoted context omitted.
Which has still horrible join performance, and several other tradeoffs. (see https://www.cockroachlabs.com/blog/cockroachdbs-first-join/ ) Maybe in a year, or two. But not today.
That blog post is from a year ago. And since Cockroach DB 1.0 was only released in May this year, it's a bit misleading to link to that post as though it was the current state of the sofware.
See: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...
Earlier quoted context omitted.
Indeed, the trend is clear, but for now, nothing has changed. Google's implementation is not very helpful to all those companies, individuals, NGOs, and governments that have to follow privacy laws, HIPAA, etc though, because Google's implementation isn't open source, and these entities can't use Google Cloud. Or don't want to. Until we get an open source solution for this, SMP machines will be useful. And even then,…
Uhhhh... most orgs that run HIPAA workloads do so slavishly on Windows and EPIC, neither of which are famously what most would consider open source.
Earlier quoted context omitted.
There's cockroachdb which is roughly open source spanner you can deploy on your own systems.
Which has still horrible join performance, and several other tradeoffs. (see https://www.cockroachlabs.com/blog/cockroachdbs-first-join/ ) Maybe in a year, or two. But not today.
Earlier quoted context omitted.
Uhhhh... most orgs that run HIPAA workloads do so slavishly on Windows and EPIC, neither of which are famously what most would consider open source.
You’re right, the real distinction is on-premises vs off-premises, I should have made that more clear (although free software implies on-premises being possible)
Google, and Amazon, and MS, undergo extensive third-party audits and people can, and do, run HIPAA workloads there.
I’m not sure what distinction you are trying to draw.
This was a lot of fun, one of the things that doesn't get much air time is that back in the early 2000's when "clusters" and "NUMA SMP machines" were competing with each other the big argument for large SMP iron was ACID compliant SQL databases like Oracle. Now that Google has implemented an ACID compliant SQL database across clusters it puts the final nail in the argument (for me at least) that "Some things only wor…
Distributed ACID transactions across multiple DBs or clusters has been possible for a while if you have been willing to pay the latency penalty for the transaction to complete, hasn't it? As far as I know, Google systems have to pay this latency cost too. From an analysis of Spanner and Calvin [1]: > The cost of two-phase commit is particularly high in Spanner because the protocol involves three forced writes to a lo…
I think this understates it. Production distributed systems suck balls with unreliable infrastructure, and anyone who has ever tried to do realtime replication of all of their data (and lots of it) across the internet knows how completely unrealistic it is. It's like running a power cord across a highway to power a refrigerator.
Earlier quoted context omitted.
You’re right, the real distinction is on-premises vs off-premises, I should have made that more clear (although free software implies on-premises being possible)
I’m still confused... most orgs running HIPAA workloads are still doing so on prem, AND using very much non-free software. Google, and Amazon, and MS, undergo extensive third-party audits and people can, and do, run HIPAA workloads there. I’m not sure what distinction you are trying to draw.
So either we need an on-prem version of Cloud Spanner, Cloud Spanner needs to be HIPAA certified, certified to match German privacy laws, etc, or Cloud Spanner can’t serve these situations.
This was a lot of fun, one of the things that doesn't get much air time is that back in the early 2000's when "clusters" and "NUMA SMP machines" were competing with each other the big argument for large SMP iron was ACID compliant SQL databases like Oracle. Now that Google has implemented an ACID compliant SQL database across clusters it puts the final nail in the argument (for me at least) that "Some things only wor…
Did you mean Numa vs SMP? Or something else maybe? How can a machine be a NUMA SMP? NUMA and SMP are fundamentally different architectures.
This was a lot of fun, one of the things that doesn't get much air time is that back in the early 2000's when "clusters" and "NUMA SMP machines" were competing with each other the big argument for large SMP iron was ACID compliant SQL databases like Oracle. Now that Google has implemented an ACID compliant SQL database across clusters it puts the final nail in the argument (for me at least) that "Some things only wor…
>"back in the early 2000's when "clusters" and "NUMA SMP machines" were competing with each other" Did you mean Numa vs SMP? Or something else maybe? How can a machine be a NUMA SMP? NUMA and SMP are fundamentally different architectures.
The historical opposite of SMP used to be asymmetric multiprocessors in the heterogenous sense - different kinds of processors, for example scalar/vector/io processors. Or for a modern day take, ARM SoCs with little low-power cores and faster & more power hungry cores, and GPUs thrown in for good measure.
Except jails already existed on FreeBSD, and CP/CMS on mainfraimes in the 70s existed long before this...