フィーチャーチームを高速化するたったひとつの奇妙な裏技！
スタッフエンジニアはこれを嫌っています！
Photo by Danny Howe on Unsplash
目次
新しいシステムや機能を設計するとき、スキーマ設計に行き詰まりやすいものです。この記事では、私のキャリアを通じて成果を上げてきた簡単なトリックを紹介します。
_最もシンプルな_データ永続化を試してみてください。新しいシステムや機能を設計する際には。
よく見かけるのは、チームがデータストレージの唯一の選択肢としてSQLやMongoDBに飛びつくことです。確かに、SQLを選んで首になる人はいません。しかし、もっとシンプルで、高速で、低コストな方法があると言ったらどうでしょう？
KV（キーバリューストア）だけで十分かもしれません。RedisやS3のようなものです。
常に正しい選択とは限りませんが、おそらくあなたが思っているよりも頻繁に当てはまります。
シンプルなストレージ層は、データ層のコードを再利用し、スキーマ設計やマイグレーションの変更に伴うコストを回避することで、初期 の開発を適度にスピードアップできます。変更はどうせ起こります。コードにできるだけ長く処理させましょう。2箇所で変更に対処するのは避けたほうが良いです。
パフォーマンスの向上が期待できるのは、key のルックアップが高度に最適化されており、書き込みでもバッチ更新の恩恵を受けられるからです。
キーで考える
最初にキーバリューパターンで設計するのは奇妙に感じるかもしれません。特に、オブジェクト階層やエンティティ関係図を使ってシステムを設計し、SQLで直接実装することに慣れているならなおさらです。
あなたはおそらく以前にキーバリューパターンを 使った ことがあるでしょう！ 設定ファイルやURLからS3スタイルのオブジェクトストレージまで、あらゆる場所にあります！ ユニークな ID 値でデータを扱うたびに、何だと思いますか？ またキーバリューパターンです！ (ただし、KVストアとは限りません。)
キーを使って設計する
事実上すべてのデータはKVパターンを使って表現 できる。(実際、多くの高次DBは低レベルKVパターン上に構築されている。) いくつか例を見てみよう：
user/123 {id: 123, ...}user/123/block ['user/456', 'user/789']user/123/groups ['admin', 'staff']user/420/friends ['user/456', 'user/789']
group/admin {user: '*:rw'}group/default {user: '*:r'}
product/42/discount/<UUID> {percentOff: '10%'}product/42/discount/<UUID> {percentOff: '20%', minTotal: 100.0}お気づきかもしれませんが、ID 自体がキーであることがよくあります！ これはKVストアで一般的なパターンです。キーは多くの場合、エンティティタイプとユニークIDの複合です。(例: user/123, user:456)
KVをグラフやツリーとして？
グラフやツリーのような複雑なデータ構造をKVパターンで表現すると役立つことがあります。(繰り返しになりますが、REST URLはその良い例です。)
キーの階層（user/420 -> user/420/friends）は、ユーザーとその友達の間のグラフ関係を自然に表現します。
これは、グラフデータ構造をシリアライズするための迅速かつ低コストな方法です。特に、グラフデータベース（Neo4jなど）の複雑さが必要ない場合に有効です。
KVパターンを使用すべき場合
- 大規模なスケールが必要な場合。（数十億、あるいは数兆のKVペア。）
- 主にユニークキーでデータにアクセスする場合。
- シンプルなデータ構造が必要な場合。
- データが階層、グラフ、またはツリー構造を持つ場合。
KVパターンを避けるべき場合
ブログのコメントなどを_単一の_KVペアに保存しないでください。例えば、post/666 -> {comments: [...あまりに多い...]} のようにはしないでください。代わりに、post/666/comments/1 や post/666/comments/<UUID> などを使用するか、SQLテーブルを検討してください。
- データセット内のプロパティ（キーやID以外）で検索する必要がある場合。
- 複数のエンティティにまたがるデータをJOINする必要がある場合。
- 複雑な制約や関係を強制する必要がある場合。
KV以上のものが必要な場合
プロジェクトの要件が自然に進化するにつれて、KVストアがサポートする以上のことを行う必要が生じるかもしれません。その時点で、より複雑なデータストアへの移行を検討する必要があります。
朗報としては、単一のKVストアをSQLに移行するのは、複雑なSQLスキーマをKVストアに移行するよりも比較的簡単だということです。（複数のテーブル、インデックス、制約などがある場合。）私はこれを50行のスクリプトで何度も行ってきました。
経験則として、最初にKVパターンから始めると、SQL設計の品質が向上することがわかりました。データを別の視点で考えるよう強制され、SQLから本当に必要なものを_正確に_理解できるようになります。
次のステップ
学ぶ最善の方法は実際に試すことです！このパターンをさらに探求したい場合は、Redis、DynamoDB、またはS3を使って何かを作ってみることをお勧めします。いずれも優れたKVストアであり、それぞれ異なるトレードオフがあります。
Fact Service - 参考プロジェクト
私のオープンソースプロジェクト、“Fact Service”（GitHub上の参考プロジェクト） をチェックしてみてください。
これは、KVデータサービスを実装したスタンドアロンのRESTful APIです。
多数のデータアダプターを備えています。 Postgres、Redis、DynamoDB、Firestore、Cassandraに対応！（Dockerコマンドも用意してあるので、すぐに始められます。）
Fact Serviceはスターター兼学習用プロジェクトです。フォークして、自分だけのKVデータサービスを構築してみてください！
まとめ
この記事がお役に立てば幸いです！ご質問やフィードバックがあれば、遠慮なくコメントするか、Twitterで@メンションしてください。Twitter