Как вы заметили, для любой системы существуют ограничения. Единственный верный ответ на ваш вопрос потребует сравнительного анализа вашего варианта использования, чтобы увидеть, какие цифры вы получите. Я не хочу вводить вас в заблуждение!
Тем не менее, я могу помочь вам понять некоторые основы QLDB, которые помогут вам построить интеллектуальную модель поведения системы при различных рабочих нагрузках.
Первая концепция, которую нужно понять, - это модель пересмотра документов. В QLDB документы вставляются, затем обновляются (пересматриваются), а затем удаляются. Каждый документ имеет назначенный QLDB UUID, а каждая версия имеет номер версии, назначенный QLDB (строго монотонно увеличивающийся и плотный). Документы можно редактировать, отправляя транзакции (отправляя операторы PartiQL) через сеанс QLDB.
Далее транзакции. Транзакции обычно читают некоторое состояние и затем либо продолжаются, либо прекращаются. Например, если вы создаете банковское приложение с использованием сценария перевода денег от Мэри к Джо, транзакция может быть «прочитать баланс Мэри», «прочитать баланс Джо», «установить баланс Мэри» и"установить баланс Джо". В промежутке ваше приложение может применять ограничения. Например, если он определит, что баланс Мэри меньше суммы перевода, он откажется от транзакции. Если эта транзакция завершается успешно, создаются две новые ревизии (одна для нового банковского счета Мэри и одна для Джо).
Следующая концепция - Оптимистический контроль параллелизма (OCC), который объяснен на https://docs.aws.amazon.com/qldb/latest/developerguide/concurrency.html. Когда вы пытаетесь зафиксировать транзакцию, QLDB отклонит ее, если другая транзакция помешает той, которую вы пытаетесь зафиксировать. Например, если был произведен другой вывод со счета Мэри (после того, как вы прочитали баланс), ваш коммит потерпит неудачу из-за конфликта OCC, что позволит вам повторить транзакцию (и еще раз проверить, что у Мэри все еще есть достаточно денег). Таким образом, характер ваших транзакций будет влиять на вашу производительность. Если вы читаете сальдо счета, а затем создаете новые сальдо на основе чтения, то пропускная способность будет ниже, чем при создании новых учетных записей или изменении учетных записей на случайные суммы (ни одна из которых не требует чтения).
Четвертая концепция - концепция журнала. QLDB - это база данных «Сначала журнал»: все транзакции сначала записываются в распределенный журнал, который затем используется для обновления индексированного хранилища. Архитектура QLDB абстрагирует физическую реализацию журнала для вас, но действительно раскрывает концепцию «цепочки», которая является разделом Журнала. Каждая ветка имеет фиксированный объем мощности (новые ревизии в секунду). В настоящее время QLDB (конец 2019 года) ограничивает каждую книгу одной цепочкой.
Собирая все это вместе, надеюсь, я смогу помочь вам с вашими вопросами:
- Макс. TPS. Теоретическая верхняя граница - это максимальная TPS одной цепи. Не существует единого фиксированного числа, так как на него могут влиять различные факторы, но это многие тысячи TPS.
- Макс. TPS на документ. Это никогда не будет превышать максимальный TPS, но будет больше связано с OCC, чем что-либо еще. Если вы просто вставляете новые документы (без чтения), у вас не будет конфликтов OCC. Если вы читаете, вы будете связаны временем, которое потребуется нам для обновления нашего индексированного хранилища из журнала. Хорошая отправная точка - 100 TPS.
- Макс на таблицу. Для каждой таблицы нет ограничений, кроме тех, которые накладываются другими ограничениями (т. Е. Лимитом на документ или линией прядей).
- Макс для каждой учетной записи. У нас нет ограничений по всему аккаунту на API "QLDB Session". Каждая книга представляет собой остров.
- Максимальный размер таблицы, книги или учетной записи. Здесь нет ограничений.
Примечание о сессиях: у нас есть ограничение по умолчанию 1500 сессий в QLDB. В каждом сеансе может быть только 1 активная транзакция, и каждая транзакция занимает некоторое время либо из-за времени запроса PartiQL, сетевых обходов, либо из-за работы вашего приложения с результатами. Это наложит верхнюю границу на вашу производительность. Мы разрешаем клиентам увеличить этот лимит, как описано в https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html.
Что касается другой части вашего вопроса (документация, примеры и учебные материалы), я могу предоставить некоторую информацию. QLDB был выпущен в прошлом месяце, поэтому Re: Invent 2019 - это первая возможность, с которой мы можем взаимодействовать с клиентами и получать прямые отзывы о том, где разработчикам нужна дополнительная помощь. Мы выступили с докладом на 300 уровнях в re: Invent 2018 и сделаем еще один в этом году. Я буду давать «Chalk Talk» о нашей архитектуре «Первый журнал» и расскажу о некоторых из этих концепций. Сессия будет записана и загружена на YouTube, но Chalk Talks требуют, чтобы вы были там лично. Но в любом случае, это лишь одна из многих возможностей, которыми мы должны воспользоваться, и лучше объяснить архитектуру, преимущества и ограничения QLDB. Не стесняйтесь задавать вопросы, и мы сделаем все возможное, чтобы ответить на них и улучшить качество доступной документации. В терминах «требования 2-3х» это число было определено путем построения реальных случаев использования (таких как пример банковского дела) против структур блокчейна и QLDB и объединения этих знаний в одно число. Мы считаем, что централизованный характер QLDB может обеспечить множество преимуществ, если не требуется распределенная бухгалтерская книга, а производительность является одним из них. Если у вас есть конкретные случаи использования, когда QLDB не быстрее, чем тот же сценарий использования в рамках блокчейна, мы хотели бы услышать о них.