AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

作者別: Taiji Inoue

こんにちは!

DynamoDB PHP SDKのMarshalerクラスを使った時にはでかい数値に気をつける


下記のblogで紹介されているように、AWS PHP SDKの 2.7.7 から PHPの型とjsonとDynamoDBの型の相互変換を行うクラス、Marshaler が追加されています。

DynamoDB JSON and Array Marshaling for PHP

この Marshaler クラスを使うと、型変換が行われるため、数値型に大きな値を入れている場合に注意が必要です。

以下に例を示します。

id = 1 のレコードに number = 9223372036854775808 という値が入っているレコードを取り出してみます。

結果

9223372036854775808 という値が取り出せました。

これを Marshaler でPHPの型に戻してみます。
使用するメソッドは、unmarshalItem です。

結果

9.2233720368548E+18 になってしまいました。/(^o^)\ ナンテコッタイ

原因

PHPでの整数の最大値はPHP_INT_MAXで定められており、9223372036854775807 になっています。(64bitの場合)
それを超えた数字を整数に変換しようとすると、指数表記になってしまいます。

参考:PHP>マニュアル>言語リファレンス>型>整数

一方、DynamoDBの方は、下記ドキュメントにて、最大 38 桁の精度とあるように、 99999999999999999999999999999999999999 まで投入できます。

参考:DynamoDB データモデル

この辺りの相互変換は、言語側の精度に依存する形になると思うので、使っている言語側の仕様を確認しておいた方がよさそうです。
たしか、rubyの場合には BigDecimal に変換されたと思います。

参考


既存のDynamoDBテーブルからテーブル定義を作成する


開発環境で作ったDynamoDBのテーブルと全く同じテーブルを本番環境で作ったり、
既存のテーブルのインデックス定義をちょっと変えて作り直したい、そんなケースがあると思います。

マネージメントコンソールで作ってもよいのですが、インデックス名を間違ったり、インデックスが不足したりすると思わぬトラブルになります。(実際ありました)

きちんと、テーブル定義をjsonファイルで管理しておけばよいのですが、そうでない場合は、既存のテーブルからテーブル定義となるjsonを吐き出して、それを読みこませて作成したいと考えると思います。

ただ、aws dynamodb describe-table で吐き出すjsonには、create-table に不要な項目が多数含まれていて、そのままでは実行できません。

「ああjson手で直すのめんどくさいなー」 と弊社今井の周りでつぶやいていたところ、

つ 「出来た」

と下記のようなスクリプトが送られてきました。仕事早っ。

jq でjsonの要素簡単に消せるんですね。
これで出力された json を使って、下記のように作成すればまったく同じ定義のテーブルが作れました。

まとめるとこんな感じです。

既存のテーブルと同じ定義のテーブルを作成する

最初からテーブル定義をjsonで管理する

上記のような事態にならないように、最初からjsonで管理しておけばよかったな、と思ってます。
具体的には、下記のような手順でしょうか。

1)テーブル定義のスケルトンを作成

2)スケルトンをベースに編集する

不要な定義消したり、インデックス名をきめたりとか。

3)テーブル作る

describe-table とかできちんと出来ているか確認する。

4)git に登録

問題なければ、git などに入れておく。

 おわりに

もっとこうしたほうがいいよとか、CloudFormation使うとこんな感じでできるとか、追加情報ありましたら教えていただけると嬉しいです。

あと、プロビジョニングツールとかないのでしょうか。(後から追加できるのがGSIくらいだから需要ない?)


DynamoDBの紹介と東急ハンズでの活用について


こんにちは、井上です。

2/7に行われた、JAWS-UG KANSAI特別編 にて『DynamoDBの紹介と東急ハンズでの活用について』という内容で発表してきました。

そのスライドをアップしました。

Amazon DynamoDBの紹介と東急ハンズでの活用について

もっと、DynamoDB と Beanstalk の相性はとても良いとか、こういう部分で困ってる、とか、テクニカルな話もいろいろしたかったのですが、意外と駆け足になってしまいました。

会場で聞いてくださっていた方の中でも、DynamoDBを使っているという方は数名しかいなかったので、とっつきにくい印象があるのかなぁと思いました。

DynamoDBは、AWS内部でも各所で使われており、S3、SQSとともに、AWSを支える最も重要な基盤のひとつになっているようです。
また、東急ハンズにおいても、現在はネットストアだけではなく、MDシステム等の基幹システムにも用途を広げつつあり、ハンズを支える重要な技術になってきています。
これからも、DynamoDBに限らずAWSの仕組みなどをうまく活用しつつ、お客様に価値を届けられるよう、頑張って行きたいと思います。

最後に、JAWS-UG KANSAIのメンバーの方々、会場を提供頂いた エムオーテックス様、ありがとうございました!!


「リーダブルコード」を読んで


はじめまして、ハンズラボの井上です。

ハンズラボには、おじさんがひたすらお酒を飲むブログとかがあって好評?連載中なのですが、酒飲んでるだけじゃなくて一応仕事もしてるんだぞアピールとして、技術的な話題などはこちらに掲載していきたいと思います。

1回めの記事では、正月休みに読んだ、「リーダブルコード」という本について、だらだらコメントなどを書いてみたいと思います。

jpeg
まず、この本を読んで感じたのは、

プログラムは、単に、コンピュータに命令を実行させるための、命令の羅列だけではなく、開発者間のコミュニケーションの媒体としての側面もある

という点です。
もちろん、プログラムは、想定通りの仕様にそって正確に動作する必要があるのですが、その想定どおりの仕様 というのは、時と共に変化します。
また、開発者自体も、最初に作成した人から、それを運用する方、緊急の不具合対応する方など、どんどん変遷していきます。
が、その中心にあるのは、常に動いているソースコードです。
開発者は、ソースコードを通していろいろな人(仕様を決めた人や、設計した人、実際にコーディングした人)の意図を汲み取りながらメンテナンスし続けなければなりません。
子供の頃、少年野球でキャッチボールの練習の際に、

「相手のことを考えて、相手が取りやすい位置に投げてあげるんだ」

と口を酸っぱくして言われましたが、プログラミングも一緒で、常にそのコードには受け取り手がいることを意識し、受け取りやすいように書いてあげないといけないと思いました。
俺さえわかればいい、動きゃなんでもいい というコードをメンテナンスするのは辛いですからね。
続きを読む 「リーダブルコード」を読んで