Amazon qldb ВЫБИРАЕТ запрос для поиска определенных строк с очень меньшим количеством READIo

#node.js #database #amazon-web-services #amazon-qldb #partiql

Вопрос:

У меня есть таблица со следующими столбцами

Идентификатор пользователя (индекс), SID (индекс), Причина (индекс), Значение времени (индекс), Сумма

Я хочу запросить причину определенного идентификатора пользователя, то есть я хочу, чтобы некоторые cause из них были равны, скажем water , но я хочу этого только для одного пользователя, чей идентификатор «someId»

Запрос, который у меня есть прямо сейчас, выполняет полное сканирование таблицы

SELECT Cause, Cause_Amount, UserID FROM Contribution WHERE UserID = 'u5JvslEo9DbQ7hcq4vkM74dWlxr2' AND TimeValue > 1620414948000 AND ( Cause = 'cleanAir' OR Cause = 'safeWater')

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

Я надеюсь, что в этом есть смысл

Ответ №1:

Вообще говоря, вы должны указать индекс на свойстве документа с наивысшей мощностью. Это означает индексирование по свойству, которое является наиболее уникальным среди ваших данных. Поэтому, если в вашей системе 10 пользователей, но в вашей Contribution таблице 1 000 000 документов, для этого потребуется отсканировать 100 000 документов.

Если вы видите высокую читаемость iOS, это похоже на то, что у вас небольшое количество пользователей, но большое количество вкладов. Кажется маловероятным, что Cause это будет высокая мощность, и QLDB еще не поддерживает запросы диапазона (9/8/2021), поэтому запрос диапазона TimeValue , вероятно, также не поможет.

Есть ли в вашем документе другие свойства, по которым вы могли бы создать индекс с более высокой мощностью?

1. Мое свойство высокой мощности-идентификатор пользователя и, возможно, значение времени. В основном значение времени-это время в цифрах, с помощью которых я его сгенерировал new Date().getTime() . О чем я думал, так это о том, что я хочу видеть строки определенного идентификатора пользователя в то время, когда причина равна воде или чему-то еще. Я использую значение времени, IN (startTimeValue, endTimeValue) чтобы поделиться своим обновленным неполным запросом и скриншотом данных таблицы. Проверка причины отсутствует в этом запросе SELECT Cause, Cause_Amount, UID FROM ${tableName} WHERE UserId= 'ID' AND TimeValue IN (startTime, endTime) . i.imgur.com/ISmr6BH.png

2. В ваших образцах данных есть только два уникальных идентификатора пользователя и две разные метки времени, но 8 строк данных. В этом случае, какой бы индекс вы ни выбрали, это приведет к одинаковому количеству ReadIOs, которое равно 4.