Масштабируется ли SpacetimeDB? Разбор трёх измерений масштабирования
Ok, but Does It Scale?
Автор разбирает вопрос горизонтального масштабирования на примере SpacetimeDB и других СУБД, таких как Postgres, Neon и CockroachDB. Он выделяет три независимых измерения масштабирования: вычисления, хранение и сеть. Объясняет, что горизонтальное масштабирование вычислений не всегда возможно и часто приводит к снижению производительности при конкурирующих транзакциях. SpacetimeDB предлагает высокую производительность при конкуренции и инструменты для масштабирования параллельных OLTP-нагрузок, а горизонтальное масштабирование хранилища ожидается к 31 октября 2026 года.
Некрасивая правда в том, что горизонтальное масштабирование часто означает делать меньше с большим количеством компьютеров: то, что один компьютер может сделать за 1 миллисекунду, 10 компьютеров могут сделать за 100 миллисекунд.
- timssopomo
Spacetime звучит как действительно интересная технология, но я не уверен, что сравнение с CRDB уместно.
Я раньше работал в Cockroach Labs. Проблема, которую она решает, принципиально иная. CRDB как решение имеет смысл, когда вам нужно _гарантировать_, что транзакции сериализуемы и долговечны, и что ваше приложение может пережить отказ узлов или регионов, сохраняя согласованность. При наивном развертывании она значительно медленнее, чем работа на одном ядре, но это цена, которую вы платите за возможность пережить потерю узла без потери данных.
Я не вижу ничего, что указывало бы на то, как spacetime решает основную проблему CRDB, а именно гарантию того, что отказы отдельных узлов могут быть пережиты с нулевой потерей данных или потерей доступности. Похоже, что по умолчанию транзакции должны быть записаны на диск до завершения, что делает их долговечными на одном узле, но вы не можете гарантировать их согласованность между узлами, не принимая сетевые накладные расходы и не теряя пропускную способность транзакций (по крайней мере, на запись).
Кроме того, к слову, за несколько лет работы, когда я участвовал практически во всех инцидентах, я не припомню, чтобы видел кластер, упирающийся в сеть. Как и везде, здесь есть компромиссы. Вы жертвуете пропускной способностью, получаете согласованность и доступность, и вам не нужно проектировать, как избежать потери данных или доступности при отказах узлов. Если я не ошибаюсь, spacetime решает совершенно другую проблему.
- chermi
Не по теме, но... У меня был друг, который вынес из гарвардского мини-MBA (он учился по программе SEAS) главный вывод (в шутку), что всё, что нужно, чтобы выглядеть умным в кругу VC/технических бизнесменов, — это задать этот вопрос.
Затем мы действительно основали стартап и поняли, что это не глупый вопрос. Но, возможно, это замкнутый круг, когда стандартный путь — это венчурное финансирование, хм.
- philippta
Я некоторое время назад проводил бенчмарк Postgres в одно- и многоузловой конфигурации против CockroachDB, и мои результаты совпадают с тем, о чем говорится в этом посте.
https://github.com/philippta/postgresql-cockroachdb-benchmar...
- echohack5
Как человек, который много использует spacetime для побочных проектов (например, https://heat.echohack.app), я постоянно впечатлен скоростью его работы.
Я думаю, в области баз данных происходит много интересного. Vitess/Neki, векторные хранилища, spacetime — все это замечательные события. Я считаю, что жаль, что у разработчиков баз данных, похоже, драматичная история. Это... все вместе очень захватывающе.
В любом случае, вот некоторые вещи, которые требуют улучшения (некоторые из них затронуты в этом блоге):
1. Резервное копирование (быстрое восстановление) и аварийное восстановление (медленное, надежное восстановление)
Это важный момент, но иногда скорость — не единственная цель, которую нужно достичь. Вам нужна уверенность, что если все упадет, вы (в конечном итоге) сможете все вернуть. Сегодня у меня нет способа это сделать.
2. Читающие реплики были бы очень полезны для аналитических нагрузок
3. Долговечная запись в S3 была бы полезна для периодических пиковых нагрузок (например, CI-систем)
Я думаю, что у ребят из Spacetime работы непочатый край, и не обязательно из-за технологии (она тоже сложная), а потому что ИИ-модели, похоже, решили, что Neon и Postgres — это все, что существует.
Я думаю, у spacetime светлое будущее, и я желаю команде всего наилучшего, поскольку они усердно работают, чтобы запечатлеть что-то новое во вселенной.
- themgt
> Вы можете развернуть логику своего сервера прямо в базе данных
> Вы можете использовать Лицензированную Работу при условии, что ваше приложение или сервис использует Лицензированную Работу не более чем с одним экземпляром SpacetimeDB в продакшене и при условии, что вы не используете Лицензированную Работу для Сервиса Базы Данных.
Следовательно, как продукт с открытым исходным кодом, SpacetimeDB не масштабируется.