Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TigerBeetle Core System Architecture: Deconstructing Performance Engineering

ixuvo.com

Post reply on HN
Print view View original

41–43 of 43 posts

Re: TigerBeetle Core System Architecture: Deconstructing Performance Engineering

#41

Post by thomascountz »

g_delgado14 wrote: post #37

Is it just me or does it not seem like this whole article was llm generated? The two "sources" are fake links that lead to 404s

Read TigerBeetle's own

* A Database Without Dynamic Memory Allocation[1]

* A Programmer-Friendly I/O Abstraction Over io_uring and kqueue[2]

* Writing High-Performance Clients for Tigerbeetle[3]

[1]: https://tigerbeetle.com/blog/2022-10-12-a-database-without-d...

[2]: https://tigerbeetle.com/blog/2022-11-23-a-friendly-abstracti...

[3]: https://tigerbeetle.com/blog/2023-02-21-writing-high-perform...

Re: TigerBeetle Core System Architecture: Deconstructing Performance Engineering

#42

Post by hawk_ »

to_ziegler wrote: post #27
hawk_ wrote: post #23

Earlier quoted context omitted.

Is this flexible quorum something that deviates from VSR? I thought VSR requires majority of the nodes to form quorum.

It's an insight from Heidi Howard et al. that came out after VSR: https://arxiv.org/abs/1608.06696 and can be applied to VSR (and others). The basic idea is pretty simple. In VSR, there are two main phases: 1. Leader election 2. Normal replication / request processing Before Heidi Howard’s insight, these two phases typically used the same quorum size - for example, 4 out of 6 replicas. The key observation was that th…

Yeah that makes sense. Thanks for the explanation. This gives me some ideas on some 2 data center setup with tolerance for 1 DC failure within VR or Paxos that I didn't think was possible.
Post reply on HN