PlanetScale разогнала Neki до 118 миллионов запросов в секунду
118M Queries per Second on Neki
PlanetScale протестировала Neki в режиме preview: кластер из 512 шардов и 480 роутеров выдал 118,5 млн QPS при 1,22 PiB данных. Каждый шард держал около 231 тыс. запросов в секунду, p99 задержки составили 6,06 мс на роутере и 13,95 мс у клиента. Нагрузка была только на чтение, без реплик и отказоустойчивости.
Мы удерживали 118 538 803 QPS в течение 16 минут на 512 шардах и 1,22 PiB данных.
- farazbabar
В 2015 году я смог достичь 1 миллиона операций чтения/записи в секунду всего на паре узлов, и протестировал это с несколькими базами данных. Это требовало (в то время) приличной настройки сети и размещения узлов внутри AWS, но стоило мне около 10–15 долларов за запуск, если я правильно помню. Очевидно, есть вопрос масштабирования такой производительности, и поэтому я хочу отметить инженерные усилия, вложенные в это, но это слишком дорого. Это напоминает мне случай, когда одна из моих команд использовала Hadoop для обработки всего нескольких терабайт офлайн-данных и смогла обработать ВСЁ ЭТО всего за несколько часов. У меня не хватило духу или смелости сказать им во время демо, что это избыточно, но я написал очень простой (и небольшой) кусок кода, который мог извлечь все сигналы из офлайн-файлов за считанные секунды с тщательным планированием сети и оптимизацией хранилища, и пригласил их на демо/обед и обучение на следующей неделе.
- jamesblonde
В 2015 году MySQL Cluster (движок NDB Cluster) показал 200 млн транзакций в секунду на обычном оборудовании [ссылка]. Это были транзакции с уровнем изоляции read-committed, а не snapshot isolation, но всё равно впечатляет. NDB теперь стал RonDB, но по-прежнему основан на неблокирующем протоколе двухфазной фиксации и распространяется под GPL-v2.
RonDB теперь поддерживает infiniband, так что должен пробить отметку в 1 млрд операций/сек. Для справки: это 1 ГГц транзакций/сек.
[ссылка] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- stephenlf
Я смотрел интервью, которое Casey Muratori взял у Tyler Cloutier (основатель и представитель SpacetimeDB) [1]. Один из тезисов Tyler заключается в том, что с учётом современной архитектуры CPU с кэш-линиями распределённая база данных должна масштабироваться как минимум на 50–100 узлов, чтобы превзойти пропускную способность оптимизированной под кэш одноузловой базы данных.
Здорово видеть обратную сторону этого аргумента. PlanetScale отвечает на вопрос: «Как это выглядит, когда вы ВСЁ-ТАКИ распределяете нагрузку на >100 узлов?»
Есть место для обеих технологий. Очень круто.
- danbruc
87,3 % обслужено из кэша. Означает ли это, что был возвращён результат, существующий в кэше, потому что точно такой же запрос выполнялся ранее? Вероятно, это всё ещё релевантный результат, если вам приходится обрабатывать миллионы запросов каждую секунду, кажется вполне вероятным, что вы увидите много повторяющихся запросов. Но в этот момент вы измеряете производительность кэша больше, чем производительность запросов. Но если только вы не запускаете какой-то стандартизированный бенчмарк запросов, число запросов в секунду само по себе не так уж информативно, потому что сложность запроса и, следовательно, время выполнения могут различаться на многие порядки. Поиск имени по ID и агрегация по миллиарду строк из семнадцати таблиц, соединённых вместе, — это оба один запрос.
- cbg0
Я быстро посчитал с помощью ChatGPT для такой же производительности/хранилища, как в бенчмарке:
Neki 1 primary + 2 replicas: ~$5.0M/месяц (только счёт AWS)
Google Spanner с 3 встроенными репликами: ~$3.85M/месяц