41–47 of 47 posts
Earlier quoted context omitted.
Thanks Kelsey! We’d love to roll up our sleeves and help you get it right. Please drop me an email.
So what was wrong with his isolated benchmark code that he shared here?
Earlier quoted context omitted.
I'm a bit worried you think instantiating a new client for every request is common practice. If you did that to Postgres or MySQL clients, you would also have degradation in performance. PHP has created mysqli or PDO to deal with this specifically because of the known issues of it being expensive to recreate client connects per request
Ok your comment made me double check our benchmarking script in Go. Can confirm we didn't instantiate a new client with each request. For transparency here's the full Golang benchmarking code and our results if you want to replicate it: https://gist.github.com/KelseyDH/c5cec31519f4420e195114dc9c8... We shared the code with the Tigerbeetle team (who were very nice and responsive btw), and they didn't raise any issues…
I searched the recent history of our community Slack but it seems it may have been an older conversation.
We typically do code review work only for our customers so I’m not sure if there was some misunderstanding.
Perhaps the assumption that because we didn’t say anything when you pasted the code, therefore we must have reviewed the code?
Per my other comment, your benchmarking environment is also a factor. For example, were you running on EBS?
These are all things that our team would typically work with you on to accelerate you, so that you get it right the first time!
Having built a ticketing system that sold some Oasis level concerts there's a few misconceptions here: Selling an event out takes a long time to do frequently because tickets are VERY frequently not purchased--they're just reserved and then they fall back into open seating. This is done by true fans, but also frequently by bots run by professional brokers or amateur resellers. And Cloudflare and every other state of…
Agree with the above, we built and run a ticketing platform, the actual transaction of purchasing the ticket at the final step in the funnel is not the bottleneck. The shopping process and queuing process puts considerably more load on our systems than the final purchase transaction, which ultimately is constrained by the size of the venue, which we can control by managing the queue throughput. Even with a queue syst…
In other words, to count not only the money changing hands, but also the corresponding goods/services being exchanged.
These are all transactions: goods/services and the corresponding money.
Earlier quoted context omitted.
It's almost like stored procedures were a good idea.
If only. But you also need to fix the internal concurrency control of the DBMS storage engine. TB here is very different to PG. For example, if you have 8K transactions through 2 accounts, a naive system might read the 2 accounts, update their balances, then write the 2 accounts… for all 8K (!) transactions. Whereas TB does vectorized concurrency control: read the 2 accounts, update them 8K times, write the 2 account…
I sometimes wonder how many fewer servers we would need if the aproaches promoted by Tiger Style were more widespread.
What datasteucture does Tiger Beatle use for it's client? I'm assuming its multi writer single reader. I've always wondered what the best choice is there. A reverse LMAX disruptor (multiple producers single consumer).
Earlier quoted context omitted.
The short answer is that we tried, back in 2020, while working on a central bank payment switch by the Gates Foundation. We found we were hitting the limits of Amdahl's Law, given Postgres' concurrency control with row locks held across the network as well as internal I/O, leading to the design of TigerBeetle. To specialize not for general purpose but only for transaction processing. On the one hand, yes, you could u…
i am not an exact expert on the limitation you claim to have encountered on postgresql but perhaps someone with more postgresql expertise can chime in on this comment and give some insight
But this pattern is not required by PostgreSQL, it's possible to run arbitrarily complex transactions all on server side using more complex query patterns and/or stored procedures. In this case the locking time will be mainly determined by time-to-durability. Which, depending on infrastructure specifics, might be one or two orders of magnitude faster. Or in case of fast networks and slow disks, it might not have a huge effect.
One can also use batching in PostgreSQL to update the resource multiple times for each durability cycle. This will require some extra care from application writer to avoid getting totally bogged down by deadlocks/serializability conflicts.
What will absolutely kill you on PostgreSQL is high contention and repeatable read and higher isolation levels. PostgreSQL handles update conflicts with optimistic concurrency control, and high contention totally invalidates all of that optimism. So you need to be clever enough to achieve necessary correctness guarantees with read committed and the funky semantics it has for update visibility. Or use some external locking to get rid of contention in the database. The option for pessimistic locking would be very helpful for these workloads.
What would also help is a different kind of optimism, that would remove durability requirement from lock hold time, which would then result in readers having to wait for durability. Postgres can do tens of thousands of contended updates per second with this model. See the Eventual Durability paper for details.
Earlier quoted context omitted.
Ok your comment made me double check our benchmarking script in Go. Can confirm we didn't instantiate a new client with each request. For transparency here's the full Golang benchmarking code and our results if you want to replicate it: https://gist.github.com/KelseyDH/c5cec31519f4420e195114dc9c8... We shared the code with the Tigerbeetle team (who were very nice and responsive btw), and they didn't raise any issues…
Appreciate your kind words, Kelsey! I searched the recent history of our community Slack but it seems it may have been an older conversation. We typically do code review work only for our customers so I’m not sure if there was some misunderstanding. Perhaps the assumption that because we didn’t say anything when you pasted the code, therefore we must have reviewed the code? Per my other comment, your benchmarking env…
Earlier quoted context omitted.
Appreciate your kind words, Kelsey! I searched the recent history of our community Slack but it seems it may have been an older conversation. We typically do code review work only for our customers so I’m not sure if there was some misunderstanding. Perhaps the assumption that because we didn’t say anything when you pasted the code, therefore we must have reviewed the code? Per my other comment, your benchmarking env…
Yeah it was back in February in your community Slack, I did receive a fairly thorough response from you and others about it. However then there were no technical critiques of the Go benchmarking code, just how our PostgreSQL comparison would fall short in real OLTP workloads (which is fair).
I don’t think we reviewed your Go benchmarking code at the time—and that there were no technical critiques probably should not have been taken as explicit sign off.
IIRC we were more concerned at the deeper conceptual misunderstanding, that one could “roll your own” TB over PG with safety/performance parity, and that this would somehow be better than just using open source TB, hence the discussion focused on that.