MapR-DB JSONとBinaryについて データモデル編

アドベントとしては既にかなり破綻していますが、ノロノロ粛々と記事を書いていきたいと思っている4日目です。
本日のお題はMapR-DBです。

MapR-DBはMapR Technologies社が提供するNOSQL DBとなります。
MapR-DBにはMapR-DB JSON(以下、JSONテーブル)とMapR-DB Binary(以下、Binaryテーブル)の2種類存在します。

本記事ではこれらの違いについてデータモデル的な観点から比較を行っていきます。
性能や管理コマンド、MapR 6.0でJSONテーブルに追加された新機能などについては他の日のエントリーに回します。
なお、本記事の内容はこちらの内容を和訳して簡単にまとめたものとなります。※完訳ではありません。

JSON テーブル

• JSONテーブルは名前の通りJSONドキュメントを格納します。つまり、階層的かつネストになったデータを格納出来、かつデータは更新可能となります。
• JSONテーブルではMapR社がメインで開発しているOJAI : Open Json Application Interface（オージェーエーアイ、もしくはオーハイ）データ・モデルとOJAI APIを利用します。
• ドキュメントはJSON形式ですが、実際にはバイナリで保存されており、テキスト形式で保存されているわけではありません。
• JSONテーブルでは'_id'フィールドがrowkeyとして扱われ、JSONドキュメントがvaueとなります。
• テーブルはMapRファイルシステム上の任意のパスに格納されます。
• それぞれのドキュメントのフィールド、もしくはフィールドのサブセット、もしくはドキュメント全体をディスクから読み書きします。個々のフィールド、もしくはフィールドのサブセットの更新の際には、ドキュメント全体を読む必要はなく、更新を行ったらその分だけディスクに書き出します。
• OJAIではJSONがサポートする標準的な型よりも多くのデータ型を利用して複雑なクエリを生成し、コネクションやコンフィグレーションオブジェクトなしにJSONテーブルにアクセス可能です。
• クエリ結果のフィルタはクライアントに戻る前にMapR-DB内で行われます
• サポートするプラットフォームはLinux, OS X, Windowsです。
• 他のクラスタにデータをコピーすることなく、リアルタイムにApache Drillやその他の解析ツールからアクセス可能となります。
• 数千ノード規模でスケールします。
• MapRのAccess Control Expression(ACE)機能により、単一、もしくは複数のフィールド単位で読み書き制御狩野です。
• JSONテーブル内の単一フィールドとサブドキュメントのディスクレイアウトを制御できます。

JSON ドキュメント

JSON テーブルが利用するJSON ドキュメント特徴としては以下のような点が挙げられます。

• スカラー、ネストドキュメント、配列の3つのタイプでデータを格納可能
• スキーマは柔軟であり、新たなフィールドをいつでも追加出来ます。各rowでJSONの構成が同一である必要はありません
• フィールドを特定する際には”.”(ドット)を利用することが出来ます

{
  "a" : {
          "b" : {
                  "c" : {
                          "d" : "value_for_d"
                        }
                 }
         }
} 

上記のdのパスはa.b.c.dとなります

JSONテーブルのカラムファミリー（CF)

JSONテーブルはCF上に格納され、CF単位でディスク上に格納されます。
JSONテーブルではCFを新たに作成し、一つ以上のフィールドを別のCFに格納することで、ディスク上の離れた場所にデータを格納できます。
一つのCFに格納されたデータに対してクエリやオペレーションを実行することで、テーブル内のその他のデータと同居するデータよりも、より効率的かつ高い性能を実現出来ます。
またキャッシュの効率も良くなります。
JSONテーブルでは64個までCFを作成できます

Binary テーブル

• BinaryテーブルはApache HBaseとコンセプト的には同じで、ワイドカラムストア型のデータベースとなります。
  • 実際にBinaryテーブルはHBaseのデータ・モデルを利用し、HBase APIをサポートしています。
• Binaryテーブルはカラムナデータを必要とする大規模アプリケーションでも利用可能となり、標準的なHBaseアプリケーションAPIを利用するアプリケーションとバイナリ互換性を持ちます。
• Binaryテーブルでは、keyによってrowがインデックスされ、各行のカラムによってデータ要素が決定されます。CFは一つ以上のカラムのグループから成ります。
• Keyのサイズは最大で64KBまでとなります。ただし、数百バイト程度にしておくのが推奨されます。
• Rowは一つ以上のCFにまたがります。Rowのサイズは最大で2GBまでサポートされます。ただし、2MB程度までにしておくのが推奨されます。一般的にはMapR-DBの性能はたくさんの小さいRowを持つテーブルほど良くなります。
• CFは一つ以上のカラムから成り立ちます。MapR-DBでサポートされるCFの数は64までとなります。
• カラムは一連のタイムスタンプと関連してValueを決定するキーとなります。

BinaryテーブルのCF

テーブル全体をスキャンするのは非効率的ですが、CFにアクセスすることでアクセスする範囲を狭め、性能を高めることが出来ます。
また、CFごとに圧縮機能を設定することで、ニーズに応じたレイテンシや消費ディスクの効率を設定することが出来ます
ただし、各CFに存在するおおよその行数である、cardinality(カーディナリティ)に注意する必要があります。
CFごとのカーディナリティの差が大きい場合、行数の少ないCFのデータは複数のノードに散らばりがちになります。
これは行数が多いCFがより多くのSplitを必要とするためです。
そのため、CFごとのカーディナリティの差が大きい場合、行数の少ないにも関わらずCFのスキャンに時間がかかることがあります。

MapR-DBではカラムレベルではなく行レベルでSplitが発生します。
そのため、非常に多くのカラムを持つ極端にワイドなテーブルにおいては、行数が比較的少なくともスプリットが推奨されるテーブルサイズに到達します。
そのため、一般的には行数が多く、カラム数が少なくなるように設計することが重要です。

MapR-DBテーブルではカラムをいつでも追加することが出来ます。
また、カラムがNullの場合はストレージ容量は消費されません。

まとめ

以上、各テーブルのデータモデル観点から説明でした。
MapR-DBについてはまだまだ紹介することがたくさんありますので、新しい記事が出てくることでしょう！！！（期待）