Amazon DynamoDBのテーブルは項目の作成順を保持しているのか

# はじめに
本記事では、Amazon DynamoDBに保存されている項目は作成された順番を保持しているのか、という問いに対して検証を行いその結果を記したものになります。

前提として、DynamoDBテーブルにはパーティションキーとソートキーを設定しています。このテーブルの項目に対してスキャンを実行した際に、どのような並び順で項目が返されるのかを検証します。

# 仮説
検証の前に、当該の内容ついてウェブサイトで公開されていないかを確認しました。
すると、以下のbuilders.flashにこのような記載がありました。

>複合プライマリキーでもパーティションキーの値は保存先のパーティションを分散するために使われます。

>同じパーティションキーの値を持ちソートキーが異なる項目は、ソートキーの値で順番に並べてストレージ内で近くに保存されるようになっている

https://aws.amazon.com/jp/builders-flash/202404/learn-dynamodb-primary-key/

さらに[デベロッパーガイド](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html#HowItWorks.Partitions.CompositeKey)には、以下の記述があります。
>テーブルに項目を書き込むため、DynamoDB はパーティションキーのハッシュ値を計算し、項目を含めるパーティションを決定します。そのパーティションでは、いくつかの項目で同じパーティションキー値を持つことができます。そのため、DynamoDB には、同じパーティションキーを持つ他の項目とソートキーの昇順で項目が保存されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/f47b6b47-6200-1d59-1679-0e6fe11de299.png)
以下から引用

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html#HowItWorks.Partitions.CompositeKey

この記述を踏まえると、少なくとも同じパーティションキーを持つ項目については、ソートキーの昇順で保存されるため、項目の作成順は保持されないと考えられます。
さらに、パーティションキーはハッシュ値を計算し、項目を保存するパーティションが決まるため、パーティションキーが異なるデータを含めても作成順については保持されないと考えられます。

ドキュメントを読むかぎりでは、項目の作成順を保持していないという結論になります。
実際にDynamoDBを使って検証して確認してみます。

# DynamoDBテーブルを使った検証
今回検証するテーブルは、以下のプライマリーキーで事前にいくつかの項目が作成されている状態です。
- パーティションキー：department
- ソートキー：id

現在の項目の順番はデータの作成順かつパーティションキーの降順になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/d310d1fc-5204-9967-bc69-ebb8021f51bb.png)



## パーティションキーの表示順の確認
まずは、パーティションキーが異なる項目がどのような順番で表示されるかを確認します。
テーブルに対して、以下の属性と値を持った項目を作成します。
作成済みの項目のパーティションキーとは異なるパーティションキーを持った項目を作成します。

1つ目の項目
- department：technology
- id：010
- first_name：takashi
- family_name：yamamoto

2つ目の項目
- department：legal
- id：001
- first_name：hiroshi
- family_name：watanabe

テーブルをスキャンした際に、この2つの項目がどう表示されるのかを確認します。

まず1つ目の項目を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/2538717b-c243-abbe-73e4-129eab0bbb4f.png)

この状態でテーブルをスキャンしてみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/c8e39e62-2ea6-8175-db93-f870ce7c80be.png)
新しく追加した項目は一番下に表示されました。

次に2つ目の項目を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/c5d5dd04-241a-aafd-405d-092e370926cf.png)

テーブルをスキャンします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/d606d8eb-a952-8c6f-2b5f-9bc98879a314.png)
下から2番目に追加されました。

[仮説](#仮説)に記載した通り、パーティションキーのハッシュ値を計算し、項目を含めるパーティションを決定する仕組みとなっているようなので、やはり作成順は考慮されないようです。

## ソートキーの表示順の確認
続いて、パーティションキーが同じ場合にソートキーが異なる項目がどのように表示されるかを確認します。

1つ目の項目
- department：sale
- id：003
- first_name：miho
- family_name：hayashi

2つ目の項目
- department：marketing
- id：005
- first_name：ryo
- family_name：nakamura

テーブルをスキャンした際に、この2つの項目がどう表示されるのかを確認します。

まず1つ目の項目を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/28e44bc6-5de2-1184-c41c-c907c085e350.png)

テーブルをスキャンします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/ad8a55ed-bd8d-5776-6336-85c0ad8861d2.png)

ソートキーが001と005の間に配置され、昇順になっています。


次に2つ目の項目を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/4eb98d72-a628-f4cf-1987-4d8d5b2f430b.png)

テーブルをスキャンします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2981404/3f04a577-2ff1-a6df-5902-850f9dd6ce22.png)
こちらも同様に、ソートキーの昇順に表示されました。

こちらもやはり[仮説](#仮説)に記載した通り、同じパーティションキーの項目についてはソートキーの昇順で保管されるようです。

# まとめ
[仮説](#仮説)で参照したドキュメントに記載があった通り、パーティションキーやソートキーに基づいて保存されるため、作成順は保持されないということが分かりました。
テーブルの設計をする際は、作成順は考慮されないという前提で、作成順に保持したい場合は作成順をソートキーに設定するなどの工夫が必要になりそうです。