まず、NOSQLという新しい動向は、伝統的なRDBMS（リレーショナル・データベース管理システム）を無条件に否定するものではありません。この動向は、今日のデータ環境がSQLだけに留まらず（Not Only SQL：NOSQL）、ストレージに多様なツールが必要であるという認識が急速に広がっていることの表われです。リレーショナル型のデータ・ストレージとNOSQL型のデータ・ストレージは、それぞれ異なるアプローチを持ち、異なる種類のアプリケーションやサービスに適しています。これらは互いに補完するものであると理解してください。 　NOSQLが注目されるようになった背景には、TB（テラバイト）あるいはPB（ぺタバイト）級のデータを保管して使うアプリケーションやサービスの急増という現状があります。その分野では頻繁に「常時使用可能」な可用性を保証し、エンドユーザーの待ち時間を減らす努力が払われてきました。たとえば次のような多くの市場分野で、さまざまな組織がBig Data時代の到来に備えて取り組んでいます。

　これらの分野に限らず、大量データを扱う環境にあるあらゆる組織が、いまや未曽有の大規模データを保管するシステムを構築する問題に直面しています。RDBMSとハイエンドの専用ハードウェアを軸とする伝統的なデータ保管アプローチではこうしたニーズに応えられないと、多くの組織は既に気づいています。特に問題になるのは、次の点です。

　先進的な組織では、コストや複雑性にしわ寄せせずにBig Dataに適した容量を実現させようと、より良いスケーリングの方法を追求してきました。また、増加の一途をたどる使用シナリオのすべてが、RDBMSの複雑なクエリー機能や管理機能を必要とするわけではないことも、同時に明らかになってきました。アプリケーションやサービスによっては、SQL構造や厳密なACIDが必要ないものもあります。さらに環境によっては、これらの過剰機能が高価につき、柔軟性と即応性が要求される非常に厳しい市場競争の中で、サービス提供が妨げられる可能性すらあります。

　つまり、近年急増しているサービスで必要とするデータは、より大規模になる一方で、構造化の必要性はより少ないのです。

　そう考えると、業界を牽引するWeb企業がNOSQLの動きの最前線にいるのは不思議なことではありません。特に、Google社の BigTable論文（2006年） と、Amazon社の Dynamo論文（2007年）は、NOSQL市場に大きな影響を及ぼしました。BigTable やDynamo、あるいはその両方から構想を得たNOSQLソリューションが多数存在しており、ここ2年でいくつかのソリューションがオープンソースのコミュニティで発表されています。

　NOSQLを使ったデータ・ストレージソリューションは、それぞれ細かい点では異なりますが、基本的に次のような共通点があります。

　NOSQLストレージ・ソリューションの歴史や長所、あるいは設計の問題等についてさらに詳しく知りたい場合は、Webで検索してください。

