こんにちは。開発部の対馬です。
他社様の機器、APIなどと連携することの多いIoTのサーバー開発では、機器などから送信されるデータのフォーマットが未定、または変更になることが多々あります。
そのようなとき、フォーマット変更によるDB設計の停滞や手戻りを防ぐため、「とりあえずKVS的に、データは全部JSON文字列で保存しておこう」という方針で開発をせざるを得ないことがあります。
ある意味バッドノウハウな気もしますが、意外と柔軟な設計ができたりするので、ご紹介します。
ちなみに、JSON型や関数をバリバリに活用するような話ではありません。
逆に、そういう実装にするとクエリが複雑になったり、保守の難易度が上がったりするので、よほど要件がマッチしない限り自発的にそういう設計をおこなうことはありません。
きっとあとで変わるよな・・・
「A社が提供するWebAPIと連携して、こんな機能を実現したい。API仕様書を提供いただいたので確認してください」
「わかりました」
確認すると、APIの返り値はJSONフォーマットです。
そこに、いついつのデータはこれとこれとこれと・・・というのがずらずらと格納されています。
こんな感じだときっと場合によってキーとかも変動したりするんだろうな・・・
計測データのキーが確定してるなら、テーブルにきっちりフィールドを定義するんだけど、アヤシイ。
変わるっぽいものと確定っぽいものを区別する。
このアプリケーションは時刻が重要な検索キーなのは間違いないので、「じゃあ時刻（と若干の付帯情報）をキーにして、なんちゃってKVSかな」と決めました。
で、最終的にこの計測データ格納テーブルのスキーマはこうなりました。
・APIキー
・計測時刻
・計測データ（JSONでまるごと）
また、この保存した計測データをさらに、ロガー端末からのリクエストに応じて提供するAPIを作成します。
ロガー端末からは、
・認証情報
・取得したいデータの計測時刻
・取得したいデータの項目（複数指定可）
をパラメータでもらうことにしました。
ひとまず意図通りに実装し、ロガー端末との連携も問題ありません。
やっぱり変わった。けど大丈夫。
それからしばらくして、「やっぱり計測データのキー名が微妙なので変更しようと思います」というお話が。
ついでに計測データの項目もちょっと増えたようです。
「あ、やっぱり・・・」
しかし、アプリケーション側では修正はほとんどありません。バリデーションルールを多少変更するくらいです。
項目が増えたりキー名が変更になっても、とりあえずJSONにして計測データフィールドに突っ込んでいるだけだからです。
ロガー端末からも、取得したいデータの項目名を変更後のキー名で指定してもらえば、問題なくデータを提供できます。
今回はデータフォーマット変更のリスクを織り込んだ設計がハマり、ほとんど修正なしで仕様変更に対応することができました。
ただしこれは、このアプリケーション自体の仕様がそんなに複雑でなかったから出来たことで、普通はこんな簡単にはいかないとは思います。
ということで、使いどころにもよりますが、なかなか便利な「なんちゃってKVS」のご紹介でした。
