Custom DynamoDB response deserialization

[simonvandel]

Hi, I am extending a query engine with the ability to query DynamoDB.
The query engine operates on Apache Arrow.
So what I do currently is to convert from https://docs.rs/aws-sdk-dynamodb/latest/aws_sdk_dynamodb/operation/query/struct.QueryOutput.html to https://docs.rs/arrow-array/49.0.0/arrow_array/struct.RecordBatch.html. This works, but a profiler also shows me that the majority of time is spent inside `aws_sdk_dynamodb::protocol_serde::shape_query``.

Is it possible to get avoid the deserialization into Vec<HashMap<String, AttributeValue>>, and get access to something lower-level? Something like the raw bytes representing the json format described here https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html#API_Query_ResponseElements

[rcoh]

you could write an Interceptor to capture the response body and extract it. I think you'd want to use https://docs.rs/aws-smithy-runtime-api/1.1.2/aws_smithy_runtime_api/client/interceptors/trait.Intercept.html#method.modify_before_deserialization You can use this to grab the Bytes from the body.

You could also use read_before_transmit to just steal the Http request and send it yourself.

I want to double check that you're building in release mode for your profile results as well.

[rcoh]

yeah, that makes sense. I'm sure cargo bench is running in release mode. Yeah, you'll need to replace the body with one that will still parse, probably {}? You also need to be careful to preserve errors I suspect? You could do that by looking at the response code, I think.

https://github.com/smithy-lang/smithy-rs/blob/7eb008c4f7d852700e8c468fc1691e3cf880f2e7/examples/pokemon-service-client-usage/examples/trace-serialize.rs#L36 is a good example to start from.

Are you sending actual requests to dynamo with cargo bench or are you simulating? The deserialization may not be as much of a bottleneck in practice (but I'm sure skipping it will be faster!)

[simonvandel]

Thanks for the link.
I'm querying dynamodb-local.
If I compare a query with a dummy projection (so that the number of bytes to parse is minimal) VS no projection, I'm seeing a difference of around 20%.

So you are right that the deserialisation is not dominating, but if it can be removed, then that would be cool.

[simonvandel]

@rcoh
I tried inspecting the body with this Interceptor:

#[derive(Debug)]
pub struct DynamoDBInterceptor;

impl Intercept for DynamoDBInterceptor {
    fn name(&self) -> &'static str {
        ""
    }

    fn modify_before_deserialization(
        &self,
        context: &mut aws_sdk_dynamodb::config::interceptors::BeforeDeserializationInterceptorContextMut<'_>,
        runtime_components: &aws_sdk_dynamodb::config::RuntimeComponents,
        cfg: &mut aws_sdk_dynamodb::config::ConfigBag,
    ) -> Result<(), aws_sdk_dynamodb::error::BoxError> {
        let response = context.response();
        if response.status().as_u16() == 200 {
            // This returns headers
            dbg!(response.headers());
            // This returns Some(100) (looks ok for an response with no items)
            dbg!(response.body().content_length());
            // This returns None. I would have expected it to return the bytes of the response body
            dbg!(response.body().bytes());
        } else {
            panic!("")
        }
        Ok(())
    }
}

But I'm only getting None back from the response.body().bytes() call, even though the content length of the body is non-zero. Do you have any ideas what I'm doing wrong?

[rcoh]

yep! if you look at body.bytes() docs it's only bytes if it's in memory already. You should use response.body.take() to take the body. Then outside of this context, use body.collect().await to consume the contents.

The other option might be to use an override to set your own deserializer which would allow you to grab the body before it had been read.