2 ms·
They're calling a hashmap behind a RwLock a "database"? Damnit I wish I had the capacity for grifting, I could be rich by now.
by slopinthebag 2mo ago
They're calling a hashmap behind a RwLock a "database"? Damnit I wish I had the capacity for grifting, I could be rich by now.
- cloutiertyler 2mo agoIf you don't believe me, perhaps you'd believe the TigerBeetle team who also made their database single threaded by design. Perhaps you'd be interested in reading our technical response: https://spacetimedb.com/blog/benchmarking https://spacetimedb.com/blog/benchmarking
- slopinthebag 2mo agoMy comment was unrelated to benchmarking and I don’t see anything in that blogpost addressing my comment. Also you’re spamming the same comment up and down this thread. Did this post upset you?
- cloutiertyler 2mo agoYes, of course it did. This article makes factually wrong claims about the database I've spent 6+ years building. Your comment was about whether SpacetimeDB was "just a hashmap behind a RwLock" and the blog post I linked addresses that question. Namely, it does have a RwLock, but that is by design and produces better results than the alternative.
- slopinthebag 2mo agoBetter results than the alternative, assuming your use case is to find two accounts by indexed ID, check a balance, and update two rows. And you have a small in-memory dataset, tiny rows, indexed point lookups, very little application computation, no external I/O, no joins, no analytical queries, no large scans, no disk-capacity pressure, thousands of independent requests available for pipelining, and deliberate hot-row contention. Or in other words, you have the perfect conditions for a...hashmap behind an RwLock! Hm I wonder why people find this benchmark unfair...
- cloutiertyler 2mo agoYou're just describing OLTP transactions, which is exactly what OLTP benchmarks are designed to test.