118M Queries per Second on Neki

jjoshmgross about 3 hours ago 23 commentsRead Article on planetscale.com

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

94% Positive

Analyzed from 990 words in the discussion.

Discussion (23 Comments)Read Original on HackerNews

_zoltan_•21 minutes ago

> 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"?

farazbabar•about 1 hour ago

In 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.

danbruc•about 1 hour ago

87.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.

samlambert•about 2 hours ago

It cost $250,000 to do this run but it feels worth it.

handfuloflight•about 2 hours ago

I did not know men could build such things.

jeffbee•about 1 hour ago

That's roughly 250x more than it would cost to perform this stunt using on-demand Cloud Bigtable, if my math checks out (~1150 nodes @ 85¢/hour for 1h).

dataviz1000•34 minutes ago

  > 512 shards, each with one Postgres primary each on an r8g.16xlarge
  > 480 Neki routers, each on its own 8xlarge instance
  > We sustained 118,538,803 QPS for 16 minutes across 512 shards and 1.22 PiB of data. Our largest recording was 118,747,267.

  Component                      Detail                           Monthly  Hourly  16-min burst
  ---------------------------------------------------------------------------------------------
  Shard compute                  512x r8g.16xlarge                 $1.41M  $1,930          $515
  Router compute                 480x r8g.8xlarge*                  $661K    $905          $241
  Storage (gp3 floor)            1.22 PiB @ $0.08/GB-mo             $102K    $140           $37
  Storage (io2 floor)            1.22 PiB @ $0.125/GB-mo            $160K    $219           $58
  IOPS (io2, light)              5K IOPS/shard, tiered rate         $166K    $228           $61
  IOPS (io2, medium)             20K IOPS/shard, tiered rate        $666K    $912          $243
  IOPS (io2, worst-case)         231,517 IOPS/shard (0% cache)     $4.56M  $6,251        $1,667
  ---------------------------------------------------------------------------------------------
  Total (gp3 floor)                                                $2.17M  $2,975          $793
  Total (io2 floor)                                                $2.23M  $3,054          $814
  Total (io2 + light IOPS)                                         $2.40M  $3,282          $875
  Total (io2 + medium IOPS)                                        $2.90M  $3,966        $1,058
  Total (io2 + worst-case IOPS)                                    $6.79M  $9,305        $2,481

whalesalad•about 2 hours ago

I estimated the cluster to achieve this was ~$3-4k per-hour. I am thinking there is a typo on the r8g.16xlarge and they are actually r8gd.16xlarge (notice the d) which comes with directly attached nvme disks.

rcrowley•about 1 hour ago

It felt rude to take so many r8gd instances away from our customers who really love those (and i8g and i8ge).

svuiv•about 2 hours ago

We used r8g.16xlarge instances with EBS disks, no nvmes

whalesalad•about 1 hour ago

would love to hear more about the ebs volumes, iops/size/raid configuration

AdamProut•about 2 hours ago

I'm curious why the test needed so many router hosts:

512 shards, each with one Postgres primary each on an r8g.16xlarge

480 Neki routers, each on its own 8xlarge instance

That'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?).

svuiv•about 1 hour ago

that's over 13k queries/sec per router core, about 50% of it is spent doing syscalls, the other 50%: parsing, doing grpc, tls, go gc, resolving the shards, waiting for the responses

neki is still in platform preview, this experimentation allowed us to collect profiles at such scale and ship some nice optimizations, more are coming

znpy•about 2 hours ago

If this is closed source then i have zero interest in it.

jjice•about 1 hour ago

I believe multigress is the similarly aged open equivalent from Supabase. Haven't used it myself and don't know what the differences are in usability, but I'm a bit more interested in that since it's open.

samlambert•about 1 hour ago

Neki right now:

Multiple live shards: yes

Query routing across shards: yes

Online shard splitting: yes

Zero-downtime resharding: yes

Multiple independent shard groups: yes

Data topology management: yes

HA / automated failover: yes

Multi-AZ: yes

Connection pooling: yes

Online schema changes: yes

Workflow-driven migrations/cutovers: yes

Zero-downtime imports: yes

CDC / logical replication: yes

Online Postgres version upgrade workflows: yes

Cross-shard transactions: coming

Multigres today:

Multiple live shards: no

Query routing across shards: no

Online shard splitting: no

Resharding: no

Multiple shard groups: no

HA / failover: yes

Multi-AZ: yes

Connection pooling: yes

Logical replication/import work: in progress

Distributed migration/resharding workflows: no

How it is an it's an alternative? Do you just say things without validating?

jjice•38 minutes ago

Comes off a bit rude, especially from the CEO.

I get that PlanetScale has the currently superior product, and I listed the closest thing to it. You're right it's not ready, but in the case that the parent had mentioned of closed-source making it a deal breaker, it's the best alternative.

Neki looks like a good product, and I trust that something coming from the folks behind Vitess is going to be a damn fine offering, but some of us don't love tying our workloads to fully proprietary products. I wouldn't even want to host something like this myself, but knowing there's a path out of the proprietary hosting (which we've seen time and time again is something we should plan for) is critical for a lot of us when choosing solutions as important as our data layer.

If I needed a truly sharded PG at the moment, Neki is probably the best option I could find.

As for the "alternative" argument specifically, it's not on par at the moment, you're right, but that's their goal and they're attempting to fill the same void. In the case of someone who has a requirement their solution be open source, then Neki is flat out of the running too.

I'm rooting for a good Postgres sharding solution to come out. Your team appears to be doing some good work. I would also like to see where both Neki and Multigres are in five years.

spongeboi•about 1 hour ago

unfortunately they haven't been able to move forward w/ the project, it can't even shard yet

jjice•35 minutes ago

It appears to be under active development, but you're right that sharding doesn't appear implemented. I'm excited to see what they can build out over the next few years.

noir_lord•about 1 hour ago

Someone posted a twitch conversation yesterday about this, I poked around on the page realised there was no open source version and noped out immediately.

I'm sure it's a great product (it seems like planetscale do good engineering and the folks I know who use them seem fine with it) but I don't do vendor lock-in as a service personally, I'll use whatever employer uses because that's the deal but for personal stuff, well this isn't designed for that really, wrong order of magnitude on scaling.

jeffbee•about 2 hours ago

The fact that you can just pay to scale out point reads is not news to anyone.

AdamProut•about 2 hours ago

yeah, this is a definitely a "best case" workload for a sharded database. Single row reads on the key used to shard with no hotspots (no shard to shard network traffic at all).