Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jorangreef
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
91.
▲
by
jorangreef
1y ago
Give us 27 years—the company only turned 3 last month, and we designed for 30 :) To be clear, TB's pretty young, only 3, but Jepsen-tested and already migrating some of the largest brokerages, wealth managements and exchanges in variou
92.
▲
by
jorangreef
1y ago
For more about our open source and business philosophies, which we see as orthogonal, see this interview we did with Jerod Santo: https://www.youtube.com/watch?v=Z0kzYlCTUuc
93.
▲
by
jorangreef
1y ago
Appreciate your transparency that it's still a PoC, we'll chime in there. (But see also Wireguard and stunnel, depending on what your policy needs are, we try to keep policy out of TB as much as possible, and just give you great p
94.
▲
by
jorangreef
1y ago
Yes, this is what we also recommend, amongst other solutions. The building blocks are orthogonal.
95.
▲
by
jorangreef
1y ago
Apache 2.0 since day 0, since it came out of a non-profit central bank switch by the Gates Foundation, which is also Apache 2.0. Our view is that this kind of infrastructure is simply too valuable, too critical, not to be open source.
96.
▲
by
jorangreef
1y ago
Gregor! Thanks again for having me there, and good to see you.
97.
▲
by
jorangreef
1y ago
Such a pleasure to read this, that TigerStyle is making a difference for you. Appreciate the kind words!
98.
▲
by
jorangreef
1y ago
Hey Dan, appreciate the compliment. Do you think it would be more fair to suggest that OLTP workloads have 0% contention? That debit/credit sets never intersect? In practice, we're seeing that our customers are already some of the
99.
▲
by
jorangreef
1y ago
Joran from TigerBeetle here! TigerBeetle is our open source contribution. We want to make a technical contribution to the world. And we have priorities on the list of things we want to support, and support properly, with high quality, in ti
100.
▲
by
jorangreef
1y ago
Thanks! For anyone who wants to play the walking sim (excuse the pun!): https://sim.tigerbeetle.com
101.
▲
by
jorangreef
1y ago
CAP defines availability physically: “requests to a non-failing node receive a response”. TigerBeetle ensures logical availability: as long as clients can reach a majority, requests complete with strict serializability, preserving safety an
102.
▲
by
jorangreef
1y ago
Thanks! Check out https://tigerfans.io
103.
▲
by
jorangreef
1y ago
As one example, Rene Schallner made a pretty cool ticketing demo called TigerFans: https://tigerfans.io
104.
▲
by
jorangreef
1y ago
You should chat to our solutions team, who'd be able to help you solve auth etc. at the logical level with end-to-end encryption, something we typically do for our customers.
105.
▲
by
jorangreef
1y ago
And to be fair, those are all great general purpose solutions. For example, you could also use Postgres or Redis as queue, instead of say Redpanda or Kafka. But our customers need separation of concerns in their architecture. While they cou
106.
▲
by
jorangreef
1y ago
DBMS design has also changed. The bottleneck for a DBMS has moved from spinning disk to CPU and per core memory bandwidth. That's also key to TigerBeetle's design. For example, with static allocation and zero-copy techniques such
107.
▲
by
jorangreef
1y ago
Joran from TigerBeetle! Without much sweat for general purpose workloads. But transaction processing tends to have power law contention that kills SQL row locks (cf. Amdahl’s Law). We put a contention calculator on our homepage to show the
108.
▲
by
jorangreef
1y ago
You could, but TB brings a whole lot of debit/credit primitives out of the box (making it dead simple for e.g. 2PC money movement across third party systems, or transactions of thousands of transactions, to express complex financial co
109.
▲
by
jorangreef
1y ago
Depending on contention and RTT, as a specialized OLTP DBMS, TB can do roughly 1000-2000x more performance than a single node OLGP DBMS (cf. the live demo in the talk above)… but also with strict serializability. You don’t need to sacrifice
110.
▲
by
jorangreef
1y ago
Joran from TigerBeetle here! Yes, this is by design. SQL is a great general purpose query language for read-heavy variable-length string workloads, but TigerBeetle optimizes for write-heavy transaction processing workloads (essentially debi
111.
▲
by
jorangreef
1y ago
Liked it almost as much as My Cousin Vinny! ;)
112.
▲
by
jorangreef
1y ago
I’ve known Will for some time while they’ve been in stealth.
113.
▲
Spiral
(spiraldb.com)
261 points
by
jorangreef
1y ago
|
89 comments
114.
▲
by
jorangreef
1y ago
Hello! :)
115.
▲
by
jorangreef
1y ago
I don't mean to trap you, my anonymous friend :) but does the formal proof for Raft in Coq via Verdi not apply—at least in spirit—to the essential view change and SMR protocol for Viewstamped Replication? And, similarly, would you say
116.
▲
by
jorangreef
1y ago
There are at least two formal proofs. Have you tried Googling for them, instead of creating a throwaway account to comment anonymously here? :)
117.
▲
by
jorangreef
1y ago
> “seems” / “seem” Are you intending to suggest there are no formal proofs since? For example, you compare ‘14 Raft against ‘88 VSR, ignoring the interim progress made by MIT with ‘12 VSR? It would seem fair to compare the latest ve
118.
▲
by
jorangreef
1y ago
I heard on good authority that one of the earliest implementations of consensus at Google involved Sanjay Ghemawat tangentially. Sanjay's PhD on Harp, with Barbara Liskov, had also been based on Viewstamped Replication, and so, interna
119.
▲
by
jorangreef
1y ago
Yes, exactly. That difference came in with '12 VSR's view change (deterministic, round-robin), which upgraded '88 VSR's view change. '14 Raft missed this upgrade, unfortunately (despite citing the '12 paper), t
120.
▲
by
jorangreef
1y ago
Raft played a huge role in improving how consensus is taught, compared to Paxos. It’s hinted at in the introduction to the Raft paper, that Raft is "most notably" similar to Viewstamped Replication from Brian Oki, Barbara Liskov a
More ›