<- Back
Comments (34)
- farazbabarIn 2015, I was able to get to 1 million read/write queries per second on only a couple nodes and tested this with multiple databases, it required (at the time) decent network tuning and node placement inside AWS but it cost me about 10 to 15 dollars per run if I recall correctly, obviously there is the matter of scaling such performance and so I want to recognize the engineering effort gone into this but this is too much money. This reminds of when one of my teams used Hadoop to process only a a few terabytes of offline data and were able to process the WHOLE THING in only a few hours. I did not have the heart or courage to tell them during the demo that this was overkill, but I did write a very simple (and small) piece of code that could extract all the signals from the offline files in mere seconds with careful network planning and storage optimization and invited them for a demo/lunch and learn next week.
- stephenlfI watched an interview that Casey Muratori did with Tyler Cloutier (SpacetimeDB founder and spokesperson) [1]. One of the points that Tyler is that, given modern CPU architecture with cache lines, a distributed database needs to fan out to at least 50-100 nodes to beat the throughput of a cache-optimized, single node database.It’s cool to see the flip side of that argument. Planet scale is answering the question, “what does it look like when you DO fan out your workload to >100 nodes?”There’s a place for both technologies. Very cool stuff.[1] https://youtu.be/ONxwjqFjP3A?is=awlEJwGLxQmRE25i
- cbg0I did some quick ChatGPT math for the same performance/storage as the benchmark:Neki 1 primary + 2 replicas: ~$5.0M/month (just the AWS bill)Google Spanner w/ 3 replicas built in: ~$3.85M/month
- danbruc87.3 % served from cache. Does that mean it returned a result existing in the cache because the very same query was executed before? Probably still a relevant result, if you have to process millions of queries every second, it seems not unlikely that you will see a lot of repeated queries. But at that point you are measuring cache performance more than query performance. But unless you run some standardized query benchmark, a single queries per second number is not that informative anyway because query complexity and therefore execution time can span many others of magnitude. Looking up a name by ID and aggregating across a billion rows from seventeen tables joined together are both a single query.
- anonundefined
- samlambertIt cost $250,000 to do this run but it feels worth it.
- AdamProutI'm curious why the test needed so many router hosts:512 shards, each with one Postgres primary each on an r8g.16xlarge480 Neki routers, each on its own 8xlarge instanceThat's ~250K queries/sec per router which seems lowish for this type of workload? The routers won't be doing very much (parse query, route it to proper shard?).
- znpyIf this is closed source then i have zero interest in it.
- _zoltan_> The benchmark was very simple. A single-shard point select, one row fetched per-query by primary key. No writes, joins, or cross-shard queries. The workload that each shard receives is isolated, in that there are no single queries that span multiple shards.I mean... What's the point of this "benchmark"?
- anonundefined
- jeffbeeThe fact that you can just pay to scale out point reads is not news to anyone.