11–20 of 25 posts
> distributed transactions based on 2-phase commit. i just stop reading from there.
That's the way Megastore does it too. Optional 2PC for transactions that span entity groups. So what's wrong with 2PC?
[1] https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Mo...
A modern and properly implemented database engine should be bottlenecked on network saturation for these types of workloads even if backed by disk storage, never mind in-memory. These workloads are trivially distributable, so scale-out is expected unless you are doing something really wrong. In that sense, similar "look how fast my simple lookups are" benchmarks published by other database vendors are really a functi…
I don't want to see the quarter mile, I want to see you road rally.
Are there anything similar for Postgre?
> MySQL Cluster is a scalable, real-time in-memory, ACID-compliant transactional database To what degree can something be called durable if it's in-memory? > It is possible to choose how to store data; either all in memory or with some on disk (non-indexed data only). […] Disk-based data can be used to store data with less strict performance requirements, where the data set is larger than the available RAM. It's grea…
A modern and properly implemented database engine should be bottlenecked on network saturation for these types of workloads even if backed by disk storage, never mind in-memory. These workloads are trivially distributable, so scale-out is expected unless you are doing something really wrong. In that sense, similar "look how fast my simple lookups are" benchmarks published by other database vendors are really a functi…
> MySQL Cluster is a scalable, real-time in-memory, ACID-compliant transactional database To what degree can something be called durable if it's in-memory? > It is possible to choose how to store data; either all in memory or with some on disk (non-indexed data only). […] Disk-based data can be used to store data with less strict performance requirements, where the data set is larger than the available RAM. It's grea…
VoltDB replicates to k nodes so you can choose the level of durability. Combined with UPSes in separate parts of the datacenter, it's durable in some senses. (I'd be more concerned with a kernel or app bug that crashes the system, if there wasn't a "save RAM on unclean boot". This only applies to the commercial version, though. The open source one ditched that feature.
I'm sorry but MySQL Cluster is pure refined salty horse shit. Nothing more. We're currently at the office trying to recover our production data from its filthy hands.
Why did you deployed such a "horse shit" product ?
>>>> to recover our production data
Don't you have a backup ?
Earlier quoted context omitted.
That's the way Megastore does it too. Optional 2PC for transactions that span entity groups. So what's wrong with 2PC?
If you have a distributed system and need to create a transaction across multiple nodes 2PC has some shortcomings[1], the 3PC is addressing this. [1] https://en.wikipedia.org/wiki/Three-phase_commit_protocol#Mo...
1. The transaction coordinator (TC) role is
automatically taken over in case of the
failure of the coordinator during commit.
The new coordinator uses the surviving
participants' states to quickly decide
on Commit or Abort so that locked
resources are released.
2. As the participants are part of an integrated
system, failure of both the coordinator and
e.g. the only participant to be aware of the
commit decision can be handled correctly.
In this case the transaction is quickly
aborted by the new coordinator and on recovery
the old participant will 'undo' its local
committed-state before rejoining the cluster.
3. Participants' local commit decisions are not
coupled directly to lock release / visibility
of those decisions. Locks are released only
when the participant-failure-durability of
the commit decision is assured (e.g. all
replicas have committed).
4. Ndb has a third phase (The complete phase)
which releases locks on replicas. This is
not the same as the algorithm referred to
as three phase commit, so we don't call it
three phase commit. Also, the third Complete
phase is not part of the critical commit
path - the commit acknowledgement is sent
to the application prior to the start of
the third phase, so it does not affect
the user's experienced commit latency.