У Amazon QLDB есть ограничения по масштабированию / производительности?

Question

На главной странице Amazon QLDB говорится:

QLDB также является бессерверным, поэтому он автоматически масштабируется в соответствии с требованиями вашего приложения.

Однако даже такие продукты, как DynamoDB, с практически неограниченным автоматическим масштабированием, имеют некоторые ограничения масштабирования. (Например, DynamoDB имеет максимум 3 КБ RCU на ключ раздела.)

Я пытаюсь выяснить пределы масштабирования / производительности QLDB. Есть ли максимальный TPS или максимальная пропускная способность для ключа, таблицы, книги или учетной записи? Есть ли максимальный размер хранилища для таблицы, бухгалтерской книги или учетной записи?

По состоянию на октябрь 2019 года на странице квот и лимитов QLDB нет упоминания о каких-либо ограничениях масштабирования.

На странице часто задаваемых вопросов QLDB говорится:

Amazon QLDB может выполнять в 2 – 3 раза больше транзакций, чем реестры в обычных структурах блокчейнов.

Это начало, но оно не очень полезно, потому что "2-3X" - это относительно широкий диапазон, и они не указали, какие структуры блокчейнов они считают общими.

Кто-нибудь нашел информацию об этом (в документации, в сообщениях в блогах AWS, из сеанса глубокого погружения и т. Д.), Существуют ли такие ограничения?

Answer 1

Как вы заметили, у любой системы есть ограничения. Единственно верный ответ на ваш вопрос потребует сравнительного анализа вашего варианта использования, чтобы увидеть, какие цифры вы получите. Я не хочу вводить вас в заблуждение!

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

Первое, что нужно понять - это модель редактирования документа. В QLDB документы вставляются, затем обновляются (редактируются), а затем удаляются. Каждый документ имеет назначенный QLDB UUID, и каждая ревизия имеет назначенный QLDB (строго монотонно увеличивающийся и плотный) номер версии. Документы можно редактировать, выпуская транзакции (отправляя операторы PartiQL) в сеансе QLDB.

Далее транзакции. Транзакции обычно считывают какое-то состояние, а затем либо продолжают, либо прекращают. Например, если вы создаете банковское приложение со случаем использования перевода денег от Мэри к Джо, транзакция может быть следующей: "чтение баланса Мэри", "чтение баланса Джо", "установка баланса Мэри" и "установить баланс Джо". Между тем ваше приложение может применять ограничения. Например, если он определит, что баланс Мэри меньше суммы перевода, он откажется от транзакции. Если эта транзакция завершается успешно, создаются две новые версии (одна для нового банковского счета Мэри и одна для Джо).

Следующая концепция - это оптимистический контроль параллелизма (OCC), который объясняется на https://docs.aws.amazon.com/qldb/latest/developerguide/concurrency.html.. Когда вы пытаетесь зафиксировать транзакцию, QLDB отклонит ее, если другая транзакция помешает той, которую вы пытаетесь зафиксировать. Например, если со счета Мэри был сделан еще один вывод средств (после того, как вы прочитали баланс), ваша фиксация не удастся из-за конфликта OCC, что позволит вам повторить транзакцию (и еще раз проверить, достаточно ли денег у Мэри). Таким образом, характер ваших транзакций повлияет на вашу производительность. Если вы читаете балансы счетов, а затем создаете новые балансы на основе чтения, тогда у вас будет меньшая пропускная способность, чем при создании новых учетных записей или изменении учетных записей на случайные суммы (ни одно из которых не требует чтения).

Четвертая концепция - это Журнал. QLDB - это база данных "Сначала журнал": все транзакции сначала записываются в распределенный журнал, который затем используется для обновления индексированного хранилища. Архитектура QLDB абстрагирует для вас реализацию физического журнала, но раскрывает концепцию "цепочки", которая является разделом журнала. Каждая нить имеет фиксированную емкость (количество новых ревизий в секунду). QLDB в настоящее время (конец 2019 г.) ограничивает каждый реестр одной цепью.

Собирая все вместе, надеюсь, я смогу помочь вам с вашими вопросами:

1. Макс TPS. Теоретическая верхняя граница - это максимальное значение TPS одной нити. Не существует единого фиксированного числа, так как на него могут влиять различные факторы, но это многие тысячи TPS.
2. Максимальное количество транзакций в секунду на документ. Это никогда не будет превышать максимальное значение TPS, но будет больше связано с OCC, чем с чем-либо еще. Если вы просто вставляете новые документы (без чтения), у вас не будет конфликтов OCC. Если вы читаете, вы будете связаны тем временем, которое потребуется нам для обновления нашего индексированного хранилища из журнала. 100 TPS - хорошая отправная точка.
3. Макс за стол. Нет никаких ограничений на таблицу, кроме тех, которые налагаются другими ограничениями (например, ограничение на документ или ограничение на количество строк).
4. Макс на аккаунт. У нас нет ограничений на использование API "QLDB Session" для всего аккаунта. Каждая бухгалтерская книга - это остров.
5. Максимальный размер таблицы, бухгалтерской книги или учетной записи. Здесь нет никаких ограничений.

Примечание по сеансам: у нас есть ограничение по умолчанию в 1500 сеансов для QLDB. В каждом сеансе может быть только 1 активная транзакция, и каждая транзакция занимает определенное количество времени либо из-за времени запроса PartiQL, либо из-за сетевых циклов, либо из-за работы вашего приложения с результатами. Это наложит верхнюю границу на вашу производительность. Мы разрешаем клиентам увеличивать этот лимит, как описано на https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html.

Что касается другой части вашего вопроса (документация, примеры и учебные материалы), я могу предоставить некоторую информацию. QLDB был выпущен в прошлом месяце, поэтому re:Invent 2019 - это первая возможность, которая у нас есть, для взаимодействия с клиентами и получения прямой обратной связи о том, где разработчикам требуется дополнительная помощь. Мы провели 300-уровневую лекцию на re:Invent 2018 и сделаем еще одну в этом году. Я сделаю небольшой доклад об архитектуре нашего журнала и расскажу о некоторых из этих концепций. Сеанс будет записан и загружен на YouTube, но Chalk Talks требует, чтобы вы присутствовали лично. Но в любом случае это лишь одна из многих возможностей, которые у нас есть, чтобы лучше объяснить архитектуру QLDB, преимущества и ограничения. Не стесняйтесь задавать вопросы, и мыЯ сделаю все возможное, чтобы ответить на них и улучшить качество имеющейся документации. Что касается "утверждения 2-3x", это число было определено путем построения реальных сценариев использования (таких как пример банковского дела) на основе структур блокчейна и QLDB и объединения этих знаний в одно число. Мы считаем, что централизованный характер QLDB может дать много преимуществ, если не нужен распределенный реестр, и производительность является одним из них. Если у вас есть конкретные варианты использования, в которых QLDB не быстрее, чем тот же вариант использования в структуре блокчейна, мы будем рады услышать об этом.Мы считаем, что централизованный характер QLDB может дать много преимуществ, если не нужен распределенный реестр, и производительность является одним из них. Если у вас есть конкретные варианты использования, в которых QLDB не быстрее, чем тот же вариант использования в структуре блокчейна, мы будем рады услышать об этом.Мы считаем, что централизованный характер QLDB может дать много преимуществ, если не нужен распределенный реестр, и производительность является одним из них. Если у вас есть конкретные варианты использования, в которых QLDB не быстрее, чем тот же вариант использования в структуре блокчейна, мы будем рады услышать об этом.