В случае использования моя команда использует DynamoDB для запроса GSI. С увеличением количества возвращаемых строк задержка запроса увеличивается.
Наш код выглядит примерно так (Java) (довольно нормально)
Map<String, Condition> keyConditions = new HashMap<>();
keyConditions.put(indexHashKeyName, new Condition()
.withAttributeValueList(Collections.singletonList(new AttributeValue(identifier.toString())))
.withComparisonOperator(ComparisonOperator.EQ));
QueryRequest queryRequest = new QueryRequest();
queryRequest.setTableName(tableName);
queryRequest.setIndexName(indexName);
queryRequest.setKeyConditions(keyConditions);
queryRequest.withAttributesToGet(attributesRequired);
QueryResult result = dynamoDB.query(queryRequest);
Наш DynamoDB Таблица содержит около 4-5 атрибутов типа String. Мы используем AWS KMS для шифрования в состоянии покоя, и все 4-5 атрибутов присутствуют в GSI.
Мы видим задержки p99 в GSI как обычно 30-40 мс (миллисекунд) для получения ~ 30 строки данных.
Есть ли хороший способ уменьшить эту задержку (кроме кэширования)? Кэширование не является жизнеспособным решением для шаблона клиентского трафика c, который получает наш сервис.
Мы рассматривали несколько вариантов: -
Создать DynamoDB новая таблица, которая индексируется с помощью GSI-ha sh, все данные хранятся в виде JSON (или сжатого). Это уменьшит задержку, поскольку запрос теперь станет GET. Но это станет трудным, как только размер предмета превысит предельный размер атрибута 400 КБ.
Создайте новую таблицу DynamoDB, которая проиндексирована на ключе GSI-has-key и имеет ключ диапазона 1 , 2,3 ... и каждый раз, когда большой объем данных превышает 400 КБ, создайте новый элемент диапазона и выполните несколько операций GET для получения нескольких строк JSON больших двоичных объектов. Это увеличит задержку, как только начнется создание слишком большого количества ключей диапазона для заданного ключа ha sh.
Использование ElasticSearch для выполнения вышеизложенного (предположительно, ElasticSearch имеет меньше ограничений по размеру документа ), но мы не уверены, будут ли задержки такими же или хуже, чем задержки в запросах DynamoDB.
Есть ли какое-либо другое решение для базы данных, которое AWS предоставляет, которое помогло бы для наших сценариев использования? ?
Примечание : - Наши хосты EC2 находятся в том же регионе, что и наша таблица DynamoDB. Задержка 30-40 мс - чисто для запроса DynamoDB.