Пагинация в QLDB

Question

Я заметил, что QLDB не поддерживает LIMIT или SKIP параметры запроса, необходимые для реализации базовой разбивки на страницы.

Будет ли это поддерживаться в будущем или есть другой способ реализовать разбиение на страницы в QLDB?

Answer 1

LIMIT/SKIP в настоящее время не поддерживается. QLDB специально создан для приема данных. Мы рекомендуем делать отчеты и аналитику в другой специально созданной базе данных.

Рассмотрим банковское приложение с двумя вариантами использования:

1. Перемещение денег между счетами
2. Предоставление ежемесячных отчетов

Первый очень хорошо подходит для QLDB, где индексы используются для чтения балансов, а затем обновляется или создается несколько документов. В OCC QLDB позволяет легко писать эти транзакции правильно, и производительность должна быть очень хорошей. Например, если на счету осталось 50 долларов и две конкурирующие транзакции попытаются вычесть 50 долларов, только одна будет успешной (другая не сможет выполнить фиксацию). Между тем, другие транзакции будут успешными. Помимо простоты и производительности, вы также получаете целостность за счет цепочки хеширования QLDB и системы проверки.

Второй не подходит. Чтобы вычислить инструкцию, нам нужно будет найти транзакции для учетной записи. Но что произойдет, если эта учетная запись изменится (возможно, кто-то только что отправил вам немного денег!), Пока мы выполняем поиск? Опять же, при OCC мы завершим транзакцию неудачно, и потребуется повторить генерацию оператора. Для небольшого банка это, наверное, нормально, но я думаю, вы понимаете, к чему все идет. QLDB специально создан для приема данных, и чем дальше вы отклонитесь от того, для чего он был создан, тем хуже будет производительность.

Возникает вопрос, как на самом деле выполнять эти запросы в другой базе данных. Вы можете использовать функции S3 Export или Kinesis Data Streaming для извлечения данных. S3 Exports лучше подходит для массовых операций (которые предпочитают многие аналитические базы данных, например Redshift), тогда как Streams лучше подходят для аналитики в реальном времени (например, с использованием ElasticSearch).

И наоборот, я бы не рекомендовал использовать Redshift или ElasticSearch для первого варианта использования, поскольку вы не получите производительности, целостности или долговечности, которые предлагают базы данных, разработанные для сценариев использования OLTP (например, QLDB, DynamoDb, Aurora).