国彦(45)236236件のシェア(すこし話題の記事)この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。入門は「データスキーマ設計のいろは」です。特徴を生かせない設計をしてしまう事があるので、このテーマにしてみました。どのように設計するのか解説したいと思います。特徴の1つとして「Document-Oriented」と言う記載があります。直訳すると「ドキュメント指向」です。簡単に説明すると現実世界の複雑なデータをJSONドキュメントにしてインデックスするだけで、デフォルトで全てのフィールドにインデックスが作られて、検索のスピード落とさずに検索できるよ。いう特徴を持っています。言い換えれば、ビジネス要件を保ったままインデックス化するためのドキュメントが定義可能であるということです。(余計に分かりにくいw)例えば、以下のユーザー情報を表すデータでは、「1つのユーザー情報に対して名前や年齢などの情報をそれぞれ1つ持つことができ、さらにSNSの種類とそのIDの組み合わせを持つ複数のアカウント情報を持つことができる。」というビジネス要件を持ったデータがあるとしましょう。インデックス可能なドキュメントとして定義することができるのです。使って、検索のパフォーマンスにフォーカスしたデータ設計をする場合、そのデータ構造は極力フラットに、RDBであれば関連テーブルを極力なくして非正規化していくのがこれまでの常識でした。この設計方法は、今までのシステムの制限や仕組みの制約上仕方のない設計でしたが、この非正規化方法はビジネス要件(ビジネスを表現するデータの構造)を満たす検索の実現が難しかったり、検索のために非正規化したデータは、検索要件とかなり密接に関わるため、検索対象の元データは同じでも、検索ニーズが変わってしまうとそのデータ構造さえガラッと変わってしまいます。(仕様変更がアプリ側もデータベース側もすごく大変なのです。ドキュメント指向はとても画期的で、これまでの検索アプリケーションの設計フローまで変えてしまいます。データスキーマ設計フロー比較してみます。検索側の要件を先行して、データ設計と並行で進めるイメージ。途中で大きな変更が必要になる場合も。ビジネス要件を満たすデータ構造が難しいため、例えば、フィールド数を減らすためにフラグ系のフィールドデータの値を1つのフィールドにまとめてコード化したものをインデックスしましょうとか、データ構造以外にデータの内容も工夫を繰り返し、利用者(フロントエンドの開発者など)が仕様を把握するのが難しい設計になりがち。調べる)ちゃんと検索対象データのビジネス要件を理解して設計していれば、途中の変更はフィールドの追加など小さな変更ですみます。落とし込みつつ、検索、集計、ソートがビジネス要件を満たせるか実際にクエリーを書いて検証しながら進めたり、4階層とか5階層とかネストしすぎる場合は、ビジネス要件を満たしつつ階層を減らせないか考えたりしたほうが安心ですが、基本的には、様々なデータ型や、それに対応した検索・集計・ソート機能が提供されているので、データスキーマの設計では、検索対象データのビジネス要件にフォーカスして設計してしまっても途中で大きな変更はないはずです。検索結果でも使用されます。限ったことではないですが、フィールド名はわかりやすくシンプルに統一性を重視して命名しましょう。スネークケースに統一する例えば表記方法では、キャメルケースまたはスネークケースに統一する。設計者の趣味もあると思うので、どちらがオススメというのはありませんが、どちらかに統一することをお勧めします。セットすると、そのレスポンスのJSONをキャメルケースに統一することもできます。分析するにしてもデータスキーマ設計書を見なくてもフィールド名でその値が想像できるような名前をつけましょう。悪い例:以下の例では、ユーザーの名前なのかメールアドレスなのかフィールド名だけではわかりません。サフィックスにつけることで、ユーザーの名前がストアされていることがわかります。Kido"}良い例その2:複数の情報がある場合は、オブジェクトにまとめるのも良い方法です。インデックス・テンプレートを使って、アナライザーやマルチフィールド、適用するデータ型など、マッピング定義をルール化することも可能です。すると新しいフィールドが追加された時の設計コストが削減できます。(極端な話、言語処理など検索エンジン特有の設計を知らないエンジニアでもフィールド命名規約さえ守れば、適切な型や言語処理が適用されたフィールドを追加できる仕組みを作ることができる。データ型をサポートしています。データ型の特殊な型です。データ型を使い分ける場合は、フィールド名称でその違いがわかるように設計するという考え方もあるので、説明しておきます。いう対になっている情報があります。データ型の対象データです。データ型としてインデックスされます。組み合わせは維持されません。"white"]}そのため、以下のような組み合わせ違いの検索条件でも上記のドキュメントはマッチします。データ型は以下の例のように、マッピング定義時にその型を明示的に設定します。クエリーを使って検索可能になります。そのオブジェクトのパスを指定して以下のようにリクエストします。値の組み合わせが正しい条件ではマッチしますが、上記のクエリーはマッチしなくなります。含まれるようになります。する)使う側が理解しやすくなります。あるのでこちらも覚えておきましょう。内にインデックスする制限がある)。構造に落とし込む設計イメージになります。オブジェクトと比較したメリット・デメリットを以下にまとめました。子のドキュメントは検索要求の結果として返すことができる。デメリット:クエリーのパフォーマンスが落ちるメモリを多く消費するデメリットも少しありますが、正直どれくらいパフォーマンスに違いがあるのかわかりません。設計すると良い感じでしょうか?まとめいかがでしたでしょうか?今回は「データスキーマ設計のいろは」というテーマで解説しました。乗り換えるだけのメリットがあります。これらの特徴を理解して、最適な設計に役立ててください。Elasticsearch」もよろしくお願いします。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。使いたいときの注意点を書きました。本が出ていたので読んでみたところよかったので紹介させていただきます。