Позволяет ли Cloud Spanner масштабировать хранилище отдельно от вычислений?

# #google-cloud-spanner

Вопрос:

Я вижу много утверждений о том, что Spanner отделяет вычисления от хранилища. И убедитесь, что диаграммы выглядят именно так. Однако при масштабировании гаечного ключа единственное, что я могу повернуть, — это количество узлов в кластере. На каждом узле предусмотрено некоторое количество вычислительных ресурсов и 2 ТБ хранилища.

Что приятно, так это то, что даже если я предоставляю узлы сверх своих потребностей в хранилище, я все равно плачу только за то хранилище, которое использую. Таким образом, в этом смысле затраты на вычисления и хранение также не связаны.

Но что, если мое хранилище масштабируется быстрее, чем вычислительные ресурсы? Если у меня есть 10 ТБ данных, мне нужно 5 (на самом деле 6) узлов. Но что, если просто не хватит запросов, чтобы использовать даже 10% доступных вычислений на этих узлах? В отличие от хранилища, я не плачу за использованные вычислительные часы. Я плачу за узел, пока он подготовлен, и я не могу отменить его, потому что мне нужно место для хранения.

Это означает, что Spanner фактически не отделяет вычисления от хранилища в строгом смысле. Поскольку мои вычислительные затраты зависят от объема хранилища (а также от запросов в секунду), это утверждение кажется почти вопиюще ложным.

Возможно, что Гаечный ключ просто не предназначен для случая использования, когда вычислительные ресурсы масштабируются медленнее, чем хранилище, но я чувствую, что, должно быть, что-то неправильно понимаю. Пожалуйста, помогите мне увидеть ошибочность моих путей.

Ответ №1:

  • I pay for the node as long as it's provisioned and I can't deprovision it because I need the storage space.

    К сожалению, это правда.

    Поддержание самих данных требует затрат не только на процессор, но и на память. Таким образом, существует ограничение на то, какой объем данных узел может эффективно обрабатывать. Утверждение о разделении вычислений/хранилища остается в силе до тех пор, пока не будет достигнут предел.

  • It's possible that Spanner is simply not intended for a use case where compute scales slower than storage.

    Я боюсь, что нет обходного пути для этого ограничения банкомата. Но я согласен, что это допустимый вариант использования, и у Cloud Spanner, вероятно, должно быть решение для его решения.

    Хотя это напрямую не касается вашей проблемы — вы можете открыть запрос на функцию, чтобы предоставить точку данных и помочь команде лучше расставить приоритеты.