Amazon Timestream 所感
軽く触ってみて感じたこと，気づいたことについて記す．
Memory Storage
その名の通りメモリに時系列データを突っ込む
少量の短期間 (最近) のデータに対してオンラインクエリをすることに最適化されている
保存するデータあたりの単価が一番高い
SSD Storage
Magnetic Storage
HDD的な媒体に記録されているのだろう
中規模から大量のデータを処理する高速分析クエリ用に最適化されているとある
保存するデータあたりの単価が一番安い
このStorage Typeについて，ユーザーは自由にデータを移動させることはできない．例えば，あるデータをMemory storageからMagnetic Storageに手動で動かす，というような方法は提供されていない．
唯一，データがStorageのTypeを移動するのは時間経過によるもののみで，このdurationはユーザーが任意に指定できる (ただし，それぞれのStorage Typeで最長保持期間の制限は存在する)．つまり，data ageが1日以上になったらMemory storageからSSD storageに移動させる，という設定をすることができる．
この設計はおそらく，「時系列データというものは最近のものであればあるほどアクセスされる頻度が高い」という多くの場合あてはまる（であろう）利用パターンに基づいたものであると思う (良いと思う)．
これはつまり，databaseにはtableがあって，そのtableはRDBMSのようにスキーマが定義されているということになる． 実際のクエリの例を見てもらうとわかるが，本当にSQLでクエリできるのでSQLに親しんだ人であればとっつきやすくて良い．使い心地はRDBMSによく似ていると思う． 以下は軽く触ってみて思ったこと・気づいたこと:
あるデータがどのStorage Typeに保存されているかは知る方法がない
クエリはStorage Typeをまたいで透過的に実行されそうなのでそうなったときにパフォーマンスが読みにくそう
そうならないように時間によるfilterを常にかけておく必要がありそう
そもそもmemory, ssd, magneticそれぞれの性能・性能差がわからない
要検証
現在のデータが占めるStorage Typeの比率を知りたいが知るすべはなさそう
mem 10%, ssd 30%, hdd 60% みたいな
クエリのパフォーマンスチューニングツールがなさそう
EXPLAIN 的な……
クエリ実行に何秒かかったか，みたいな情報も取れない気がする
これはclient sideでやれという感じ？
パフォーマンスのメトリクス (クエリのレイテンシとか) を見ることができる
https://gyazo.com/814e13171bb8d32b52eceb14df6cd547
が，これはすべてのデータベース・テーブルを総合したメトリクスなのでどうすりゃええんや感がある
どう考えてもデータベースごと・テーブルごとのメトリクスを見たい
コスト見積もりツールが欲しい
クエリに JOIN が存在しない
確かに無いっぽい
これは完全に勘違い，JOINはサポートされていました．失礼しました
クエリは60秒でタイムアウトする