61–70 of 95 posts
The last discussion point from this article very much so rings true for me, too. It's been how many years since the Spanner paper and I still can't get a GCP VM with atomic clocks? At least now I can provision Cloud Spanner as a managed service, but is this the future of clouds keeping their services at an advantage?
That sounds really good. I think reasons for slow adoption are probably a mix of: 1. Lack of developer awareness. 2. Security implications (or perceived implications) of exposing memory directly to a network without passing through CPU or application-level access control mechanisms. The second point may be prohibitive for a lot of general purpose database systems which are intended to be run on shared infrastructure…
Do you have indications why CPU bound? I have never seen Systems other than for example linear algebra or special algorithms to max out a modern CPU. Almost all loads today are in love way or another memory bound.
Systems limited by memory as in "quantity of" are scarse
This is impressive, but won't have huge impact, IMO. Way back in 2015, MySQL Cluster (NDB Cluster engine) benchmarked 200m transactions/second on commodity hardware [1]. It was read-committed transactions, not snapshot isolation, but still impressive. NDB (or RonDB, the new DB by its author) uses a non-blocking 2-phase commit protocol (failed transaction coordinators are failed over) and is even open-source. Still, i…
Why not many are talking about RonDB? This is like Erlang of the database world! People at Ericsson were really very smart and ahead of their time. FoundationDB, TiKV, CitusData's Postgres extension are very well known, but RonDB looks like a hidden gem. What are the practical issues with RonDB that it is not widely known(or used?)?
Earlier quoted context omitted.
Why not many are talking about RonDB? This is like Erlang of the database world! People at Ericsson were really very smart and ahead of their time. FoundationDB, TiKV, CitusData's Postgres extension are very well known, but RonDB looks like a hidden gem. What are the practical issues with RonDB that it is not widely known(or used?)?
[flagged]
Earlier quoted context omitted.
Time synchronization over a network with unknown latency characteristics is fundamentally impossible.
Really? It is now Tuesday in central europe and I guess most machines¹ managed to figure out that fact. Most machines will also know it is 8:11. The question is how much resolution do you need and are your clocks accuratly synced enough for the thing you plan to do. You are aware that many of the physics experiments that operate at the edge of what is possible use extremely accurate clocks synced over national and so…
You can't trust system clocks in a distributed system to ensure ordering. Some reading:
https://codeburst.io/why-shouldnt-you-trust-system-clocks-72...
> The data is assumed to be randomly distributed to memory nodes in the shared memory pool. Any memory node is equi-distant to any compute node, and a compute node needs to reach multiple memory nodes for transaction execution.
and also:
> Once a memory server fails, NAM-DB halts the complete system and recover all memory servers to a consistent state from the last persisted checkpoint. The recovery procedure is executed by one dedicated compute server that replays the merged log for all memory servers.
>This global stall is problematic for production, but NAM is a research proof-of-concept system. Maybe using redundancy/quorums would be a way to solve this, but then that could be introducing challenges for consistency. Not straightforward.
Yeah, research and proof-of-concept sounds about right. Some might even call it a toy database.
Also worth noting that this is a paper from 2016/2017. The world of (actually!) distributed database design has significantly moved on since then.
Earlier quoted context omitted.
Why not many are talking about RonDB? This is like Erlang of the database world! People at Ericsson were really very smart and ahead of their time. FoundationDB, TiKV, CitusData's Postgres extension are very well known, but RonDB looks like a hidden gem. What are the practical issues with RonDB that it is not widely known(or used?)?
[flagged]
Earlier quoted context omitted.
Why not many are talking about RonDB? This is like Erlang of the database world! People at Ericsson were really very smart and ahead of their time. FoundationDB, TiKV, CitusData's Postgres extension are very well known, but RonDB looks like a hidden gem. What are the practical issues with RonDB that it is not widely known(or used?)?
[flagged]
The particular timestamp oracle implementations still might suffer from metadata bloating and its commit protocol assumes an optimistic segment lock which would be a bottleneck in multiple scenarios.
So, from what I understand this is a (good?) practical speedup for some scenarios but doesn't change the fact that it's not possible to make an arbitrary sytem distributed without sacrificing correctness or throughput.
An easy reasoning: imagine that every node is one light year apart from all others.
Earlier quoted context omitted.
Really? It is now Tuesday in central europe and I guess most machines¹ managed to figure out that fact. Most machines will also know it is 8:11. The question is how much resolution do you need and are your clocks accuratly synced enough for the thing you plan to do. You are aware that many of the physics experiments that operate at the edge of what is possible use extremely accurate clocks synced over national and so…
Perfect time synchronization over a network with unknown latency is provably impossible. Fairly certain distributed physics experiments will be using atomic clocks that are not synchronized over the network. And/or they'll use direct satellite or GPS time sources which have predictable latencies.