　Hibariは、Cloudian社(旧Gemini Mobile Technologies）が社内で開発したものです。Cloudian社は、アジア、ヨーロッパ、アメリカで、Tier 1モバイル・オペレータ向けの大規模メッセージングおよびトランザクション・システム開発分野の先頭に立つ企業です。Cloudian社が必要とするデータストアは、Tier 1通信事業分野向け製品の導入環境に必須の堅牢さに加えて、効率的で高速かつ柔軟性を備え、拡張可能なものです。ところが、当時利用できる選択肢の中には満足できるものはありませんでした。そこで2005年に、Cloudian社はのちに「Hibari」となるシステムの開発に着手しました。Hibariという名称は漢字では「雲雀」と書き、「クラウドの鳥」を意味します。その後、システムが成熟して製品化できるようになったのを機に、2010年7月、Cloudian社はApache 2.0ライセンスの下でHibariをオープンソースのコミュニティにリリースしました。Hibariが成長を続けて完成度を高める場として最も適しているのはオープンソースのコミュニティであると、Cloudian社は考えています。

　ここからは、Hibariの特長について説明します。これらの特長によって、Hibariは現代のBig Dataストレージ・システムを求めるビジネスおよび開発者にとって魅力的な選択肢となっています。

簡単でコストが低廉な拡張性

　Hibariは次に示すように、クラスターの増加に伴うコストと運用上の複雑性を最小限に抑えながらBig Dataに拡張性を提供します。

• Hibariは、物理ノードを追加して、そこに追加チェインを配置することによって、水平に拡張できます。Hibariのクラスターにマシンを追加するごとに、クラスターのストレージ容量の合計と処理性能は線形に増加します。
• クラスターにチェインを追加（または削減）する場合、システムは中断時間なしでストレージの自動データ配置バランシングを行うため、サービスを中断せずにHibariのストレージ・クラスターを拡大（または縮小）できます。
• Hibariは、汎用のPC上で稼働します。またシステムは、異なるハードウェア・リソースに容易に対応できます。ストレージ・クラスター内のブリックは、異なる容量のRAMやディスクを使用でき、CPUのさまざまな処理速度にも対応できます。異なるハードウェアを組み合わせてクラスターを構成する場合、Hibariのコンシステント・ハッシュ機能をチューニングしてクラスターの使用状況を最適化することも可能です。各チェインに重み付けファクターを指定して、キー・スペース全体に占めるチェインの割り当てを、他のチェインに比べて増加または減少させることもできます。

　Hibariは、異種のハードウェアの混在をサポートするだけでなく、Erlangをベースとしているため、ほとんどすべてのオペレーティング・システム上で稼働します。異種のハードウェアおよびオペレーティング・システムに容易に対応できるので、利用できるあらゆるリソースを用いてHibariをインクリメンタルに拡張できます。すべてのリソースを同時に、また同一の種類に揃えて購入する必要はありません。

	Hibariの水平拡張の上限値は、明確には決まっていませんが、Erlangに組み込まれたネットワーク分散機能の実装の限界から見て、200〜250ノードが実質的な限界になります。また、Hibariのチェインは、理論的には複数のデータ・センターをまたがって延長しで地理的な冗長性を確保することも可能ですが、現在のところ、単一のデータ・センター内の配置しかテストしておらず、稼働実績はありません。

　Hibariのクラスター・サイズの変更に関する詳細情報は、「Hibari®システム管理者ガイド」の 動的なクラスター構成変更の節を参照してください。

シンプルながら強力なクライアントAPI

　Hibariの中核をなすデータモデルとクライアントAPIは、キー・バリュー・ストア方式としてシンプルな設計がなされています。BLOBベースのキーとバリューのペアが、辞書のようにソートされたテーブルに対して、追加、検索、削除を行います。Hibariは、キー・バリュー・ストア方式に伴う柔軟性と拡張性を提供していますが、それと同時に、クライアント・アプリケーションと開発者のパワーを増強する次のような大きな特長を備えています。

• オプションとして、クライアントがオブジェクト単位に有効期限を設定できます。
• オプションとして、クライアントがオブジェクト単位にカスタム・フラグを設定できます。この柔軟性を備えたカスタム・メタデータの更新は、関連するバリューBLOBの更新の有無によらずに可能であり、検索もバリューBLOBの有無によらず可能です。
• オブジェクトの更新のつど、自動的にタイムスタンプを取得します。このタイムスタンプの仕組みにより、「テスト・アンド・セット」型の命令の実行が可能になります。つまりクライアントは、対象のキーのタイムスタンプが期待したものである場合にのみ、要求した命令を実行するように指定できます。
• HibariのクライアントAPIは、キーの制限範囲内で（具体的にはチェイン全体ではなく特定のチェイン内で）、アトミック・トランザクションをサポートします。この「マイクロ・トランザクション」のサポートは、他のオープンソースのKVDBにはないHibariの特長であり、これによって堅牢なクライアント・アプリケーションの作成がずっと簡単になります。

　Hibariは、複数のクライアントAPIの実装をサポートしています。たとえば、次のようなものがあります。

• ネイティブErlang
• ユニバーサル・バイナリ・フォーマット（UBF）
• Thrift
• Amazon S3
• JSON-RPC

　Hibariのクライアント・アプリケーションは、Java、 C/C++、Python、Ruby、Erlangなど幅広い言語で開発できます。

　HibariのクライアントAPIに関する詳細情報は、Client API: Native Erlangおよび当ガイドでこのあと説明するクライアントAPIの章を参照してください。

	HibariのソースコードディストリビューションにはAmazon S3とJSON-RPCは含まれません。これらは別の外部プロジェクトです。

HibariはErlangの VMをサポートするUNIXとUNIX系、およびWindows、Mac OS Xなどのオペレーティング・システム（以下、OS）上で稼働します。詳しくは、Erlangの公式サイト Implementation and Ports of Erlang を参照してください。 　 また、稼働環境に必要なハードウェア要件については、「Hibariシステム管理者ガイド」の ブリックのハードウェアに関する注意を参照してください。

Hibariに必要なサードパーティのソフトウェアは、シングルノードのインストールか、マルチノードのインストールかによって、異なります。

現在、Hibariはビルド済みで提供することができません。当面は、ソースコードからHibariをビルドしてください。第7章の TODO(「7. ソースコードからHibariをビルドする」) の説明に従ってビルドして、その後、本節に戻ってセットアップを行ってください。

Hibariをビルドすると、後でセットアップに使用する2つのファイルが出力されます。 - tarballパッケージ“hibari-X.Y.Z-DIST-ARCH-WORDSIZE.tgz” - md5sumファイル“hibari-X.Y.Z-DIST-ARCH-WORDSIZE-md5sum.txt”

_X.Y.Z_はリリースバージョン、_DIST_はリリースのディストリビューション、_ARCH_はリリースのアーキテクチャ、_WORDSIZE_はリリースのワードサイズです。

シングルノードにHibariをインストールしたシステムには、マルチノードのHibariクラスターが提供するようなデータのレプリケーションや冗長性はありません。しかし、テストや開発上の目的で簡単にHibariをシングルノードにインストールして配置したいときは、この方法を利用します。

	Hibariノードでは、システムの /etc/sysctl.conf ファイルに vm.swappiness=0 を設定してください。ErlangのVMにおいてswappinesssの指定は望ましくありません。

ターゲットノードにHibariをインストールする前に、以下の準備を実行してください。

ユーザー権限の設定

インストール時に使用するシステムのユーザーIDは、Hibariの実行時のユーザーIDとは異なるものでなければなりません。インストールを実行するユーザーアカウント ($USER) は、以下のようにセットアップします。

• $USERは、インストールノードにも、ターゲットHibariノード群にも必要です。
• $USERは、インストールノードにおいてSSHの公開鍵と秘密鍵を持つ必要があります。パスワード認証なしにSSHでログインできるようにSSH agentを設定してください。
• $USERアカウントは、ターゲットのHibariノードでも、パスワード認証なしにSSHでログインできなければなりません。
• $USERアカウントは、ターゲットのHibariノード上で、パスワード認証なしにsudoコマンドでアクセスできなければなりません。

インストールを実行するユーザーのアカウントに上記の権限がない場合は、以下のステップを実行してください。

1. rootユーザーとして、インストールノードにインストールユーザー ($USER) を追加します。その後、各Hibariノードにインストールユーザーを追加して、そのユーザーにパスワード認証なしのsudo権限を付与します。

   $ useradd $USER
   $ passwd $USER
   $ visudo
   # append the following line and save it
   $USER  ALL=(ALL)       NOPASSWD: ALL

   	sudoのテスト中に“sudo: sorry, you must have a tty to run sudo”というエラーメッセージが出た場合は、 /etc/sudoers ファイル内の次の行をコメントアウトしてください。

   $ visudo
   Defaults    requiretty

2. インストールノードに、インストールユーザー用のSSHの公開鍵と秘密鍵を新たに作成します。

   $ ssh-keygen
   # enter your password for the private key
   $ eval `ssh-agent`
   $ ssh-add ~/.ssh/id_rsa
   # re-enter your password for the private key

3. 各Hibariノードにおいて

   • \~/.ssh/known_hosts ファイルに、インストールノードのエントリーを追加します。

   • ~/.ssh/authorized_keys ファイルに、SSHの公開鍵のエントリーを追加します。

     以下の例では、dev1、dev2、dev3がターゲットのHibariノード群です。

     $ ssh-copy-id -i ~/.ssh/id_rsa.pub $USER@dev1
     $ ssh-copy-id -i ~/.ssh/id_rsa.pub $USER@dev2
     $ ssh-copy-id -i ~/.ssh/id_rsa.pub $USER@dev3

     	インストールノードがHibariのクラスターノードの１つである場合は、インストールノードにもssh-copy-idを実行する必要があります。

4. 各Hibariノードへのパスワード認証のないSSHのアクセスが、期待どおりに行われることを確認します。

   $ ssh $USER@dev1
   $ ssh $USER@dev2
   $ ssh $USER@dev3

	SSHのセットアップの詳細について知りたい場合は、 ( http://inside.mines.edu/~gmurray/HowTo/sshNotes.html )を参照してください。

Clusterインストーラーツールのダウンロード

“Cluster”とは、Hibariのノード群のクラスターのインストールと設定、およびブートストラップに使用する簡単なツールです。このツールはHibariパッケージの一部ではありませんが、GitHubから入手できます。

	Clusterは、多くのユーザーのニーズを満たすツールです。ただし現在、このツールの「ターゲットノード」のレシピはLinux主体に書かれています（たとえばuseraddや userdelなど）。その他のOSやプラットフォーム向けのパッチ類の提供が望まれます。Linux以外の配置の場合のClusterツールは比較的単純で、ツールのレシピどおりに操作すれば手動でインストールできます。

1. Clusterツールをダウンロードするための作業用ディレクトリを作成します。

   $ mkdir working-directory

2. GitHubからClusterツールのGitリポジトリをダウンロードします。

   $ cd working-directory
   $ git clone git://github.com/hibari/clus.git

   このダウンロードにより、clus というサブディレクトリが作成され、その下に、インストーラーツールと種々のサポートファイルが格納されます。

Clusterツールの設定

Clusterツールには、Hibariのクラスターのセットアップ方法を示す基本的な設定情報が必要です。必要な設定を明記した簡単なテキストファイルを作り、Clusterツールを稼働させる際に、そのファイルをインプットとして使ってください。

設定情報ファイルは、Clusterツールをダウンロードした作業用ディレクトリ内に作成するのが最も簡単です。ファイル名は何でもかまいません。ここでは説明のために hibari.config というファイル名を使用します。

以下は hibari.config ファイルのサンプルです。作成するファイルには、ここに示したすべてのパラメータを記載する必要があります。またその値は、この例と同じ書式（括弧や引用符も）でなければなりません。パラメータの記述はサンプルに従ってください。

ADMIN_NODES=(dev1 dev2 dev3)
BRICK_NODES=(dev1 dev2 dev3)
BRICKS_PER_CHAIN=2

ALL_NODES=(dev1 dev2 dev3)
ALL_NETA_ADDRS=("10.181.165.230" "10.181.165.231" "10.181.165.232")
ALL_NETB_ADDRS=("10.181.165.230" "10.181.165.231" "10.181.165.232")
ALL_NETA_BCAST="10.181.165.255"
ALL_NETB_BCAST="10.181.165.255"
ALL_NETA_TIEBREAKER="10.181.165.1"

ALL_HEART_UDP_PORT="63099"
ALL_HEART_XMIT_UDP_PORT="63100"

• ADMIN_NODES

  • Hibari Adminサーバーを起動できるノード群のホスト名。Adminサーバーに関する詳細は、「Hibariシステム管理者ガイド」の Adminサーバーアプリケーションを参照してください。

• BRICK_NODES

  • Hibariのストレージ・ブリックとして機能するノード群のホスト名。上記設定ファイルのサンプルには3つのストレージ・ブリックのノード（dev1、dev2、dev3）があり、この3つのノードのそれぞれでAdminサーバーを稼働できます。

• BRICKS_PER_CHAIN

  • チェイン・レプリケーションごとのブリック数。たとえば、1チェインあたり2ブリックであれば、チェインに格納されるデータには2つのコピーが存在します（ブリックごとに1コピー）。1チェインあたり3ブリックであれば、3つのコピーが存在します。チェイン・レプリケーションの概要は、本ドキュメントの「1.2.2 チェイン・レプリケーションによる高可用性と強い一貫性」を参照してください。チェイン・レプリケーションの詳細は、Hibariシステム管理者ガイドを参照してください。

• ALL_NODES

  • ADMIN_NODES と BRICK_NODES の和集合によって得られるHibariの全ノードのリスト。

• ALL_NETA_ADDRS

  • 「Hibariシステム管理者ガイド」の パーティション化検出アプリケーションに記述されているように、マルチノードのHibariのクラスター内の各ノードは、2つのネットワーク（ネットワークAおよびネットワークB）に接続されていなければなりません。これは、ネットワークのパーティションを検出および管理するためです。 ALL_NETA_ADDRS パラメータで、ネットワークA内の各HibariノードのIPアドレスを指定します。このネットワークAを介して、データ・レプリケーションおよびその他のErlangの通信が行われます。IPアドレスの一覧は、 ALL_NODES で指定したホスト名に対応している必要があります。

• ALL_NETB_ADDRS

  • ネットワークB内におけるHibariの各ノードのIP アドレス。ネットワークBは、ネットワークパーティションの検出に役立つハートビートブロードキャストのためだけに使用されます。IPアドレスの一覧の順番は、ALL_NODESで設定したホスト名の順番に対応している必要があります。

• ALL_NETA_BCAST

  • ネットワークAのIP ブロードキャストアドレス。

• ALL_NETB_BCAST

  • ネットワークBのIP ブロードキャストアドレス。

• ALL_NETA_TIEBREAKER

  • ネットワークAでパーティション問題が発生した場合に、「タイブレーカ」として使用するネットワーク監視アプリケーション用のIPアドレス。Hibariノードにおいて、ネットワークAにパーティションが発生し、ネットワークBにはパーティションが発生していないとネットワーク監視アプリケーションが判断した場合、ネットワークAのタイブレーカのIPアドレスがpingに応答すれば、ローカルノードはパーティションの「正しい」側に存在することになります。タイブレーカは、Erlangのすべてのネットワーク通信が配信されるレイヤ2のスイッチまたはレイヤ3のルータのアドレスであることが望まれます。

• ALL_HEART_UDP_PORT

  • ハートビート・リスナー用のUDPポート。

• ALL_HEART_XMIT_UDP_PORT

  • ハートビート・トランスミッター用のUDPポート。

ネットワーク監視の設定に関する詳細は、パーティション検出のOTPアプリケーションのソースファイル (https://github.com/hibari/partition-detector/raw/master/src/partition_detector.app.src) を参照してください。

	稼働時の設定では、ネットワークAとネットワークBを、物理的に異なるネットワークおよびネットワークインターフェイスにするべきです。しかし、テストおよび開発時には、ネットワークAとネットワークBを物理的に同じネットワークにすることができます（設定ファイルの上記サンプルと同様）。

最終ステップとして、 各Hibariノード で

• /etc/hosts ファイルに、クラスター内のすべてのHibariノード群のエントリーがあることを確認します。

  10.181.165.230  dev1.your-domain.com    dev1
  10.181.165.231  dev2.your-domain.com    dev2
  10.181.165.232  dev3.your-domain.com    dev3

• システムの /etc/sysctl.conf ファイルに vm.swappiness=0 を設定してください。Erlangの VMにおいてswappinessを指定することは望ましくありません。

Hibariのインストール

インストールノードからインストールユーザーとしてログインし、以下の手順でHibariクラスターを作成します。

1. Clusterツールのダウンロードおよび クラスター設定情報ファイルの作成を行った作業ディレクトリに、Hibariのtarballパッケージとmd5sumファイルがあることを確認します。

   $ cd working-directory
   $ ls -1
   clus
   hibari-X.Y.Z-DIST-ARCH-WORDSIZE-md5sum.txt
   hibari-X.Y.Z-DIST-ARCH-WORDSIZE.tgz
   hibari.config
   $

2. Hibariのすべてのノードに、”hibari”というユーザーを作成します。

   $ for i in dev1 dev2 dev3 ; do ./clus/priv/clus.sh -f init hibari $i ; done
   hibari@dev1
   hibari@dev2
   hibari@dev3

   	“hibari”ユーザーがすでにそのノードに存在する場合は、-fオプションが“hibari”ユーザーを強制的に削除して、再度作成します。

3. 新たに作成した「hibari」ユーザーを通して、HibariのすべてのノードにHibariパッケージをインストールします。

   $ ./clus/priv/clus-hibari.sh -f init hibari hibari.config hibari-X.Y.Z-DIST-ARCH-WORDSIZE.tgz
   hibari@dev1
   hibari@dev2
   hibari@dev3

	デフォルト設定では、Clusterツールはターゲットノード群の /usr/local/var/lib にHibariをインストールします。別の場所へインストールしたい場合は、インストールの前に clus.sh スクリプト（作業用ディレクトリの /clus/priv/ の下）を開き、 CT_HOMEBASEDIR 変数を編集してください。

マルチノードのHibariクラスターの起動および停止は、インストールプロセスを管理したノードから、Clusterツールを使って行います。本節で説明するHibariの各コマンドは、インストール手続き中に作成した Clusterツール設定情報ファイルのファイル名を参照することに注意してください。

$ cd working-directory
$ ./clus/priv/clus-hibari.sh -f stop hibari hibari.config
ok
ok
ok
hibari@dev1
hibari@dev2
hibari@dev3

新しいテーブルは、AdminサーバーのGUIを通して作成するのが最も簡単です。“http://localhost:23080/” を開き、“Add a table” をクリックしてください。GUIに加えて、hibari-admin ツールで新しいテーブルを作成することも可能です。詳しい使用法は、hibari-admin ツールの説明を参照してください。

	管理用のAPIを使ったテーブル作成の方法については、「Hibariシステム管理者ガイド」を参照してください。

GUIを使ってテーブルを追加する場合、以下のようなテーブル設定のオプションがあります。

キー・バリュー型データベースとしてHibariが提供するクライアントAPIは非常にシンプルです。APIによって、データの追加、検索、削除という基本的な操作ができます。制限はありますが、その範囲内で操作を組み合わせればアトミック・トランザクションも実行できます。

HibariのクライアントAPIで実行できる操作は、次のとおりです。ネイティブErlangのAPIの各操作の詳細に関しては、リンク先を参照してください。

データの追加　

データの検索

データの削除

複合操作

フォールド操作

クライアント側の必要に応じて、データの追加、検索、削除に「テスト・アンド・セット」ロジックを適用すると、指定したキーのタイムスタンプと一致する場合にのみ操作を実行させることができます。

Erlangの基本データ型

この章で参照するErlangの基本データ型について、簡単に紹介します。これは、 Erlangのデータ型に関する公式ドキュメントからの抜粋を少し変更したものです。詳細な情報は、Erlangの公式ドキュメントを参照してください。

	すべてのErlangのコマンドは、最後にピリオド（’.’）をつけてください。

項（term）

すべてのデータ型のデータを 項(term) と呼びます。

数値（number）

数値定数には、 Integer(整数)型 と Float(浮動小数点)型 の2種類があります。

アトム（atom）

アトム（atom）はリテラル（名前を持つ定数）です。英小文字以外で始まるアトム、および英数字と下線（’_’）と’@’以外を含むアトム場合は、次の例のように一重引用符（’）で囲んでください。

hello
phone_number
'Monday'
'phone number'
'hello'
'phone_number'

Bit string（ビット列）とBinary（バイナリ）

Bit string(ビット列) は、型指定のないメモリー領域にデータを保管するときに使用します。表記は、 Erlangのビット構文に従います。また、8の倍数のビット数からなるビット列を、 Binary(バイナリ) と呼びます。たとえば次のように表します。

<<10,20>>
<<"ABC">>

Tuple（タプル）

Tuple(タプル) は、固定数の項の組からなるデータ型です。次の例のように、中括弧（’{ }’）で囲んで表します。

{Term1,...,TermN}

List（リスト）

List(リスト) は、可変数の項の組からなるデータ型です。次の例のように、大括弧（’[ ]’）で囲んで表します。

[Term1,...,TermN]

String（文字列）

String(文字列) は、二重引用符（”）で囲んで表します。これは、Erlangの正式のデータ型ではありません。リスト[$h,$e,$l,$l,$o]、つまり[104,101,108,108,111]の代わりに、簡略化した表現として”hello”という文字列を使用します。

Boolean（ブール）

ErlangにBoolean型（論理型）はありません。ブール値を表す場合は、代わりにアトムの 真（true） と 偽（false） を使用します。

CREATE TABLE foo (
    BLOB key;
    BLOB value;
    INTEGER timestamp;                  -- Monotonically increasing
    INTEGER expiration_time;            -- Usually zero
    LIST OF ATOMS_AND_TWO_TUPLES flags; -- Metadata stored in RAM for speed
) PRIMARY KEY key;

書式

解説

引数

戻り値

エラー終了の場合

エイリアス

例

書式

解説

引数

戻り値

エイリアス

例

書式

解説

引数

戻り値

エイリアス

例

書式

解説

引数

戻り値

エイリアス

例

書式 :: brick_simple:get(Tab, Key, Flags, Timeout).

解説

引数

戻り値

正常終了の場合

エイリアス

例

書式

解説

戻り値

正常終了の場合

エイリアス

例

書式

解説

引数

戻り値

エイリアス

例

書式

解説

引数

戻り値

エイリアス

例

書式

解説

	データの移行処理中にこの操作を実行しないでください。

引数

戻り値

エイリアス

例

_（追加予定）

書式

解説

	データの移行処理中にこの操作を実行しないでください。

引数

戻り値

エイリアス

例

_（追加予定）

Erlang言語は、ストリング（文字列）をデータ型として明確にはサポートしておらず、整数（ASCIIバイト値）やバイナリのリストとして表現します。

一方、UBFコントラクトは、ストリングとリストとバイナリを区別します。ストリングの場合、UBF(A)は、ストリング "Hello, world!" を {'#S', "Hello, world!"} と表記します。

しかし、開発者にとって、このストリング表記を使用するのは煩雑です。Erlangでは、ubf.hrl ヘッダー・ファイルに ?S("Hello, world!") というマクロが入っており、少しはましな近道になります。他の言語を使用する際には、いずれかの2項のタプルとアトムとして、2項のタプルとアトム '#S' を作成できます。

幸いなことに、ストリングが必要になるのは、 startSession メタプロトコル・コマンドを用いてHibariデータ・サーバー・コントラクトの使用を開始する際の1回だけです。以下に例を示します。

UBFベースのプロトコルを使用する場合、すべての言語で同じ手順に従います。

HibariのUBFプロトコル・コントラクトは、ファイルubf_gdss_plugin.con にあります。

	このファイルの最新版は、Hibariのソースコードを参照してください。 このドキュメント内にもファイルubf_gdss_plugin.con のコピーがありますが、さらに改訂版が出ている可能性があります。

コントラクト内で指定されるUBFの型名は、「クライアントAPI ： ネイティブErlang」で使用している型名とは少し違います。たとえば、UBFコントラクトでは、キーの有効期限を exp_time() としていますが、このドキュメントでは expiry() としています。多少名前が違っても、有効期限として両方の名前が使用する基本データ型は同じinteger() です。

UBFコントラクトでは、各コマンドに次の命名規約を使います。

UBFのRPCコールは、タプルの形式になるのが一般的です。タプルの最初の要素がコマンド名で、後続の要素がそのコマンドの引数です。応答はErlangのいずれのデータ型の項でも返せますが、Hibariのコントラクトは、アトム型かタプル型の応答のみを返します。

以下に、UBFのクライアント要求とErlangのAPIのマッピングをアルファベット順に示します。

	Erlangシェルを実験やプロトタイプで使用する場合、シェルのサーチ・パスに、ErlangのUBFクライアント・ライブラリへのパスを入れなければなりません。その一番簡単な方法は、Erlangシェルの erl コマンドの引数として、次を使用することです。 -pz /path/to/ubf/library/ebin コードを作成する場合は、?S() マクロを使用できるように、ソースモジュールの先頭行に次のステートメントを置いてください。 -include("ubf.hrl"). Erlangシェルの制限により、シェル中ではマクロを使用できません。

「すべての言語におけるUBFベースのプロトコルの使用手順」 で概説したように、最初のステップは、Hibariサーバーへのコネクションを作成することです。Hibariクラスターにノードが複数ある場合は、どのノードへのコネクションを作成しても構いません。すべてのノードがすべてのUBF要求に対応し、要求を適切なブリックに回すことができます。

UBFサーバー（“localhost”のTCPポート7581）へのコネクションを作成する. 

(asdf@bb3)54> {ok, P1, _} = ubf_client:connect("localhost", 7581, [{proto, ubf}], 5000).
{ok,<0.139.0>,{'#S', "gdss_meta_server"}}

次に、このコネクションを用いてコマンドを使用していくために、UBFメタプロトコルを用いて、Hibariサーバーの“gdss” と呼ばれるコントラクトを選択します。

	Hibariサーバーのコントラクトは「ステートレス」です。ubf_client:rpc/2 関数からの応答に含まれる項はすべて{reply,ServerReply,UBF_StateName} の形式をとります。Hibariサーバーのコントラクトはステートレスであるため、UBF_StateName は常にアトムnone になります。

UBFメタプロトコルを用いて“gdss”コントラクトを要求する. 

(asdf@bb3)55> ubf_client:rpc(P1, {startSession, {'#S', "gdss"}, []}).
{reply,{ok,ok},none}

これでUBFコネクションが確立しました。このコネクションを用いてキー「foo」を設定します。

テーブル tab1 に、キー「foo」を設定する（バリューは「foo val」、有効期限とフラグは指定なし、タイムアウト時間は5秒）. 

(asdf@bb3)59> ubf_client:rpc(P1, {set, tab1, <<"foo">>, <<"foo val">>, 0, [], 5000}).
{reply,ok,none}

	上記の例のset_req() と下記の例の get_req() の両方で、戻り値の値は、それぞれ「brick_simple:set/6」 と 「brick_simple:get/4」 に記述されたとおりであることに注意してください。 唯一の違いは、ubf_client:rpc/2 関数では、サーバーからの応答を3項のタプル {reply,ServerReply,none}.としてまとめることです。

テーブルtab1 から、キー「foo」を取得する（タイムアウト時間は5秒）. 

(asdf@bb3)66> ubf_client:rpc(P1, {get, tab1, <<"foo">>, [], 5000}).
{reply,{ok,1273009092549799,<<"foo val">>},none}

クライアントがコントラクトに違反する要求を送信すると、下記の例のように、サーバーが違反を返します。

コントラクト違反の要求を送信する. 

(asdf@bb3)89> ubf_client:rpc(P1, {bbb, 3000}).
{reply,{clientBrokeContract,{bbb,3000},[]},none}

コネクションを使い終わったら、明示的にコネクションを終了させるのがきまりです。クライアントがstop/1 の呼び出しを忘れた場合や呼び出せない場合は、サーバーがコネクションのサーバー側のクリーンナップ処理を暗黙のうちに実行します。

UBFコネクションをクローズする. 

(asdf@bb3)92> ubf_client:stop(P1).
ok

Java用UBFクライアント・ライブラリのソースコードは、 http://github.com/ubf/ubfにあるUBFソース・リポジトリのpriv/java サブディレクトリにあります。

public class HibariTest
{
    public static void main(String[] args)
        throws Exception
    {
        Socket sock = null;
        UBFClient ubf = null;

        try {
            sock = new Socket(args[0], 7581);
            ubf = UBFClient.new_via_sock(new UBFString("gdss"), new UBFList(),
                    new FooHandler(), sock);
        }
        catch (Exception e) {
            System.out.println(e);
            System.exit(1);
        }

        test_hibari_basics(ubf);

        ubf.stopSession();
        System.out.println("Success, it works");
        System.exit(0);
    }
/* ... */
}

UBFのイベント・ハンドラーのインターフェイス

UBFClient の各インスタンスは、個別のスレッドを用いてサーバーからデータを読み出し、次のいずれかを実行します。

1. 同期RPCの応答をサーバーから受信したというシグナルを他のスレッドに送ります。
2. サーバーから event_out 非同期イベントを受信した場合は、コールバック機能を実行します。
3. ソケットをそのままクローズします。

2番目と3番目は、UBFEventHandler インターフェイスを実装するクラスを用いて、この場合に実行するアクションを定義します。

HibariTest.java は、非同期イベントに対応するコールバック機能のサンプルを実装しています。実際のアプリケーションでは、このサンプルよりずっと多くの処理が必要です。

    public static class FooHandler implements UBFEventHandler {
        public FooHandler() {
        }
        public void handleEvent(UBFClient client, UBFObject event) {
            System.out.println("Hey, got an event: " + event.toString());
        }
        public void connectionClosed(UBFClient client) {
            System.out.println("Hey, connection closed, ignoring it¥n");
        }
    }

	このFooHandler クラスの使用例は、ubf.HibariTest.main()メソッド を参照してください。

Python用のEBFクライアント・ライブラリのソースコードは、http://github.com/ubf/ubfにあるUBFソース・リポジトリのpriv/python サブディレクトリにあります。

	EBFプロトコルは、UBFと非常に密接な関連があることを思い出してください。唯一の大きな違いは、「レイヤー5」のセッション・プロトコル層です。ここでは、UBF(A)を使用する代わりにEBF (Erlang Binary Format) プロトコルを使用しています。詳細は「HibariサーバーにおけるUBFプロトコル層の実装」 を参照してください。

さらに、Tomas Abrahamssonらが開発した「py_interface」パッケージが必要です。「py_interface」は、GNU Library General Public Licenseの下で配布されています。Gitのリポジトリは、repo.or.czにあります。それをコピーしてビルドするには、以下を使用します。

git clone git://repo.or.cz/py_interface.git
cd py_interface
autoconf
./configure
make
pwd

最後のコマンドのアウトプットpwd を使用して、「py-interface」ライブラリへの完全なディレクトリ・パスを記憶します。下記の例は、パスが/tmp/py-interface であると想定しています。

pyebf.py ファイルには、HibariのUBFコントラクトのdo_req() コマンドを数回呼び出す小さな単体テストが入っています。ほとんどすべてのコマンドの実行結果は、 assert 関数で確認します。

env PYTHONPATH=/path/to/py_interface python pyebf.py

HibariのThrift APIは、hibari.thrift 中にHibariサービスとして規定されています。このAPIの開発時に利用できたのはThrift 0.4.0だけでした。私たちが初めて採用したのはこのバージョンです。まだサポートしていない関数やオプションもあります。

IMPORTANT:HibariのThrift APIがサポートするのは、Thrift 0.4.0以上のみです。

service Hibari {

  /**
   * Check connection availability / keepalive
   */
  oneway void keepalive()

  /**
   * Hibari Server Info
   */
  string info()

  /**
   * Hibari Description
   */
  string description()

  /**
   * Hibari Contract
   */
  string contract()

  /**
   * Add
   */
  HibariResponse Add(1: Add request)
      throws (1:HibariException ouch)

  /**
   * Replace
   */
  HibariResponse Replace(1: Replace request)
      throws (1:HibariException ouch)

  /**
   * Set
   */
  HibariResponse Set(1: Set request)
      throws (1:HibariException ouch)

  /**
   * Delete
   */
  HibariResponse Delete(1: Delete request)
      throws (1:HibariException ouch)

  /**
   * Get
   */
  HibariResponse Get(1: Get request)
      throws (1:HibariException ouch)
}

各基本ユーティリティ関数には、インプット用の引数が1つだけあります。この引数は機能に対応する名前を持つオブジェクトです。このオブジェクトが、Hibariに対して必須の引数も任意の引数もすべて引き渡します。将来は、このオブジェクトを利用してマイクロ・トランザクションを実装する予定です。

UBFとThriftの型変換の詳細に関しては、UBF-Thriftを参照してください。

UBFの型をThriftの基本型にマッピングすることと、UBFのコントラクトをThriftのサービスにマッピングすることは、異なります。Thriftは主に2つの異なる型（structとfield）を用いて要求を組み立てます。

Thriftを使ってクライアント・コードを作成するとき、要求をどのように組み立てたらいいのか、心配する必要はありません。Thriftをインストールしてクライアント・コードを作成する方法については、Thrift Wikiを参照してください。また、着手にあたってはhibari.thriftも必要です。

UBFのコントラクトに関心がある場合は、ntbf_gdss_plugin.con のファイル内にHibariのNTBFのコントラクトがあります。

コードさえ作成できれば、Hibariに接続するのは簡単です。下記の例では、3つの言語で、テーブルtab1 に、キー 'fookey' とバリュー 'Hello, world!' を追加しています。

Erlangの例：

  -include("hibari_thrift.hrl").

  % init
  {ok, Client} = thrift_client:start_link("127.0.0.1", 7600, hibari_thrift),

  % create the input parameter object
  Request = #add{table=<<"tab1">>, key=<<"fookey">>, value=<<"Hello, world!">},

  % send request
  try
    HibariResponse = thrift_client:call(Client, 'Add', [Request]),
  catch
    HibariException ->
      HibariException
  end,

  ok = thrift_client:close(Client).

Javaの例：

  import com.hibari.rpc.*;

  // init
  TTransport transport = new TSocket("127.0.0.1", 7600);
  TProtocol proto = new TBinaryProtocol(transport);
  Hibari.Client client = new Hibari.Client(proto);
  transport.open();

  // create the input parameter object
  Add request = new Add("tab1", ByteBuffer.wrap("fookey".getBytes()),
    ByteBuffer.wrap("Hello, world!".getBytes())))

  // send request
  try {
    HibariResponse response = client.Add(request);
  } catch (HibariException e) {
    // ...
  }

  transport.close();

Pythonの例：

  from hibari import Hibari

  # init
  transport = TSocket.TSocket('localhost', 7600)
  transport.setTimeout(None)
  transport = TTransport.TBufferedTransport(transport)
  protocol = TBinaryProtocol.TBinaryProtocol(transport)
  client = Hibari.Client(protocol)
  transport.open()

  # create the input parameter object
  request = Add()
  request.table = "tab1"
  request.key = b"fookey"
  request.value = b"Hello, world!"

  # send request
  response = client.Add(request)

  transport.close()

TBFは、HibariのThrift APIのすべての関数に対して、2つの汎用型（HibariResponseとHibariException）のうち1つを返します。正常終了の場合はHibariResponseが返ることが期待できますが、そうでない場合は、HibariExceptionが返ることになっています。

（追加予定）

（追加予定）

事前準備として、ツールとソフトウェアのチェックリストをよく読み、必要に応じてインストールとセットアップを行ってください。

以下の手順に従って、GitHubからHibariリポジトリをダウンロードします。

<working-directory>
  |- hibari/
    |- .git/
    |- .gitignore
    |- Makefile
    |- dialyze-ignore-warnings.txt
    |- dialyze-nospec-ignore-warnings.txt
    |- lib/                             
      |- <application_name>/
        |- .git/
        |- .gitignore
        |- ebin/
        |- include/
          |- *.hrl
        |- priv/
        |- rebar.config
        |- src/
          |- <application_name>.app.src
          |- *.erl
        |- test/
          |- eunit/
            |- *.erl
          |- eqc/
            |- *.erl
      :
    |- rebar
    |- rebar.config
    |- rel/                             
      |- files/
        |- app.config
        |- erl
        |- hibari
        |- hibari-admin
        |- nodetool
        |- nodetool-admin
        |- vm.args
      |- hibari/
        :
        |- releases/
          |- <release_vsn>/
            :
          :
        :
      |- reltool.config
  |- hibari-doc/                        
    :
  |- manifests/                         
    :
  |- patches/                           
    :
  |- rebar/                             
    :
  |- .repo/
    :

<1> アプリケーション <2> リリース <3> ドキュメント <4> マニフェスト <5> パッチ <6> Rebar

以下の手順に従って、Hibariのリリースパッケージをビルドします。

以下の手順に従って、Hibariのドキュメントをビルドします。

Hibariのドキュメントは、AsciiDocと、次の補助ツールを使って作成されます。

Hibariのドキュメントは、AsciiDocと、手で修正したa2xツールを使って生成できます。 lang-ja.confファイルは、lang-en.confファイルへのシンボリックリンクとして作成しました。

$ diff -r -u 8.6.4-orig/bin/a2x.py 8.6.4/bin/a2x.py
--- 8.6.4-orig/bin/a2x.py      2011-04-24 00:50:26.000000000 +0900
+++ 8.6.4/bin/a2x.py   2011-04-24 00:35:55.000000000 +0900
@@ -156,7 +156,10 @@
 def shell_copy(src, dst):
     verbose('copying "%s" to "%s"' % (src,dst))
     if not OPTIONS.dry_run:
-        shutil.copy(src, dst)
+        try:
+            shutil.copy(src, dst)
+        except shutil.Error:
+            return

 def shell_rm(path):
     if not os.path.exists(path):
Only in 8.6.4/etc/asciidoc: lang-ja.conf

以下の手順に従ってソースコードをダウンロードし、Erlang/OTPをビルドします。続いてシステムをインストールします。以下の手順が基本的なやり方ですが、すべてのオプションに対応しているわけではありません。

	Erlang/OTP の設定とビルドを行う前に、システムに openssl-devel パッケージがインストールされていることを確認してください。

	"otp-installing-directory-name/bin" が$PATH環境変数に追加されたことを確認してください。 　　 == サンプル・アプリケーション （作成中）

（追加予定）

Hibariのすべての"プロジェクト" に関する作業ディレクトリをリストします。

$ repo forall -c "pwd"

	プロジェクトにはそれぞれ、対応するGitリポジトリとデフォルトの改訂版があります。詳細は "manifests/hibari-default.xml" ファイルを確認してください。

新しいトピック（例：new-topic-name）のブランチを作成します。

$ repo start new-topic-name `repo forall -c "pwd" | xargs echo`

既存のトピック（例：topic-name）のブランチを中断します。

$ repo abandon topic-name `repo forall -c "pwd" | xargs echo`

マスター・ブランチを構成管理下に置き、チェックアウトします。

$ repo forall -c "git branch --track master github/master"
$ repo forall -c "git checkout master"

dev（開発）ブランチを構成管理下に置き、チェックアウトします。

$ repo forall -c "git branch --track dev github/dev"
$ repo forall -c "git checkout dev"

（追加予定）

（追加予定）

（追加予定）