devkuma – NoSQL

MongoDB シャーディングの概要

kc@example.com (kc kim) — Wed, 19 Jan 2022 09:19:00 +0900

スケーリング(scaling)

シャーディングについて話す前に、まずスケーリングについて見てみよう。

一般的なスケーリングで言えば、システム規模が大きくなるとスケーリング、つまり拡張が必要になる。スケーリング方法は大きく「垂直スケーリング」と「水平スケーリング」の2種類に分けられる。

垂直スケーリング

垂直スケーリングは、CPU、RAM、ストレージをより高性能なものへ交換していく方法である。スケーリングは簡単だが、そもそも CPU やメモリには限界があるため、ある程度の性能限界がある。

水平スケーリング

データセットごとにシステムを分割し、複数のサーバーから並列で処理する方法である。総合的な性能は垂直スケーリングより高くできるが、スケーリングするほど複雑性が増すため管理が難しくなる。

シャーディング(sharding)とは?

シャーディングとは、データを複数サーバーに分散させる「水平スケーリング」の仕組みである。

シャーディングには大きく3つの利点がある。「読み書き処理が速くなり、性能を上げやすい」、「ストレージを増設しやすい」、「可用性が高い」である。それぞれの詳細を以下で見ていく。MongoDB は標準機能としてシャーディング、つまり水平スケーリングをサポートする。

読み書き

データをシャードクラスターに分散して保存すると、読み書き処理、つまりファイル I/O を分散処理できる。ファイルの読み書きは遅い処理であるため、これを分散することでより高速な読み書きが可能になる。また、読み書きの負荷が増えても、サーバーを増やすことで水平スケーリングできる。

ストレージ

シャードクラスターには、分割されたデータが分散して保存される。データ量が増える場合でも、サーバーを増やして水平スケーリングできる。

高可用性

シャードクラスターでは部分的な読み書きが可能である。読み書きできない場合でも、作業を実行できるシャードサーバーから取得できることがある。

シャードクラスター

MongoDB のシャーディングは、シャード、ルーター、構成サーバーという3つの構成要素から成る。それぞれの関係と説明は次のとおりである。

シャード

シャードサーバーには、コレクションを分割した断片データ、つまりチャンクを保存する。シャードサーバーはレプリカセットとして構成できる。

ルーター

mongos はクエリルーターであり、アプリケーションからシャードクラスターへのインターフェースを提供する。シャードクラスターにアクセスするときは常に mongos 経由でアクセスする。シャード化されていないコレクションであっても、必ず mongos 経由でアクセスする。

構成サーバー

シャードクラスター設定に関するメタデータを保存する。どのシャードサーバーにデータがあるかといった情報もこのサーバーに保存される。MongoDB 3.4 以降では、構成サーバーをレプリカセットとして構成する。

シャードキー

「シャードキー」とは、データを分散してシャードサーバーに保存するときにキーとして利用する情報を指す。MongoDB は「シャードキー」を使って、コレクション内のドキュメント分散を行う。

次の図は、x シャードキーで分散された簡単な例である。

… 図 …

「シャードキー」に関するポイントは次の3つである。

すべてのドキュメントに存在する不変のフィールド、またはフィールド群で構成する。
一度シャードキーを決定して分散を実行すると、シャードキーを再度変更することはできない。
シャーディングするコレクションには、シャードキーを含むインデックスが必要である。

もちろん、シャードキーの選択が性能、効率、拡張性に大きな影響を与えることは言うまでもない。シャードキーの選択が不適切であれば、上で説明したようにシャードサーバーに偏りが発生し、非効率な動作が発生する可能性がある。

チャンク

前述のように、MongoDB は「シャードキー」の値でデータ保存を分散するが、このとき「チャンク」という塊ごとにグループ化してシャードサーバーへ分散保存する。MongoDB は自動的に「チャンク」がシャードクラスター内で均等に分散されるよう移動する。

チャンクに分割し、それを各シャードへ分散保存するイメージは以下のとおりである。

… 図 …

シャードデータに対する操作制約

シャーディングされたデータ、つまりシャードデータに対する操作にはいくつかの制限がある。

group コマンドは使用できない。
代わりに aggregate なしで MapReduce を利用する。
updateOne または deleteOne では _id を指定する必要がある。
シャードキー _id が含まれていない場合はエラーが発生する。
シャーディングしたコレクションにはユニークインデックスが必要である。

シャードコレクションと非シャードコレクション

MongoDB では、シャード化するコレクションとシャード化しないコレクションを混在させることができる。シャード化するコレクションはシャードクラスターに分散保存されるが、シャード化されていないコレクションはプライマリシャードに保存される。

データ分散方法

シャード化するときの分散方法には、「ハッシュシャード」と「レンジシャード」の2つがある。

ハッシュシャード

シャードキーのハッシュ値を利用してデータ分散を行う。ハッシュを利用したシャードの場合、シャードキーの値が近くてもチャンクが散らばりやすい特徴がある。つまり、シャードキーが単調変化する場合に分散しやすい分散方法である。逆にデータが分散されやすいため、データ構造や取得方法によってはブロードキャスト操作が増える可能性もある。

レンジシャード

シャードキーの範囲に従ってデータ分散を行う。ハッシュシャードと異なり、シャードキーの値が近い場合、同じチャンク上に存在する可能性が高くなる分散方法である。シャードキーの選定が不適切であれば、せっかくシャードという分散技術を利用しようとしても、特定サーバーに負荷が偏ってしまう可能性がある。

MongoDB mongod コマンドの使い方

kc@example.com (kc kim) — Thu, 13 Jan 2022 07:57:00 +0900

mongod コマンドの基本的な主な使い方、つまりオプションを整理する。

ここで扱っているのは重要と思われるオプションだけであるため、その他の多くのオプションについては公式マニュアルを参照すること。

基本オプション

オプション	説明
`--config <filename>`, `-f <filename>`	起動オプションを含む構成ファイルを指定する。構成ファイルのパスに空白が含まれる場合は、ダブルクォート(`"`)で囲む。構成ファイルは ASCII エンコーディングを使用する。UTF-8 など ASCII 以外はサポートしない。構成ファイルと起動オプションを同時に指定した場合は、起動オプションの値が優先される。
`--port <port>`	デフォルト: 27017 MongoDB が TCP 接続を待ち受けるポート番号を指定する。
`--maxConns <number>`	MongoDB が許可する同時接続数を指定する。
`--logpath <path>`	ログファイルを出力するパスを指定する。
`--logappend`	MongoDB を再起動すると、既存ログファイルの続きとしてロギングされる。 MongoDB のデフォルトでは、再起動時に既存ログファイルをバックアップして新しいログファイルを作成する。
`--slowms <integer>`	デフォルト: 100 プロファイリングするしきい値をミリ秒で指定する。
`--profile <level>`	デフォルト: 0 データベースプロファイリングレベルを変更する。 - 0: Off。プロファイリングを行わない。 - 1: On。遅い操作のみプロファイリングを行う。 - 2: On。すべての操作をプロファイリングする。
`--auth`	データベースアクセス制御を使用する。ユーザーの設定変更は `mongo` コマンドで行う。ユーザーが存在しない場合は、`localhost` からのアクセスのみ許可される。
`--bind_ip <address>`	デフォルト: すべての接続 MongoDB が接続を受け付ける IP アドレスを指定する。
`--dbpath <path>`	デフォルト: `C:\data\db` データベースファイルを保存するストレージパスを指定する。

Windows サービスインストールオプション

オプション	説明
`--install`	MongoDB を Windows サービスに追加する。必要に応じて `--serviceName`、`--serviceDisplayName` を同時に指定する。
`--remove`	Windows サービスから MongoDB サービスを削除する。 `--serviceName` でデフォルト以外の名前をインストールした場合は、`--serviceName` を指定する必要がある。
`--serviceName <name>`	デフォルト: MongoDB サービス名を指定する。ここで指定した名前は `net start <name>`、`net stop <name>` の引数として使用される。
`--serviceDisplayName <name>`	デフォルト: MongoDB サービス管理ツールに表示される名前を指定する。
`--serviceDescription <description>`	デフォルト: MongoDB Server サービス管理ツールの説明に表示する文字列を指定する。空白が含まれる場合はダブルクォート(`"`)で囲む。
`--serviceUser <user>`	MongoDB を実行するユーザーを指定する。
`--servicePassword <password>`	MongoDB を実行するユーザーのパスワードを指定する。

参考文書

MongoDB の特徴

kc@example.com (kc kim) — Sun, 09 Jan 2022 18:38:00 +0900

今回は MongoDB の特徴について見てみよう。

公式サイトにも記載されている内容として、特徴は大きく以下のように整理できる。

ドキュメントデータベース(NoSQL)
特殊クエリ
高性能
高可用性
水平スケーラビリティ

ドキュメントデータベース(NoSQL)

JSON のようにキー・バリュー(Key-Value)の組み合わせをそのまま保存できる、ドキュメント形式のデータベースである。バリューにはさまざまな形式を指定できる。たとえば数値や文字列はもちろん、配列やオブジェクトを保存できることも特徴である。また、このバリューの形式は動的に変更でき、同じフィールド名に複数の形式を入れることもできる。つまり、スキーマレス(schemaless)なドキュメントデータベースである。

性能

性能を出すために、次のような機能が実装されている。

埋め込みデータモデルによる I/O 処理の削減
インデックス(index)のサポート

NoSQL でありながら「インデックス」をサポートしていることが MongoDB の特徴である。「インデックス」に関連して「ユニークキー」を指定することもできる。

特殊クエリ

JSON 形式で指定する特殊クエリを活用して DB を検索する。クエリで実行できる操作は基本的な CRUD 操作はもちろん、以下のような特徴的なクエリがある。

集計(Aggregation、Map-Reduce)
「テキストインデックス」を使った文字列検索
地理空間クエリ

集計(Aggregation、Map-Reduce)では、保存されたデータに対してさまざまな統計処理を実行できる。クエリ単体の組み立ては独特な実装なので慣れが必要だが、処理順序がパイプライン化されているため、コードの見通しはよい。

「地理空間クエリ」は、組み込みの「GeoJSON」形式を利用して「範囲内のポイント検索」を行うことができる。

可用性

MongoDB はレプリカセットという機能でレプリケーション機能を提供する。このレプリカセットは自動フェイルオーバーとデータ冗長性を提供する。

水平スケーリング

水平スケーリングという特徴は、「マシンを増やすことで性能を向上できる」ということである。MongoDB では、コア機能であるシャーディングという仕組みによって水平スケーラビリティを実現している。

複数ストレージエンジンのサポート

MongoDB は複数のストレージエンジンをサポートする。一般的に使用されるファイルシステムのほか、インメモリエンジンを選択できる。また、ストレージエンジン API を公開しているため、サードパーティ製ストレージエンジンを作成することもできる。

参考文書

NoSQL とは?

kc@example.com (kc kim) — Fri, 04 Jun 2021 08:26:25 +0900

NoSQL とは?

NoSQL とは “Not only SQL” と解釈される非リレーショナルデータベース全般を指す。非リレーショナルデータベース全般とは、一般的にはリレーショナルデータベースを除くすべてのデータベースを指す。

non SQL、non relational データベースは、従来のリレーショナルデータベースより制約の少ない一貫性モデルを利用する、データ保存と検索のためのメカニズムを提供する。

保存方式による分類

非リレーショナルデータベースのデータモデルの例は、保存方式によってドキュメント(Document)、キー・バリュー(Key-Value)、グラフ(Graph)などに分類される。

ドキュメント(Document) DB
- JSON、XML のような Collection データモデル構造を採用している。
- Lotus Notes に由来する。
- MongoDB、BaseX、CouchDB がこれに該当する。
キー・バリュー(Key-Value) DB
- Key と Value がペアで保存される、もっとも単純な形態のソリューションである。
- Amazon Dynamo Paper に由来する。
- Redis、Memcached がこれに該当する。
グラフ(Graph) DB
- Euler & Graph Theory に由来する。
- Nodes、Relationship、Key-Value データモデルを採用している。
- Neo4J、OrientDB などがこれに該当する。
Wide Columnar Store
- Big Table DB ともいう。
- Google の BigTable Paper に由来する。
- Key-Value から発展した Column Family データモデルを使用している。
- HBase、Cassandra、ScyllaDB などがこれに該当する。

RDB と NoSQL の違い

RDB、つまりリレーショナルデータベースと、NoSQL、つまり非リレーショナルデータベースの特徴を表に整理すると次のようになる。

RDB と NoSQL の違いは、データ構造はもちろん、データ整合性の意味やスケーリングにもある。

区分	RDB	NoSQL
データ構造	データ構造をテーブル形式で表現する。データ構造の表現には「テーブル」および「テーブル間の接続」を利用する。 RDB	テーブル形式以外の方法でデータ構造を表現する。表現方法にはドキュメント(XML、JSON)、キー・バリュー、グラフなどがある。ドキュメント(Document) キー・バリューグラフ
ACID 特性	データ不一致が発生しないよう、厳格な管理が行われる。	結果整合性と呼ばれる、厳格なデータ整合性管理は行われない。速度を優先し、データについては「結果的に」一貫性を持つよう保証する。
スケーリング	垂直方向のスケーリング、つまりサーバースペックの増強が行いやすい。	水平方向のスケーリング、つまりサーバー台数の増強がしやすいことが特徴である。

CAP 理論

一貫性(Consistency)
- 同時性または同一性ともいう。
- 複数クライアントが同じ時間に照会するデータが同一データであることを保証することを意味する。
可用性(Availability)
- すべてのクライアントの読み書き要求に対して、常に応答可能であることを保証する。
- 耐障害性ともいう。
- 耐障害性を持つ NoSQL は、クラスター内のいくつかのノードが壊れても正常なサービスが可能である。
ネットワーク分割許容性(Partition tolerance)
- 地域的に分割されたネットワーク環境で動作するシステムにおいて、2つの地域間のネットワークが切断されたりネットワークデータが失われたりしても、各地域内のシステムが正常に動作しなければならないことを意味する。

参考文書

Redis の概要

kc@example.com (kc kim) — Mon, 24 May 2021 10:12:26 +0900

概要

Redis は Remote Dictionary Server の略であり、「キー・値」構造の非定型データを保存、管理するためのオープンソースベースの非リレーショナルデータベース管理システムである。2009年に Salvatore Sanfilippo が初めて開発した。2015年から Redis Labs が支援している。さまざまなサービスで Redis が自由に使用されている。

Pareto principle(パレートの法則)

社会で起こる現象の80%は、20%の原因によって発生するという法則である。Web サイトへのアクセスにもパレートの法則がよく当てはまる。

インターネット通信の80%は、わずか20%のサイトへのアクセスと推定され、この20%の Web サイトデータをキャッシュしておけば効率を劇的に向上できる。

とされる。

(インフラエンジニアの教科書 - ネットワーク編, 2017, Gilbut)

したがって、共通で使用されるデータを Redis を利用してキャッシュとして保存しておくことは、リソースを効率的に利用する方法になり得る。

Redis の特徴

Redis は key-value store NoSQL DB である。
- 単純な string に対する key-value 構造をサポート
- バイナリデータの書き込み
Single Thread で動作する。
- シングルスレッドで動作するため、演算の原子性を保証する。
多様なデータ構造をサポートする。
- collection サポート: List、Set、Sorted Set、Hash などのデータ構造をサポート
高速
- 秒間 100,000 QPS レベルの性能を誇る。
Disk 保存
- Disk に永続的に保存できる。
レプリケーション(replication)
- 他のノードへ内容を複製できる master/slave 構造をサポートする。
Sharding サポート
- Redis Cluster を通じてデータ sharding をサポートする。
Publish/Subscribe サポート
- メッセージブローカーとして使用可能
Expire(有効期限)
- key に expire を設定し、古くなったデータを自動削除できる。
データのスナップショットまたは AOF ログによって復旧できるため、ある程度の永続性も保証される。
Java Spring では、セッション管理やキャッシュによく使用される。

なぜ Collection が重要なのか?

Redis は In-Memory データベース である。つまり、すべてのデータをメモリに保存して照会する。既存のリレーショナルデータベース(Oracle、MySQL)よりはるかに高速だが、その理由はメモリアクセスがディスクアクセスより速いためである。ただし、速いという点は Redis のいくつかの特徴の一部に過ぎない。他の In-Memory データベース、たとえば Memcached との最大の違いは、多様なデータ構造 をサポートする点である。Redis は以下のように、さまざまなデータ構造を Key-Value 形式で保存する。

Redis は基本的に String、Bitmap、Hash、List、Set、Sorted Set を提供しており、バージョンが上がるにつれて現在は Geospatial Index、HyperLogLog、Stream などのデータ型もサポートしている。

では、このように多様なデータ構造を提供することがなぜ重要なのだろうか。それは 開発の利便性と難易度 のためである。

たとえば、リアルタイムランキングサーバーを実装するときにリレーショナル DBMS を利用するなら、DB にデータを保存し、保存された SCORE 値でソートして再度読み出す過程が必要になる。件数が増えると速度が遅くなりがちだが、この過程でディスクを使用するためである。In-memory ベースでサーバー側のデータ処理を直接実装することもできるが、Redis の Sorted-Set を利用する方がより速く簡単な方法である。

Redis Persistence

Redis はディスクにデータを保存する方法として、RDB(Snapshot) と AOF(Append Only File) 方式を使用する。
どちらの方式も内部的に fork() 関数を使用するため、十分なメモリが必要である。

RDB(Snapshot)
- メモリ上のデータをディスクへ移す方式である。
- スナップショット方式はメモリの状態をそのまま取得するため、特定時点のバックアップと復旧に有利であり、AOF 方式に比べてより速くデータをメモリに読み込める。
- サーバーがダウンすると、バックアップされたスナップショット間に変更されたデータは失われる。
- 2つの方式がある。
  - SAVE: blocking 方式で、順次すべての Redis 動作を停止し、その時点の Snapshot を Disk に保存する。
  - BGSAVE: non-blocking 方式で、別プロセスを通じて実行時点のメモリ snapshot をディスクに保存する。
AOF(Append Only File)
- Redis のすべての write/update 演算を log ファイル形式で記録する方法である。
- サーバーが起動すると、順次演算を再実行してデータを復旧する。
- 演算処理が実行されるたびに記録するため、現在時点までのログを残すことができる。
- ログファイルに対して append のみを実行するため write 速度が速く、サーバーがダウンしてもデータ損失が発生しない。
- すべての演算についてログを残すため、データ量が非常に大きい。
- サーバー再起動時、すべての演算を再実行するため restart 速度が遅い。

Redis をクラウドで使用

アプリケーション開発に Amazon Web Services や Microsoft Azure を使用する場合、各クラウドサービスは Redis サービスを提供しているため、それを活用できる。

クラウドサービス	サービス名
Amazon Web Services	Amazon ElastiCache for Redis
Microsoft Azure	Azure Redis Cache

もちろん各クラウドサービスのコンピュータインスタンスに直接 Redis をインストールすることもできるが、管理コストを考えるとこれらのサービスを選択するのがよい。

参照

Redis | Wikipedia
[redisgate][http://redisgate.kr/]

データ指向アプリケーションデザイン

kc@example.com (kc kim) — Wed, 03 Aug 2022 15:06:00 +0900

信頼性、スケーラビリティ、保守性に優れたシステムを支える中核的な考え方

https://wikibook.co.kr/data-intensive-applications/

グループスタディメンバー: キム・ギョンチョル、キム・ミンギュ、キム・ジョンス、キム・ウンテク、パク・スミン、パク・ヒョンド、イ・スンイク、イ・ホジュン、チョ・ソンジク、ファン・ユンホ

本資料は、グループスタディで発表した資料です。

Redis を Docker でインストール

kc@example.com (kc kim) — Fri, 31 Mar 2023 17:46:26 +0900

Redis Docker インストール

学習や検証のために簡単に使うのであれば、Docker を使って Redis をインストールする方法を推奨する。

Redis Docker イメージのダウンロード

次のコマンドを実行して Redis Docker をダウンロードする。ここでは alpine バージョンを取得した。

別のバージョンタグが必要な場合は、https://hub.docker.com/_/redis/tags を参照するとよい。

% docker pull redis:alpine

ダウンロード後にイメージを確認すると、以下のように一覧を確認できる。

% docker images
REPOSITORY         TAG       IMAGE ID       CREATED        SIZE
redis              alpine    a4cf5af74f5e   2 days ago     30.4MB

Redis Docker コンテナの作成と実行

次のコマンドを実行する。

% docker run -d -p 6379:6379 --name=redis redis:alpine

-p: host に公開するポートを指定
--name: コンテナ名を指定

実行後、実行中のコンテナを確認する。

% docker container ls
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                    NAMES
1df277cb625c   redis:alpine   "docker-entrypoint.s…"   30 seconds ago   Up 29 seconds   0.0.0.0:6379->6379/tcp   redis

Redis Docker への接続

Redis Docker コンテナ内部への接続

Redis に接続する前に、Redis がインストールされた Docker コンテナの内部へ接続する。

% docker exec -it redis /bin/bash

もし以下のようなエラーメッセージが出る場合は、/bin/sh で接続してみる。

OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown

% docker exec -it redis /bin/sh

Redis へ接続

コンテナ内部へ接続できたら、Redis に接続してみる。redis-cli コマンドで Redis に接続する。

/data # redis-cli
127.0.0.1:6379>

接続できると、上記のように IP:port> プロンプトへ変更される。

Redis の情報を確認するには、以下のように info を入力すればよい。

127.0.0.1:6379> info
# Server
redis_version:7.0.10

... 以下省略 ...

抜けるには Ctrl+C を押せばよい。

MongoDB Docker インストール

kc@example.com (kc kim) — Mon, 10 Jan 2022 08:53:00 +0900

MongoDB Docker インストール

MongoDB Docker イメージのダウンロード

以下のコマンドを実行して MongoDB Docker イメージをダウンロードする。タグにバージョンを指定しない場合は、最新バージョンがダウンロードされる。

docker pull mongo

実行結果は以下のとおりである。

% docker pull mongo
Using default tag: latest
latest: Pulling from library/mongo
ea362f368469: Pull complete
ecab26900ceb: Pull complete
1847fcb70562: Pull complete
a7de23811c0d: Pull complete
29dd51833fb9: Pull complete
5eccd2be8afb: Pull complete
cd8a8cd6879f: Pull complete
e6ca3abc397d: Pull complete
7481c3682d3c: Pull complete
af377cb9eb7d: Pull complete
Digest: sha256:6743836d42756b2ae50549b2eb4585c688fce81a243cedd152b56266c2fb3d17
Status: Downloaded newer image for mongo:latest
docker.io/library/mongo:latest

MongoDB のバージョンを指定するには、タグにバージョンを指定する必要がある。ダウンロード可能な MongoDB バージョンは Docker Hub で確認できる。

次のコマンドで、ダウンロードした Docker イメージを確認する。

docker images

実行結果は以下のとおりである。

% docker images
REPOSITORY                                      TAG            IMAGE ID       CREATED         SIZE
mongo                                           latest         ee13a1eacac9   2 days ago      696MB

MongoDB Docker コンテナの作成と実行

docker run --name my-mongodb -v ~/mongodb/db:/data/db -d -p 27017:27017 mongo

-v ~/mongodb/db:/data/db は、ホスト、つまりコンテナを起動するローカルコンピュータの ~/mongodb/db ディレクトリと、コンテナの /data/db ディレクトリをマウントする。このようにボリュームを設定しないと、コンテナを削除したときに保存されたデータも削除されるためである。一度削除されたコンテナデータは復元できない。

% docker run --name my-mongodb -v ~/mongodb/db:/data/db -d -p 27017:27017 mongo
ade97bdb08fde4eaa72ceb0135b0a570d97b21616affb7949a0fc479fec25e0e

MongoDB Docker コンテナの開始、停止、再起動

MongoDB Docker コンテナを停止する。

docker stop my-mongodb

MongoDB Docker コンテナを開始する。

docker start my-mongodb

MongoDB Docker コンテナを再起動する。

docker restart my-mongodb

MongoDB Docker コンテナの実行確認

次のコマンドを実行する。

% docker ps -a
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS                      PORTS                                       NAMES
ade97bdb08fd   mongo                                                  "docker-entrypoint.s..."   37 seconds ago   Up 36 seconds               0.0.0.0:27017->27017/tcp                    my-mongodb

MongoDB Docker コンテナへの接続

次のコマンドを実行する。

docker exec -it my-mongodb bash

実行結果は以下のとおりである。

% docker exec -it my-mongodb bash
root@ade97bdb08fd:/#

Redis redis-cli

kc@example.com (kc kim) — Fri, 10 Mar 2023 14:39:26 +0900

redis-cli インストール

macOS 環境に Homebrew でインストールする方法は以下のとおりである。

brew tap aoki/redis-cli
brew update && brew doctor
brew install redis-cli

github.com/aoki/homebrew-redis-cli

サーバー制御

redis-cli 接続

ホスト名とポート番号を省略すると、localhost の 6379 に接続される。

$ redis-cli

リモート接続は以下のように行う。

$ redis-cli -h #{ホスト名} -p #{ポート番号}

その他の主なオプションは以下のとおりである。

-n: database 番号
-a: パスワード
-s: ソケット
-u: サーバー URL など、接続時にさまざまなオプション設定が使用可能

サーバー情報の照会

redis-cli info

> info
# Server
redis_version:6.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:ffd199d8341c2d8f
redis_mode:standalone
... 以下省略 ....

接続中クライアント一覧の照会

> client list

接続中クライアントの切断

> client kill 10.0.0.8:33333

コマンド実行後に受信したリクエストをすべてダンプ

redis-cli monitor

> monitor
OK

Key 操作

key、value の設定

set {key名} {value}

> set key01 value01
OK

key で value を照会

get {key名}

> get key01
value01

key 一覧の照会

> keys *
key01

key の削除

> del key01
1

key が存在するか確認。1なら true

exists {key名} {value}

> exists key01
0

key がまだ存在しない場合にデータをセット

setnx {key名} {value}

> setnx key01 value02
1
> setnx key01 value02
0

結果が 0 であれば、key が存在するためデータが更新されなかったことを意味する。

既存 key 名の変更

rename {以前の key名} {新しい key名}

> rename key01 key02 
OK
> rename key03 key04
ERR no such key

現在のデータベースの key 数を返す

> dbsize
2

特定 key を別のデータベースへ移動

> move key01 1
1

DB 番号の選択

> select 1
OK

現在のデータベースの key をすべて削除

> flushdb
OK

すべてのデータベースの key をすべて削除

> flushall
OK

正規表現

Redis で使用できる正規表現は次のみである。

[]: 括弧内の文字のいずれか1つ
*: 任意の文字列
?: 単一文字

使用例

# すべての Key 一覧を照会する。
$ keys *

# 数字で始まる key を照会する。
$ keys [0-9]*

Multiple Key

複数の key 値をまとめて設定

> mset key01 value01 key02 value02 key03 value03 
OK

複数の key 値を一度に照会

> mget key01 key02 key03
value01
value02
value03

expire

有効期限を設定して key を設定

以下の例では 60 秒に設定している。

> setex key01 60 value01 
OK

既存 key の有効期限設定

> expire key02 30

Math

key 値に 1 を加える

以下の例では key02 に 1 を設定し、1 を増加させる。

> set key02 1 
OK
> incr key02 
2

key 値に指定した数を加える

> incrby key02 100 
102

key 値から 1 を引く

> decr key02 
101

key 値から指定した数を引く

> decrby key02 51 
50

List

List の先頭に値を追加

空白で区切って複数の値を指定できる。

> lpush list01 value01
1

List の末尾に値を追加

空白で区切って複数の値を指定できる。

> rpush list01 value02
2

List 要素の数を返す

> llen list01
2

List で指定番号の要素を返す

> lindex list01 0
value01

List で指定した開始番号から終了番号までの要素を返す

> lrange list01 0 1
value01
value02

List の指定番号の要素を指定値へ変更

> lset list01 1 value03
OK
> lindex list01 1
value03

List の最初の要素を返して削除

> lpop list01
value01

List の最後の要素を返して削除

> rpop list01
value03

List で指定した開始番号から終了番号までの要素だけを残す形でリストを変更

> ltrim list01 1 3
OK

Hash

親 Key、子 Key(field)、値(value)によって管理されるデータ形式である。たとえば、親 Key を製品 ID、子 Key を製品属性情報の保存に使うと、RDB のデータ管理に近い考え方で使用できる。

Hash の指定フィールドに値を追加

> hset hash01 field01 value01
(integer) 1

Hash の指定フィールドの値を返す

> hget hash01 field01
"value01"

Hash の複数フィールドに追加

> hmset hash01 field02 value02 field03 value03
OK

Hash の複数フィールドの値を返す

> hmget hash01 field01 field02 field03
value01
value02
value03

Hash フィールドをすべて返す

> hkeys hash01
field01
field02
field03

Hash フィールドの値をすべて返す

> hvals hash01
value01
value02
value03

Hash の指定フィールドの値に指定数を加算

> hincrby hash01 field04 100
101

Hash の指定フィールドが存在するか確認

> hexists hash01 field01
1

Hash フィールド数を返す

> hlen hash01
4

Hash の指定フィールドを削除

> hdel hash01 field04
1

その他の操作

keys を使用できないときに key を検索する方法

scan 0 match devkuma-* count 1000

key 名は wildcard 検索でき、devkuma-* は devkuma- で始まる key を検索する。

Redis データ構造(Structure)の照会と保存

kc@example.com (kc kim) — Fri, 31 Mar 2023 17:46:26 +0900

データ構造(Collection)

Redis はさまざまなデータ構造(Structure)を提供する。

Redis でのデータ表現の基本型は、1つの Key と1つ以上の Field/Element 値で構成される。

Key
- ASCII value を保存する。
Value (Field/Element)
- 基本的に String データを保存する。
- Container タイプのデータを保存する。
Container タイプ
- Hash、List、Set、Sorted Set などを含む。

Strings

String は Redis value のもっとも基本的なデータ型である。value に文字や数字などを保存する。保存時に数字と文字を別途区別しない。
Redis String は binary safe である。これは Redis string が JPEG image や serialized Ruby object のようなあらゆる種類の data を含められることを意味する。

String value は最大 512 MB の長さを持つことができる。

Strings Redis コマンド

キー・値構造でデータを保存し、照会してみる。

コマンド	文法	説明
`set`	`set key`	key-value を保存する。
`get`	`get key`	key に該当する value を照会する。
`del`	`del key`	key を削除する。

127.0.0.1:6379> set devkuma 1000
OK
127.0.0.1:6379> get devkuma
"1000"
127.0.0.1:6379> del devkuma
(integer) 1
127.0.0.1:6379> get devkuma
(nil)
127.0.0.1:6379>

Lists

List は単純に挿入順で整列された String list である。String 型が配列構造になったものと考えればよい。
新しい要素を list の前または後ろに追加できる。最大約40億要素まで保持できるとされる。

コマンド	文法	説明
`lpush`	`LPUSH key element [element ...]`	left push であり、左から、index は 0 からデータを保存する。
`lpop`	`LPOP key`	left pop であり、list の index 0 からデータを抽出する。
`rpush`	`RPUSH key element [element ...]`	right push であり、右から、つまり index last からデータを保存する。
`rpop`	`RPOP key`	right pop であり、list の index last からデータを抽出する。
`lrange`	`LRANGE key start stop`	list のデータを start から end まで抽出する。 lrange で end を -1 と宣言すると、その list のデータをすべて抽出する。

LPUSH コマンドは新しい要素を head の前に追加し、RPUSH は後ろに追加する。empty key に実行される場合は new list が作成されて追加される。

127.0.0.1:6379> lpush fruit apple
(integer) 1
127.0.0.1:6379> lpush fruit banana
(integer) 2
127.0.0.1:6379> lpush fruit orange
(integer) 3
127.0.0.1:6379> lrange fruit 0 2
1) "orange"
2) "banana"
3) "apple"
127.0.0.1:6379>

Sets

Set は整列されていない String collection である。List 型からインデックスがなくなった型である。Value に重複がない。Lists より高速に処理できる。

ランダムにデータを抽出できるという意味では、機械学習などに使用できるかもしれない。

コマンド	文法	説明
`sadd`	`SADD key member [member...]`	set の key に member を追加する。
`srem`	`SREM key member [member...]`	set の key から member を削除する。
`smembers`	`SMEMBERS key`	set の key のすべての member を照会する。

sadd コマンドで key animal に要素を追加してみる。

127.0.0.1:6379> sadd animal dog
(integer) 1
127.0.0.1:6379> smembers animal
1) "dog"
127.0.0.1:6379> sadd animal cat cow
(integer) 2
127.0.0.1:6379> smembers animal
1) "dog"
2) "cat"
3) "cow"

srem コマンドで key animal から要素を削除してみる。

127.0.0.1:6379> srem animal cat
(integer) 1
127.0.0.1:6379> smembers animal
1) "dog"
2) "cow"
127.0.0.1:6379>

全体を削除するには del コマンドを使用する。

127.0.0.1:6379> del animal
(integer) 1
127.0.0.1:6379> smembers animal
(empty array)
127.0.0.1:6379>

Sorted Sets

Sorted set は Redis set と似た、重複しない String の集合である。 Set 型に score という概念が付いたものである。ここでも Value に重複はない。score 順に整列したり、score に対してしきい値処理をしたりできる。ゲームのリアルタイムランキング表示などに使えそうである。

Hashes

Hashes の場合、key 1つに複数の field と value のペアで構成される。Set に文字列で指定できる field という概念が付いたものである。

すべての hash は最大 2^32 - 1 個の field-value ペア、つまり約40億個以上を保存できる。

コマンド	文法	説明
`hset`	`HSET key field [field value...]`	1つまたは複数の値を設定する。
`hget`	`HGET key field`	1つまたは複数の値を取得する。

Bitmaps and HyperLogLogs

Redis はまた、実際には String base type を基盤としながら独自の意味を持つ data type である Bitmap および HyperLogLogs もサポートする。

参考

Redis data types | Redis

MongoDB mongo コマンドの使い方

kc@example.com (kc kim) — Tue, 11 Jan 2022 18:21:00 +0900

MongoDB に接続するクライアントモジュールである mongo を使用して接続する方法について見てみよう。

基本オプション

オプション	説明
`--host <hostname>`	接続する MongoDB サーバーのホスト名を指定する。ホスト名を指定しない場合は localhost に接続する。
`--port <port>`	MongoDB サーバーに接続するポート番号を指定する。ポート番号を指定しない場合は `27017` に接続する。
`--username <username>, -u <username>`	認証機能が有効な MongoDB にアクセスするときのユーザー名を指定する。
`--password <password>, -p <password>`	認証機能が有効な MongoDB に接続するときのパスワードを指定する。
`--authenticationDatabase <dbname>`	認証するデータベース名を指定する。

ファイル

.dbshell

mongo シェルで実行されたコマンドの履歴が保存される。ファイルはホームディレクトリ(%UserProfile%)直下に自動的に作成される。Windows の場合、たとえば次の場所になる。

%UserProfile%

C:\Users\<ユーザー名>\.dbshell

.mongorc.js

.mongorc.js ファイルを決められたディレクトリ(%UserProfile% または %ProgramData%)の直下に置くと、mongo 起動時に自動で .mongorc.js がロードされて実行される。これを使うと、シェル実行中に共通で使いたい変数や関数をあらかじめ定義しておくことができる。.mongorc.js はユーザー定義(%UserProfile%)よりもグローバル定義(%ProgramData%)を先に読み込む。

.mongorc.js をロードしたくない場合は、--norc オプションを付けて mongo を起動するとロードされない。

Windows の場合、たとえば次のようなディレクトリになる。 %UserProfile%

C:\Users\<ユーザー名>\.mongorc.js

%ProgramData%

C:\ProgramData\MongoDB\.mongorc.js

参考記事

Redis Command SETEX key Seconds value

kc@example.com (kc kim) — Fri, 31 Mar 2023 17:46:26 +0900

SETEX

SETEX コマンドは、文字列値に key と秒数(second)を指定する。指定した秒数の後にデータが削除される。
有効期限を持つデータを保存するときに便利に使われる。

使用可能バージョン: version 2.0.0 以降
論理的な処理時間計算量: O(1)

以下2つのコマンドと同じように動作する。

SET mykey value
EXPIRE mykey seconds

SETEX の使い方

使い方は以下のとおりである。

SETEX [key] [seconds] [value]

文字列値を保存する key を作成するとき、タイムアウト(timeout)も設定できる。key はタイムアウト時間が経過した後に削除される。以下2つのコマンドと同じ効果である。

指定した時間後にデータが削除される: 秒単位で指定。指定した秒(second)の後にデータが削除される。有効期限を持つデータを保存するときに便利に使われる。使い方は SETEX key seconds value である。

Example Command> setex key 5 value Result> OK Command> ttl key Result> 2 残り時間を秒(second)で知らせる Command> get key Result> (nil) 5秒が経過してデータが削除されたアニメーションを見る

TTL コマンドは残り時間を秒(second)で知らせる。

MongoDB でインデックスを適用する方法

kc@example.com (kc kim) — Wed, 12 Jan 2022 08:39:00 +0900

MongoDB はドキュメント型データベースであるため、少し異なるインデックスが存在する。今回は RDB にはないインデックスの概念について見てみよう。

MongoDB のインデックス

MongoDB では基本的に、ドキュメントを作成するたびに _id 属性がユニークインデックスとして自動的に生成される。これで不足する場合は、独自に db.collection.createIndex() を使用してインデックスを作成する。db.collection.createIndex() によって作成されるインデックスは、B-tree データ構造のインデックスである。

MongoDB は単純なキー指定以外にも、いくつかのインデックス型をサポートする。具体的にサポートされるインデックス型は次のとおりである。

単一キー
複合キー
マルチキー
地理空間
テキスト
ハッシュ

「複合キー」と「マルチキー」は名称が似ているが内容は異なる。「複合キー」は複数フィールドを組み合わせたキーであり、「マルチキー」は配列を扱う属性について、その配列に含まれるすべての値を対象にするキーである。

以下では、基本となる「単一キーインデックス」、「複合キーインデックス」、「マルチキーインデックス」について、具体的な使い方をサンプルコードで見ていく。

インデックスの基本作成

mongo シェルで次のコマンドを実行すると、指定したコレクションに対してインデックスを作成できる。

JavaScript コードでも関数は同じだが、3番目の引数にコールバックを指定できる点が異なる。

構文

db.collection.createIndex(keys, options)

引数

引数	Type	説明
`keys`	`string`/`object`	値を持つフィールド名を指定する。昇順キーであれば `1`、降順キーであれば `-1` を指定する。
`options`	`object`	インデックス作成に関するオプションを指定する。オプションとして指定できるものには `unique`、`collation` がある。他にもあるが、ここではこれだけ覚えておこう。

使用例

以下で「単一キーインデックス(Single field index)」、「複合キーインデックス(Compound index)」、「マルチキーインデックス(Multi-key index)」の使用例を見てみよう。

単一キーインデックスの作成

以下のようなサンプルドキュメントにインデックスを作成するサンプルコードを3つ扱う。MongoDB はドキュメント型データベースであるため、RDB にはない「埋め込みフィールド」や「埋め込みドキュメント」に対するインデックス作成ができる。

{
  "score": 1034,
  "location": { city: "Seoul", county: "Korea Republic of" }
}

単一フィールド

もっとも単純な「単一フィールド」に対するインデックス作成のサンプルコードである。

> db.collection.createIndex({ score: 1 })

> db.collection.find({ score: 1034 })
> db.collection.find({ score: { $gt: 1000 } })

埋め込みフィールド

MongoDB は属性値としてドキュメントを指定することもできる。このような場合、ドキュメント内のフィールド、つまりネストされた要素についてもインデックス化できる。

> db.collection.createIndex({ "location.city": 1 })

> db.collection.find({ "location.city": "Kyunggi" })

埋め込みドキュメント

上の「埋め込みフィールド」と似ているが、元のオブジェクトを指定することもできる。ただし、この場合は属性の数と属性の順序を含めて完全一致が求められる点に注意する必要がある。

> db.collection.createIndex({ location: 1 })

> db.collection.find({ city: "Seoul", county: "Korea Republic of" })

複合キーインデックスの作成

RDB にも存在する複合キーインデックスである。MongoDB では複数のフィールドをキーとして指定して作成できる。MongoDB の複合キーインデックスでは、「指定された複合キーすべてに一致する」パターンだけでなく、「一部に一致する」パターンでもインデックスが有効である。

次のサンプルデータに対して「複合キーインデックス」を作成する例を見てみよう。

{
  "item": "Apple",
  "location": "xxx store",
  "stock": 4,
  "type": "cases"
}

> db.collection.createIndex({ item: 1, location: 1, stock: 1 })

> db.collection.find({ item: "Apple" })
> db.collection.find({ item: "Apple", location: "xxx store" })
> db.collection.find({ item: "Apple", location: "xxx store", stock: { $gt: 0 } })

上の例ではインデックスの作成が item -> location -> stock であるため、その先頭部分である item や item -> location などでもインデックスが有効になる。

マルチキーインデックスの作成

MongoDB には、配列を値として使用するフィールドもある。配列の値は「プリミティブ」でも「オブジェクト」でも、どちらの場合でも「マルチキーインデックス」を作成できる。

以下では、配列フィールド ratings を含むコレクションに対してインデックスを作成し、検索するサンプルを見てみる。

{ "item": "Apple",  ratings: [ 2, 9 ] }
{ "item": "Banana", ratings: [ 4, 3 ] }

インデックス作成は、単純に ratings に対して createIndex() を呼び出して作成できる。

> db.collection.createIndex({ ratings: 1 })

配列フィールドに対する検索は、通常 $elemMatch を使用する。以下の例では「3以上6以下の ratings が1レコード以上存在するドキュメント」を抽出している。

> db.collection.find({ ratings: { $elemMatch: { $gte: 3, $lte: 6 } } })
{ "_id" : ObjectId("5a2d24459c684f917e3ec0c2"), "item" : "XYZ", "ratings" : [ 4, 3 ] }

以下のように入力すると、「3以上または6以下を満たすレコードが1件以上存在するドキュメント」を抽出するため、結果的にすべて抽出されてしまう。

> db.collection.find({ ratings: { $gte: 3, $lte: 6 } })
{ "_id" : ObjectId("5a2d24399c684f917e3ec0c1"), "item" : "ABC", "ratings" : [ 2, 9 ] }
{ "_id" : ObjectId("5a2d24459c684f917e3ec0c2"), "item" : "XYZ", "ratings" : [ 4, 3 ] }

参考文書

MongoDB で unique 制約を適用する方法

kc@example.com (kc kim) — Wed, 12 Jan 2022 08:59:00 +0900

今回は「MongoDB で unique 制約を適用する方法」について見てみよう。

unique 制約の適用

MongoDB で unique 制約を適用するには、インデックスを作成するときに createIndex() のオプションとして unique に true を指定すればよい。

以下では、「単一キーインデックス」の場合と「複合キーインデックス」の場合について、サンプルコードを見ていく。

単一キーインデックス

単一キーインデックスであれば、単純に次のようなコードを mongo シェルで実行すると作成できる。

> db.members.createIndex({ userId: 1 }, { unique: true })

複合キーインデックス

複合キーインデックスの場合も、単一キーインデックスとコードは変わらない。

> db.members.createIndex({ firstname: 1, lastname: 1 }, { unique: true })

複合キーインデックスの場合、複合キーの組み合わせとして一意であればよいため、以下は問題なく設定できる。

> db.members.insert({ firstname: "kc", lastname: "Kim" })
> db.members.insert({ firstname: "et", lastname: "Kim" })
> db.members.insert({ firstname: "kc" })

unique 制約の設定制限

RDB の場合と似ているが、すでに重複データが登録されているコレクションに対して unique 制約を設定することはできない。すでに重複している状態では当然と言えば当然である。

また、ハッシュインデックスに対して unique 制約を設定することは推奨されない。(Hashed Indexes の Considerations)

unique 制約キーに値が設定されていない場合の動作

上で「複合キーインデックス」に unique 制約を設定したデータ登録例のように、値がないフィールドが存在する場合、内部的には null が指定されたものとして処理される。

たとえば、次のようにフィールド x に対する unique 制約があるコレクションがあるとする。

> db.collection.createIndex({ x: 1 }, { unique: true })

フィールド x を指定しないデータが登録されたと仮定する。

> db.collection.insert({ y: 1 })
WriteResult({ "nInserted" : 1 })

最初は x: null として指定されるため、正常に登録できる。続けて、フィールド x が存在しない別のデータを挿入するとどうなるだろうか。

> db.collection.insert({ z: 1 })
WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 11000,
        "errmsg" : "E11000 duplicate key error collection: test.collection index: x_1 dup key: { : null }"
    }
})

上記のようにエラーが発生し、挿入できないことがわかる。また、エラーメッセージからも、指定がない場合は null が指定されることがわかる。

参考文書

MongoDB - Unique Indexes

Apache HBase 概要

kc@example.com (kc kim) — Fri, 08 Jul 2022 09:37:00 +0900

HBase とは？

Apache HBase は、米国 Apache Software Foundation が開発し公開しているオープンソースの分散データベース管理システムである。データベースの主流であるリレーショナルデータベースとは異なる構造を持つ NoSQL システムの一つである。

Google が開発し社内システムで内部的に使用している BigTable をモデルに、類似した構造や機能を持つデータベース管理システムをオープンソースソフトウェアとして再現したものである。

同じく ASF が開発して公開している分散ファイルシステム HDFS (Hadoop Distributed File System) を基盤としてデータベースを構築する。リレーショナルデータベースと同じようにテーブル形式でデータを構造化するが、一般的な RDBMS とは異なり、各カラムの値をまとめてストレージ上に記録する。この方式をカラム指向型と呼ぶ。

テーブルの各行 (row) には、カラム名に相当する qualifier と、フィールド値に相当する cell という単位のデータのペアを単位としてデータを保存する。そして、複数の qualifier が column family としてグループ化されている。cell のデータは自動的に履歴管理され、過去の任意時点のデータを呼び出すことができる。

複数のサーバーコンピュータで 1 つのデータベースを管理する分散環境を前提に設計されており、データを複数ノードに分散して記録するシャーディングを自動的に実行する。そのため、アプリケーション側で対象を意識する必要がなく、データの一貫性も強く確保され、処理中に古いデータが外部から参照されないようになっている。

データベース操作は、RDB のような SQL ではなく、Java API や RESTful API などの形式で提供される API をアプリケーションから呼び出して行う。Apache Hadoop の MapReduce など、ビッグデータの大規模分散処理に適している。

HBase は SQL データベースを置き換えるソリューションではないが、Apache Phoenix のようなソフトウェアを使って SQL レイヤーを追加できる。SQL レイヤーを追加すると、JDBC ドライバなどを使い、さまざまな分析作業を慣れた方法で簡単に処理できる。

Apache HBase|GitHub

HBase の歴史

年	イベント
2006年11月	Google が BigTable の論文を発表した。
2007年2月	初期 HBase プロトタイプが Hadoop へのコントリビューションとして作成された。
2007年10月	Hadoop 0.15.0 とともに利用可能な最初の HBase がリリースされた。
2008年1月	HBase は Hadoop のサブプロジェクトになった。
2008年10月	HBase 0.18.1 がリリースされた。
2009年1月	HBase 0.19.0 がリリースされた。
2009年9月	HBase 0.20.0 がリリースされた。
2010年5月	HBase は Apache トップレベルプロジェクトになった。
2010年6月	最初の開発者版である HBase 0.89.20100621 がリリースされた。
2011年1月	HBase 0.90.0 がリリースされた。
2011年半ば	HBase 0.92.0 がリリースされた。

HBase の特徴

Apache HBase の重要な特徴をいくつか示す。

分散 (Distributed)

Apache HBase は、疑似分散 (Pseudo-distributed) モードと完全分散 (Fully distributed) モードの 2 つのモードで実行できる。疑似分散モードはテスト目的で使用され、単一ノードで実行される。一方、完全分散モードは本番環境で使用され、ノードクラスタ上で実行される。

ビッグデータストア

Apache HBase は、数十億行と数百万または数十億カラムを持つテーブルに非常に大きなデータを保存できるように設計されている。Hadoop HDFS 上で実行されるため、低レイテンシでデータに対するリアルタイムの読み書きが可能である。テーブルに保存された膨大なデータの読み取り処理に対して、より良い性能を提供する。

非リレーショナル (Non-Relational)

すでに述べたように、Apache HBase は非リレーショナルデータベースであるため、リレーショナルデータベースモデルには従わない。リレーショナルデータベース管理では、データは行と列の形でテーブルに保存される。そのデータへアクセスするには SQL 言語を使用できるが、Apache HBase の場合、データストレージは固定形式ではなく、独自のストレージおよびクエリメカニズムを使用する。Apache HBase ではスキーマは柔軟であり、要件に応じて拡張できる。

柔軟なデータモデル

Apache HBase は、テーブルにデータを保存できる柔軟なデータモデルを提供する。テーブルには 1 つ以上の column family がある。ユーザーのデータは、key/value ペアの集合である row に保存される。テーブル内の row は row key によって一意に識別される。

拡張可能 (Scalable)

Apache HBase の Region は、行が Region ごとに分散されるため水平スケールが可能である。テーブルは複数の Region に保存でき、Region が非常に大きくなると、同じ中央の row key を基準にデータが 2 つの Region に分割される。

HBase の機能

Apache HBase の機能は次のとおりである。

線形およびモジュール式のスケーラビリティをサポートする。
読み取りと書き込みの厳密な一貫性を提供する。
自動かつ設定可能なテーブルシャーディングを提供する。
RegionServer 間の自動 failover をサポートする。
Apache HBase テーブルで Hadoop MapReduce ジョブをサポートするための便利な基本クラスを提供する。
クライアントアクセスのために Java API を簡単に利用できる。
リアルタイムクエリのためのブロックキャッシュと Bloom filter を提供する。
サーバーサイドフィルタを通じてクエリ述語プッシュダウンを提供する。
拡張可能な JRuby ベース (JIRB) シェルを提供する。

HBase の長所と短所

HBase の長所

大容量データを安定して扱うのに効果的である。
- 中央で分散システム全体を制御する Master を置き、全体データの一貫性を管理することで、複製データ間の一貫性を保証する。
大量データの分析処理支援に適している。
- MapReduce の input として使いやすい。
- HDFS、MapReduce などと一緒に使用するのに最適化されている。
性能問題が発生した場合、Region server を追加するだけで性能を維持できる。
failover が容易で管理しやすい。

HBase の短所

MapReduce の input として使いやすいが、同時にファイル input と一緒に使用すると CPU 使用率が高くなり、Region server が容易に down する。
適切な HBase setting のための条件に関する資料はあるが、Cluster の規模や基本 Spec が異なるため、そのまま適用するのは難しい。
特定 Region server に特定 table の Region が集中しやすく、性能低下につながる。
- 構成時には HBase の適切な設計が必要である。

RDBMS と HBase の違い

リレーショナルデータベースと HBase の主な違いを見てみる。

RDBMS	HBase
テーブルをデータベースとして使用する。	Region をデータベースとして使用する。
サポートされるファイルシステムは FAT、NTFS、EXT である。	サポートされるファイルシステムは HDFS である。
コミットログを使用してログを保存する。	WAL (Write-Ahead Logs) を使用してログを保存する。
使用される参照システムは coordinate system である。	ZooKeeper で使用される参照システムである。
Primary key を使用する。	Row key を使用する。
Partitioning がサポートされる。	Sharding がサポートされる。
Row、Column、Cell を使用する。	Row、Column family、Column、Cell を使用する。

HDFS と HBase の違い

HDFS と HBase の主な違いを見てみる。

HDFS	HBase
HDFS は分散保存のためのファイルシステムを提供する。	HBase はテーブル形式のカラムベースデータストレージを提供する。
HDFS は大容量ファイルに最適化されたストレージを提供する。	HBase はテーブル形式データに対する最適化を提供する。
フラットファイルを使用する。	key-value ペアのデータを使用する。
データモデルは柔軟ではない。	柔軟なデータモデルを提供する。
ファイルシステムと処理フレームワークを使用する。	Hadoop MapReduce サポートを内蔵したテーブル形式ストレージを使用する。
ほとんど write-once-read-many に最適化されている。	多くの読み書きの両方に最適化されている。

行指向データストアとカラム指向データストアの違い

行指向 (Row-oriented) データストアとカラム指向 (Column-oriented) データストアの主な違いを見てみる。

行指向データストア	カラム指向データストア
行指向データストアはレコードの追加/修正に効率的である。	カラム指向データストアはデータ読み取りに効率的である。
行全体を含むページを読み取る。	必要なカラムだけを読み取る。
OLTP システムに最も適している。	まだ OLTP システムには適していない。
行全体の値をシリアライズする。	カラム全体の値をシリアライズする。
メモリの連続ページに行を保存する。	ページのカラムをメモリに保存する。

OLTP (Online Transactional Processing) とは、オンライントランザクション処理を意味し、ネットワーク上のオンラインユーザーによる Database に対する一括トランザクション処理を指す。

カラム指向データベースの長所と短所

カラム指向データベースの長所と短所を見てみる。

長所

効率性およびデータ圧縮に対するサポート機能が組み込まれている。
高速なデータ検索をサポートする。
カラム指向データベースでは管理と構成が単純化される。
COUNT、SUM、AVG、MIN、MAX などの集計クエリに対する高性能に適している。
より大きな Region をより小さな Region に分配する自動シャーディングメカニズムを提供するため、partitioning に効率的である。

短所

複数テーブルの JOIN クエリおよびデータが最適化されていない。
頻繁な削除と更新のために partition を作成する必要があり、ストレージ効率が低下する。
非リレーショナルな特性上、partition と index の設計が非常に難しい。

HBase のユースケース

データ一貫性を保証するため、または分析などの用途で使用する。
- 例: Facebook、eBay、Adobe、LINE など。
監視システム (Monitoring system)。
ユーザー操作の追跡 (Tracking user actions)。
監査ログシステム (Audit logging systems)。
リアルタイム分析 (Real-time analytics)。
- Hadoop を使用して大量データを分析する必要がある場合。
大規模 SNS サービスのメインストレージとして利用。
- メッセージ中心システム (Twitter に似たメッセージおよびステータス)。
HBase からコンテンツを提供するコンテンツ管理システム。
Web クローリング中の Web ページ保存のような標準的なユースケース。

参考資料

Apache HBase アーキテクチャ

kc@example.com (kc kim) — Fri, 08 Jul 2022 09:40:00 +0900

Apache HBase Architecture

Apache HBase は NoSQL データベースである。NoSQL は、データベースが SQL を基本アクセス言語としてサポートする RDBMS ではないことを示す一般的な表現である。Apache HBase は、従来の意味でのデータベースというよりデータストアである。HBase はクラスタに汎用ノードを追加することで、線形かつモジュール式に拡張できる。ノードを 20 個から 40 個に増やすと、HBase クラスタのストレージと容量も同時に増加する。

HBase クラスタアーキテクチャ

Apache HBase の構成要素

HBase は Master server と Region server の 2 種類のサーバーで構成される。
Region server を増設することで簡単にスケールアウトできる構造になっている。 HBase のデータは Region という単位に分割されており、Region の扱い方によってサーバーの種類が分かれる。

Master server - HBase HMaster

Apache HBase HMaster は、RegionServer の監視、障害処理、Region 分割管理を担当する HBase クラスタの重要な構成要素である。

各テーブルのデータは RegionServer が管理し、クラスタ全体は HMaster が管理する。
HMaster は、HBase のすべてのデータ (Region) がどの Region server に保存されているかというメタ情報を管理するサーバーである。
Region server に Region を割り当て、Region server の障害を検知する。

HMaster の機能は次のとおりである。

RegionServer を監視する。
- Region server を調整する。
- Region の起動を管理する。
RegionServer の failover を処理する。
Region を割り当て、または解除する。
クラスタ内のすべての Region server を監視する。
- 管理機能。
- テーブルの作成、削除、更新。
メタデータ変更を処理するために使用される。
すべてのメタデータ変更に対するインターフェースを提供する。
アイドル時間にリバランシングを実行するために使用される。
HMaster は HBase クラスタに関する情報を表示する Web ユーザーインターフェースを提供する。

これらの作業は、Master server 内で動作している ZooKeeper というソフトウェアが担当している。
ZooKeeper は HBase 以外にも多くの分散アプリケーションで使用されるソフトウェアである。

Region server - HBase Region Server

RegionServer は、Master server から割り当てられた実データの保存を担当する。Hadoop クラスタと同じように、NameNode はメタデータを保存し、DataNode は実データを保存する。HBase でも同様に、Master はメタデータを保持し、RegionServer は実データを保存する。RegionServer は分散クラスタ環境の DataNode 上で実行される。

RegionServer は次の作業を行う。

割り当てられた regions (tables) を処理する。
クライアントが実行する読み取りおよび書き込み要求を処理する。
キャッシュを HDFS に flush する。
Region 分割処理を担当する。
HLog を維持管理する。

クライアントはまず Master server、正確には ZooKeeper に問い合わせ、対象データ (Region) を保持している Region server の位置を取得する。

その後、その Region server がクライアントの要求を担当する。
Region は常に単一の Region server によって管理され、読み取りと書き込みに対するデータ一貫性を維持する。

Region server が down すると、割り当てられていた Region は別の Region server に failover される。この作業は Master server が実行する。
ただし、failover が完了するまで、クライアントは対象 Region に対して読み書きできない。

RegionServer の構成要素

RegionServer の構成要素を見てみる。

WAL (Write-Ahead Logging)

WAL とは、データ整合性を保証する標準的な方法であり、DB で使用される方式である。WAL を使用するシステムでは、データを修正する前にまず WAL に記録する。この記録を利用して、どの時点で障害が発生したか、どこまで成功し、どこから後続作業を実行すべきかを知ることができる。

PostgreSQL、HBase、MongoDB など、さまざまな DB システムで WAL 方式が使用される。

Apache HBase WAL は、編集ログファイルとも呼ばれる中間ファイルである。HBase でデータを読み取ったり修正したりするとき、ディスクに直接書き込むのではなく、一定時間メモリに保持する。そのため、システムが down するとメモリ上のデータが失われる可能性がある。この問題を克服するため、Apache HBase はデータをメモリに記録する前に、まず Write-Ahead Logging ファイルに記録する。

HFile

HFile は HBase にデータを保存するためのフォーマットであり、Column Family に属する。Column Family は複数の HFile を持つことができる。 Row データが物理的に保存される実ファイルであり、データは Key/Value 形式で保存される。 MemStore が十分に満たされると、HDFS に新しい HFile を作成して保存する。
ランダムアクセスを最小化する構造のため、この処理は非常に高速に行われる。

Store

HBase のテーブルに対する Column family に該当する。ここに HFile が保存される。

MemStore

MemStore はメインメモリに常駐し、現在のデータ操作を記録する。データが WAL に保存されると、Region Server のメモリストアに key/value データをソートして保存する。このデータをそのまま HFile に保存する。 1 つの Column Family ごとに 1 つの MemStore が存在する。

Region

Region は、key を基準に分割され、RegionServer でホストされるテーブルの分割単位である。

クライアント

クライアントは Java またはその他の言語で作成でき、外部 API を使用して実際の row データを管理する RegionServer に接続できる。クライアントは Region を探すために catalog table に問い合わせ、Region が見つかると、RegionServer に直接接続してデータ操作を実行し、高速検索のためにデータをキャッシュする。

Catalog table

Catalog table は、すべての RegionServer および Region に関するメタデータを維持するために使用される。

HBase には 2 種類の catalog table がある。

-ROOT- このテーブルには META テーブルの位置に関する情報がある。
.META このテーブルにはすべての Region とその位置に関する情報が含まれている。

ZooKeeper

Apache ZooKeeper は HBase のコーディネータのようなものである。HBase は ZooKeeper を利用して、クラスタを構成するサーバーの状態を管理する。構成情報の維持、命名、分散同期の提供、サーバーエラー通知などのサービスを提供する。クライアントは ZooKeeper を通じて Region server と通信する。

Apache ZooKeeper は、HBase に分散同期とグループサービスを提供する分散アプリケーション向けの高性能な集中型多重調整サービスシステムである。クラスタ調整を担いながら、ユーザーがアプリケーションロジックに集中できるようにする。また、ユーザーが Master server と連携できる API も提供する。

Apache ZooKeeper API は、一貫性、順序付け、耐久性を提供し、分散クラスタシステムに対する同期と同時実行性も提供する。

HBase データの書き込み/読み取りプロセス

HBase でデータを読み書きする過程について説明する。

HBase データ書き込み

HBase でデータを保存するときは、WAL (Write Ahead Log) と Region server の MemStore の 2 か所にデータを保存する。

この 2 つを利用し、WAL と MemStore の両方で変更が発生した時点で書き込み処理が正常に完了したことになる。

HBase にデータ投入要求が来ると、まず適切な Region server を探す。Region server を見つけると Commit log を追加し、メモリ内の MemStore に追加される。 MemStore に保存されていたデータは、設定された値に従っていっぱいになると HFile という形式でディスクに flush され、メモリを空けて再び要求を待つ。同時に WAL にもこれに関する記録を残す。 MemStore flush は hbase.hregion.memstore.flush.size の値を超える場合に発生し、単位は byte で 134217728 (128 MB) に設定されている。

MemStore は Region server のメモリ領域であり、キャッシュのような機能を持つ。そして、MemStore のデータが一定量集まった時点で、ディスク上に HFile としてデータを書き出して永続化する。
ただし、HFile に書き出す前のデータはサーバーのメモリ (MemStore) に保存されているため、サーバーが down すると消える。そのため、HBase はデータを書き込むときに HLog というログを残し、サーバーが down した場合は HLog をもとにデータを復旧できる。

HBase データ読み取り

HBase でデータを読み取る過程は、前述した HBase データ書き込み過程と似ている。

HBase に要求が入ると、まず MemStore を確認する。MemStore で目的のデータを見つけると、そのデータを返す。そうでない場合は、最近 flush されたファイルから古い順に、クエリを満たす適切なデータを見つけるか、これ以上 flush ファイルがなくなるまで繰り返す。

参考資料

HBase 紹介|joinc.co.kr

Apache HBase リージョン(Regions)

kc@example.com (kc kim) — Wed, 21 Jun 2023 11:05:33 +0900

Apache HBase は、行キーで辞書順にソートされたテーブルに大容量データを保存する。テーブルは複数のリージョン(Region)に分散され、リージョンはさらに複数の RegionServer に分散される。Apache HBase でテーブルを作成すると、デフォルトリージョンが割り当てられる。

Apache HBase リージョンは水平方向に拡張可能である。これには開始キーと終了キーが含まれ、該当する行を基準にソートされ、連続した形式で保存される。HBase は強い一貫性を提供するため、複数のリージョンに同じ行キーを保存しない。リージョンは複数の RegionServer に負荷を分散し、要件に応じて負荷分散とフェイルオーバーも行う。データが増加する場合、リージョンは手動または自動で分割される。

リージョン数

RegionServer ごとに中大規模(5-20GB)のリージョンを少数(20-200個)使用することが推奨される。リージョンの標準数は100個である。

リージョンを考慮する際のいくつかの要素を見てみよう。

リージョン数を選択する際の制限要因は、利用可能なヒープ領域である。MemStore にはリージョンごと、カラムファミリーごとにほぼ 2MB が必要であり、リージョンが100個、リージョンごとに3つのカラムファミリーがある場合、MemStore のヒープ領域要件は 600MB である。リージョンが少ないほど MemStore のヒープ要件は少なくなる。
多数のリージョンは、多数の小さな flush を生成する。各 flush が StoreFile を作成すると多数の StoreFile が作成されるため、より多くの compaction が必要になる。また、MemStore および StoreFile インデックスにはより多くのヒープ領域が必要である。
master が RegionServers にリージョンを割り当て、再割り当てする必要があるため、多数のリージョンは master に負荷を生む。また、master はロードバランシングのためにリージョンを移動する必要がある。

リージョン割り当て(Region Assignment)

Apache HBase でリージョンは、以下のように master によって割り当てられる。

master は assignment manager を開始する。
assignment manager は hbase:meta メタデータで既存の割り当てを確認する。
RegionServer が利用可能な場合、割り当ては保存される。
RegionServer がオンライン状態でなければ、load balancer が呼び出され、リージョンを別の RegionServer に割り当てる。
hbase:meta メタデータが新しい割り当てで更新される。

リージョンフェイルオーバー(Region failover)

RegionServer は失敗する可能性があり、複数の RegionServer がデータを提供するため、RegionServer のリージョンが利用できなくなることがある。ZooKeeper は RegionServer のエラーを検出し、master はリージョンに類似した Row Key を持つ別の RegionServer でフェイルオーバーを開始する。

リージョンローカリティ(Region Locality)

Region Locality は、RegionServer に対するリージョンの近接性を示す。これはクラスター全体で HDFS ブロックレプリケーションによって達成される。

レプリカ配置ポリシーは HDFS のレプリカ配置ポリシーであり、次のとおりである。

1つ目のレプリカはローカルノードに配置される。
2つ目のレプリカは別ラック(rack)の任意ノードに配置される。
3つ目のレプリカは2つ目のレプリカと同じラック(rack)に配置されるが、このときは別ノードに配置される。

リージョンの利点(Benefits of Regions)

リージョンの利点は、分散データストア、パーティショニング、自動シャーディングと拡張性、リージョン分割である。

それぞれ詳しく見てみよう。

分散データストア

分散データストアの設計は、テーブルに複数のリージョンを使用する Apache HBase の設計と一致する。ノードクラスター全体に大きなテーブルのリージョンを分散すると、高可用性を得られる。

パーティショニング

データテーブルは複数のリージョンに保存され、リージョンはデータを分割する。これで該当テーブルのデータにアクセスするには、別のリージョンからアクセスする必要がある。複数のリージョンがあれば、データを高速に配信できる利点がある。

自動シャーディングと拡張性

自動シャーディングプロセスは、リージョンの行キー数が多くなりすぎたときに、リージョンをおよそ2つの半分に分割するために使用される。HBase で水平拡張性の基本単位はリージョンであり、リージョンごとに行を共有する。

リージョン分割

しきい値を超えるとリージョンが分割される。これはリージョンを分割し、分割されたリージョンをオフラインにする RegionServer によって処理される。その後、2つの分割リージョンが hbase:meta に追加され、RegionServer で開かれ、master に報告される。リージョン分割は基本的に自動だが、手動で実行することもできる。HBase リージョン分割ポリシーは hbase.regionserver.region.split.policy で構成される。

HBase データモデル

kc@example.com (kc kim) — Tue, 20 Jun 2023 19:07:12 +0900

データ構造

HBase テーブルには型がなく、バイト配列(byte[])として保存される。
HBase の行は一意な行キーで昇順にソートされ、テーブルの値を読み書きするときはこの行キーを通じて行われる。
前述したように、HBase が管理するデータは一定範囲ごとにリージョンという単位で分割され、テーブルには複数のリージョンがある。また、HBase の列は Column Family という単位でグループ化される。
テーブルのデータはリージョンごとに分かれ、Column Family ごとに分かれてファイルへ出力される。ファイルは別々だが、同じリージョンであれば同じ Region Server に保存される。

HBase データ、つまりセル値にはそれぞれ timestamp が付与されており、バージョンが管理されている。ファイルは次の形式で保存される。

Row(Row Key): Column family: Column: timestamp: 値

データモデル

Apache HBase データモデルは、列(Column) key、行(Row) key、および timestamp によってインデックスが作成される分散型、多次元型、永続型、ソート済みの map であり、これが Apache HBase が key-value ストレージシステムとも呼ばれる理由である。

HBase の基本単位は Column であり、この Column が集まって Column Family を構成し、この Column Family が集まってテーブルを構成する。テーブルに入る各 Row は Row Key を持ち、識別できる。以下の図を見てみよう。

このテーブルは Customer と Sales の2つの Column Family を持つ。
Customer Column Family は Name と City の2つの Column を持つ。
Sales Column Family は Product と Amount の2つの Column を持つ。
Row は Row Key、Customer CF、Sales CF で構成される。

次は Apache HBase で使用されるデータモデル用語である。

Table

Apache HBase テーブルは複数の Row で構成される。文字で構成され、ファイルシステムと一緒に使用しやすいテーブルとしてデータを構成する。

Row の集合。Row Key があり、多数の column family で構成される。
Schema 定義では Column Family のみを定義する。

Row

Apache HBase は行(Row)を基準にデータを保存し、各行には一意な Row Key がある。Row Key はバイト配列で表される。

Row Key

Row Key を基準にデータが集まるため、Row Key は適切にデータが分散されるよう設計する必要がある。Row Key 設計の目標は、似た Row が互いに近くなる方式でデータを保存することである。

任意の Byte 列として辞書順にソートされる。
空の Byte 文字列はテーブルの開始と終了を意味する。
文字列、整数バイナリ、シリアライズされたデータ構造まで、どのようなものでも Row Key になり得る。

一般的に Row Key パターンは Web サイトドメイン形式で構成することもできる。org.apache.mair、org.apache.jira のようにドメインを逆順に保存すると、apache ドメインは近い位置にデータを保存できる。

Column

Column Family と Column Qualifier で構成される。

Column Family

Column Family は Row を保存するために使用され、Apache HBase にデータを保存する構造も提供する。

文字と文字列で構成され、ファイルシステムパスと一緒に使用できる。テーブルの各行は同じ column family を持つが、すべての column family に行を保存する必要はない。

Column Qualifier

Column Qualifier は Column Family に保存されたデータに対するインデックスを提供する。Column qualifier は固定値ではないため、さまざまなデータを入力できる。map オブジェクトと考えられる。

Column のグループであり、すべての ColumnFamily の Member は同じ prefix を使用する。
NOSQL:Cassandra と NOSQL:HBASE は NOSQL という Column Family の member column である。
ColumnFamily prefix は必ず表示可能な文字で構成する。
テーブルスキーマで定義の一部を先に指定する必要がある。
すべての ColumnFamily member は物理的にファイルシステムで一緒に保存される。
新しい ColumnFamily member は動的に追加可能である。

Cell

Cell は Column family、Row key、Column qualifier で構成されるデータ単位であり、各 Column の値を Cell という。

データ Cell には value(値)と timestamp(値のバージョン)を含む。timestamp があるため、以前の値も一緒に保存され、一定期間その値を保持する。

ROW KEY、Column、Version が明示された tuple。
値は任意の Byte 列であり Timestamp。
テーブル Cell はバージョン管理される。Cell のみである。

Timestamp

Cell に同じデータが保存された値にはバージョンが指定され、各バージョンは生成時間に割り当てられたバージョン番号で識別される。データを書き込むときに Timestamp を明示しなければ、現在時刻が指定される。

HBase データ型(Data Types)

Apache HBase にはデータ型の概念がない。すべてバイト配列である。値が挿入されると、Put および Result インターフェースを使用してバイト配列へ変換される、一種の byte-in and byte-out データベースである。Apache HBase はシリアライズフレームワークを使用して、ユーザーデータをバイト配列へ変換する。

Apache HBase Cell には最大 10から15MB の値を保存できる。値がより大きい場合は Hadoop HDFS に保存し、ファイルパスメタデータ情報を Apache HBase に保存できる。

HBase データストア

次は Apache HBase の物理的に保存される形式について紹介する。

概念的観点

テーブルが概念レベルで一連の Row として表示されることがわかる。

次はデータが HBase に保存される方式の概念図である。

物理的観点

Physical view テーブルは column family によって物理的に保存される。

次の例は、Column Family ベースのテーブルとして保存されるテーブルを表す。

ネームスペース

ネームスペースはテーブルの論理グループである。関連テーブルをグループ化するリレーショナルデータベースに似ている。

ネームスペースの表現を見てみよう。

HBase Namespaces
- Table
- Region Server Group
- Permission
- Quota

ネームスペース空間の各構成要素を見てみよう。

Table

すべてのテーブルはネームスペースの一部である。定義されたネームスペースがなければ、テーブルは default ネームスペースに割り当てられる。

RegionServer group

ネームスペースに対するデフォルト RegionServer group を持つことができる。この場合、作成されたテーブルは RegionServer の構成員になる。

Permission

ネームスペースを使用して、ユーザーは読み取り、削除、更新権限などのアクセス制御リストを定義でき、書き込み権限を使用してテーブルを作成できる。

Quota

この構成要素は、ネームスペースがテーブルおよびリージョンに対して含められる割り当て量を定義するために使用される。

事前定義された namespaces

事前定義された2つの特殊ネームスペースがある。

hbase: HBase 内部テーブルを含めるために使用されるシステムネームスペースである。
default: このネームスペースは、ネームスペースが定義されていないすべてのテーブルのためのものである。

データモデル操作

主要な作業データモデルは Get、Put、Scan、Delete である。これらの操作を使用してテーブルからレコードを読み、書き、削除できる。

各操作を詳しく見てみよう。

Get

Get 操作はリレーショナルデータベースの Select 文に似ている。HBase テーブルの内容を取得するために使用される。

以下のように HBase Shell で Get コマンドを実行できる。

hbase(main) :001:0> get 'table name', 'row key' <filters>

Put

Put 操作はテーブルにデータを書き込むために使用される。

Scan

Scan 操作はテーブルの複数行を読むために使用される。読み取る行集合を指定する必要がある Get とは異なる。Scan を使用すると、行範囲またはテーブルのすべての行を反復できる。

Delete

Delete 操作は HBase テーブルから行または行集合を削除するために使用される。HTable.delete() によって実行できる。

削除コマンドが実行されると削除マークで表示され、compaction が発生すると該当行がテーブルから最終削除される。

内部削除の種類は以下のとおりである。

Delete: 特定バージョンの Column に使用される。
Delete column: すべての列バージョンに使用できる。
Delete family: 特定 ColumnFamily のすべての列に使用される。

ローカル練習用 HBase Docker インストール

kc@example.com (kc kim) — Tue, 13 Jun 2023 18:40:33 +0900

HBase を Docker にインストール

以下の Docker イメージを利用して、Docker 環境に HBase をインストールしてみる。

インストールする HBase Docker image
- https://hub.docker.com/r/dajobe/hbase

HBase Docker 実行コマンドのダウンロード

以下の GitHub から HBase Docker 実行コマンドをダウンロード、つまり clone する。

GitHub
- https://github.com/dajobe/hbase-docker

git clone git@github.com:dajobe/hbase-docker.git

HBase Docker の実行

Docker が起動した状態で、以下のコマンドをそのまま実行する。

./start-hbase.sh

コンテナを起動し、すべてのローカル API ポートと Web UI を調べ、まだ存在しない場合はコンテナ IP への alias を追加するために /etc/hosts の編集を提案する start-hbase.sh スクリプトを使用することが推奨される。

コンテナを起動して、すべてのローカル API ポートと Web UI を決定し、まだ存在しない場合はコンテナ IP への alias を追加するために /etc/hosts の編集を提案する start-hbase.sh スクリプトを使用することが推奨される。

% ./start-hbase.sh
start-hbase.sh: Starting HBase container
Error: No such container: hbase-docker
Unable to find image 'dajobe/hbase:latest' locally
latest: Pulling from dajobe/hbase
6cf436f81810: Pulling fs layer

... 中間省略 ...

159beed970fa: Pull complete
Digest: sha256:daa36a6d90b118ced866b6c76fcd918e7da73302b0e4971f506f0f61f645a9fe
Status: Downloaded newer image for dajobe/hbase:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
start-hbase.sh: Container has ID 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361
./start-hbase.sh: line 32: python: command not found

ここでコンテナ ID は 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361 である。Shell 実行時に必要なので記録しておこう。

上記コマンドを実行すると、実行した現在のパスに data が作成され、port が開かれて HBase が実行される。

手動で実行する方法

docker run --name=hbase-docker \
  -h hbase-docker \
  -p 9095:9095 \
  -p 8085:8085 \
  -p 16010:16010  \
  -v $PWD/data:/data \
  -d dajobe/hbase

HBase Shell の実行

次に、Docker イメージを利用して HBase に接続できる Shell コマンドを実行してみる。

上で記録したコンテナ ID を $id に入れて実行する。

docker run --rm -it --link $id:hbase-docker dajobe/hbase hbase shell

macOS Apple Chip(M1, M2) の場合は、以下のようなエラーが出ることがある。

% docker run --rm -it --link 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361:hbase-docker dajobe/hbase hbase shell
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

その場合、すでに実行された Docker を削除し、--platform linux/amd64 オプションを入れて再実行すると動作するはずである。

% docker run --rm -it --platform linux/amd64 --link 3804d552250334cc850189e076b77cb0d3066850cef332bec7a125dc29228361:hbase-docker dajobe/hbase hbase shell

2023-06-16 09:38:17,680 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
HBase Shell
Use "help" to get list of supported commands.
Use "exit" to quit this interactive shell.
For Reference, please visit: http://hbase.apache.org/2.0/book.html#shell
Version 2.1.2, r1dfc418f77801fbfb59a125756891b9100c1fc6d, Sun Dec 30 21:45:09 PST 2018
Took 0.0480 seconds
hbase(main):001:0>

Shell から抜けるコマンドは quit である。

hbase(main):005:0> quit

Command の使用方法は次のページで説明する。

HBase 一般 Shell コマンド - status, version, whoami

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

General HBase shell commands

ここでは HBase の一般コマンドについて紹介する。

`status`

cluster 状態を表示する。追加オプション("summary", "simple", "detailed")を通じて詳細情報を確認できる。デフォルトは "summary" である。

status コマンドでクラスターの状態を確認できる。

オプション	説明
simple	サーバー情報
summary	サーバー数、ロード負荷
detailed	サーバー情報、メタ情報
replication	ソース、シンク情報

status

hbase(main):001:0> status
1 servers, 0 dead, 2.0000 average load

status 'simple'

hbase(main):002:0> status 'simple'
1 live servers
    532f4d895a98:40371 1686636094968
        requestsPerSecond=0.0, numberOfOnlineRegions=2, usedHeapMB=19, maxHeapMB=966, numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=42, writeRequestsCount=5, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, coprocessors=[]
0 dead servers
Aggregate load: 0, regions: 2

status 'summary'

hbase(main):003:0> status 'summary'
1 servers, 0 dead, 2.0000 average load

status 'detailed'

hbase(main):004:0> status 'detailed'
version 2.0.0-SNAPSHOT
0 regionsInTransition
master coprocessors: []
1 live servers
    532f4d895a98:40371 1686636094968
        requestsPerSecond=0.0, numberOfOnlineRegions=2, usedHeapMB=21, maxHeapMB=966, numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=42, writeRequestsCount=5, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, coprocessors=[]
        "hbase:meta,,1"
            numberOfStores=1, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=36, writeRequestsCount=3, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=10
        "hbase:namespace,,1686636105191.93358ca1f9bf1816320d88c48e39a3b4."
            numberOfStores=1, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2, rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=8
0 dead servers

version

インストールされた HBase のバージョン情報を確認する。

version

hbase(main):001:0> version
2.0.0-SNAPSHOT, r31ed817447b4c3edef2019d1580aa3ede83a82da, Fri Sep 26 02:07:26 UTC 2014

whoami

現在の HBase ユーザーを確認する。

whoami

hbase(main):008:0> whoami
root (auth:SIMPLE)
    groups: root

HBase テーブル管理コマンド - create, list, exists, disable/enable, describe, alter, drop

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

Table Management commands

ここでは、テーブル管理に関する HBase Shell コマンドを紹介する。

create - テーブル作成

create コマンドを使用してテーブルを作成できる。ここでは、テーブル名と Column Family 名を指定する必要がある。HBase shell でテーブルを作成する構文は次のとおりである。

create '<table name>', '<column family>'

次は order というテーブルのサンプルスキーマである。ここには customer と sales という 2 つの column family がある。

次のように HBase shell でこのテーブルを作成できる。

create 'order', 'customer', 'sales'

実行すると次のように表示される。

hbase(main):002:0> create 'order', 'customer', 'sales'
Created table order
Took 2.4344 seconds
=> Hbase::Table - order

create オプション

テーブルを作成するときにオプションを追加することもできる。

t1 を作成しながら、最新の version を最大 5 個まで保存する column family cf1 を作成する。

create 't1', {NAME => 'f1', VERSIONS => 5}

t1 を作成しながら、column family cf1、cf2、cf3 を作成する。

create 't1', {NAME => 'f1', NAME => 'f2', NAME => 'f3'}

その他のオプションを指定したコマンドである。

create 't1', {NAME => 'cf2', VERSION => 1, TTL => 2592000, BLOCKCACHE =>true}

create 't1', {NAME => 'cf2', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' ='10'}}

list - テーブル一覧照会

list は、HBase のすべてのテーブルを一覧表示するために使用されるコマンドである。list コマンドの構文は次のとおりである。

list

このコマンドを入力し、HBase プロンプトで実行すると、次のように HBase のすべてのテーブル一覧が表示される。

hbase(main):004:0> list
TABLE
order
1 row(s) in 0.1070 seconds
=> ["order"]

次のようにオプションを付けることもできる。

hbase(main):005:0> list 'customer.*'
TABLE
order
1 row(s) in 0.0140 seconds
=> ["order"]

exists - テーブル存在確認

exists コマンドを使用してテーブルの存在を確認できる。次はテーブルの存在を確認する構文である。

exists '<table name>'

次の例では、order テーブルが存在するかを確認している。

hbase(main):022:0> exists 'order'
Table order does exist
0 row(s) in 0.0680 seconds

次の例では、user テーブルが存在するかを確認しているが、実際には存在しない場合である。

hbase(main):023:0> exists 'user'
Table user does not exist
0 row(s) in 0.0110 seconds

disable - テーブル無効化

テーブルを削除したり設定を変更したりするには、まず disable コマンドを使用してテーブルを無効化する必要がある。enable コマンドを使用すると再び有効化できる。

テーブルを無効化する構文は次のとおりである。

disable '<table name>'

次は order テーブルを無効化する方法を示す例である。

hbase(main):004:0> disable 'order'
0 row(s) in 1.4570 seconds

テーブルを無効化した後でも、list および exists コマンドでテーブルの存在を確認できる。

hbase(main):009:0> list
TABLE
order
1 row(s) in 0.0140 seconds
=> ["order"]

無効化されたテーブルは scan できない。次のようなエラーが発生する。

hbase(main):010:0> scan 'order'
ROW                                         COLUMN+CELL

ERROR: order is disabled.

// omitted

is_disabled

このコマンドは、テーブルが無効化されているかを確認するために使用される。構文は次のとおりである。

is_disabled '<table name>'

次の例では、order というテーブルが無効化されているかどうかを確認する。無効化されていれば true を返し、そうでなければ false を返す。

hbase(main):011:0> is_disabled 'order'
true
0 row(s) in 0.0360 seconds

disable_all

disable_all コマンドは、指定した正規表現に一致するすべてのテーブルを無効化するために使用される。disable_all コマンドの構文は次のとおりである。

disable_all ‘<regex table name>’

簡単な例を次に示す。次のコマンドは r で始まるすべてのテーブルを無効化する。

disable_all 'r.*'

HBase に dev_follow、dev_friend、dev_test、dev_user という dev で始まる 4 つのテーブルがあると仮定する。次のコードは dev で始まるすべてのテーブルを無効化する。

hbase(main):017:0> disable_all 'dev.*'
dev_follow
dev_friend
dev_test
dev_user

Disable the above 4 tables (y/n)?
y
4 tables successfully disabled

enable - テーブル有効化

無効化されたテーブルを有効化するには、enable コマンドを使用する。次はテーブルを有効化する構文である。

enable '<table name>'

次はテーブルを有効化する例である。

hbase(main):018:0> enable 'order'
0 row(s) in 0.6580 seconds

テーブルを有効化した後に scan する。エラーが発生しなければ、テーブルが正常に有効化されたということである。

hbase(main):020:0> scan 'order'
ROW                                         COLUMN+CELL
0 row(s) in 0.0730 seconds

is_enabled

is_enabled コマンドは、テーブルが有効化されているかを確認するために使用される。構文は次のとおりである。

is_enabled '<table name>'

次のコマンドは、order というテーブルが有効化されているかどうかを確認する。有効化されていれば true を返し、そうでなければ false を返す。

hbase(main):021:0> is_enabled 'order'
true
0 row(s) in 0.0750 seconds

describe - テーブル説明

describe コマンドは、テーブルに関する説明を返す。構文は次のとおりである。

describe '<table name>'

次は order テーブルに対する describe コマンドの出力である。

hbase(main):006:0> describe 'order'
DESCRIPTION                                                                                                  ENABLED
 'order', {NAME => 'customer', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCO true
 PE => '0', VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELL
 S => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'}, {NAME => 'sales', DATA_BLO
 CK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NON
 E', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY =
 > 'false', BLOCKCACHE => 'true'}
1 row(s) in 0.1450 seconds

alter - テーブル変更

alter は既存のテーブルを変更するために使用されるコマンドである。このコマンドを使用して、column family の最大 cell 数を変更したり、テーブルスコープ演算子を設定および削除したり、テーブルから column family を削除したりできる。

Column Family の最大 cell 数変更

次は column family の最大 cell 数を変更する構文である。

alter '<table name>', NAME => '<column family>', VERSIONS => 5

次の例では最大 cell 数を 5 に設定する。

hbase(main):007:0>alter 'order', NAME => 'customer', VERSIONS => 5
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.4240 seconds

hbase(main):009:0>

テーブルスコープ演算子

alter を使用すると、MAX_FILESIZE、READONLY、MEMSTORE_FLUSHSIZE、DEFERRED_LOG_FLUSH などのテーブルスコープ演算子を設定および削除できる。

READONLY - 読み取り専用設定

次はテーブルを読み取り専用にする構文である。

alter '<table name>', READONLY(option)

次の例では、order テーブルを読み取り専用にしている。

hbase(main):009:0> alter 'order', READONLY
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.3650 seconds

MAX_FILESIZE - region 設定変更

MAX_FILESIZE で region 設定を変更する。

alter 't1', MAX_FILESIZE => '123217728'

region の最大サイズを 128 MB に変更する。

Column Family 削除

alter を使用すると column family を削除することもできる。次は alter を使用して column family を削除する構文である。

alter '<table name>', 'delete' => '<column family>'

次は order テーブルから column family を削除する例である。

hbase(main):010:0> alter 'order', 'delete' => 'sales'
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.3790 seconds

describe コマンドで確認すると、'sales' が消えたことがわかる。

hbase(main):011:0> describe 'order'
DESCRIPTION                                                                                                  ENABLED
 'order', {NAME => 'READONLY', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCO true
 PE => '0', COMPRESSION => 'NONE', VERSIONS => '1', TTL => 'FOREVER', MIN_VERSIONS => '0', KEEP_DELETED_CELL
 S => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'}, {NAME => 'customer', DATA_
 BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '5', COMPRESSION => '
 NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMOR
 Y => 'false', BLOCKCACHE => 'true'}
1 row(s) in 0.0850 seconds

drop - テーブル削除

drop コマンドを使用してテーブルを削除できる。構文は次のとおりである。

drop '<table name>'

テーブルを削除する前に無効化する必要がある。

hbase(main):024:0> disable 'order'
0 row(s) in 1.3960 seconds
hbase(main):025:0> drop 'order'
0 row(s) in 0.2860 seconds

exists コマンドを使用して、テーブルが削除されたかを確認する。

hbase(main):026:0> exists 'order'
Table order does not exist
0 row(s) in 0.0710 seconds

drop_all

drop_all コマンドは、指定した正規表現に一致するすべてのテーブルを削除するために使用される。構文は次のとおりである。

drop_all '<regex table name>'

簡単な例を次に示す。次のコマンドは t で始まるすべてのテーブルを削除する。

drop_all 't.*'

参考: 対象のすべてのテーブルは、削除する前に無効化する必要がある。

HBase データ操作コマンド - put, get, delete, deleteall, scan, count, truncate

kc@example.com (kc kim) — Fri, 16 Jun 2023 14:55:22 +0900

Data Manipulation commands

ここでは、データを操作する HBase Shell コマンドを紹介する。

put - データ登録/変更

ここでは、HBase テーブルでデータを作成および変更する方法を紹介する。

HBase に次のようなテーブルを作成する。

put コマンドを使用して、テーブルに row を登録および変更できる。構文は次のとおりである。

put '<table name>', '<row id>', '<column family>:<column name>', '<value>'

最初の row 登録

create 'order', 'customer', 'sales'

put 'order', '101', 'customer:name', 'John White'
put 'order', '101', 'customer:city', 'Los Angeles'
put 'order', '101', 'sales:product', 'Chairs'
put 'order', '101', 'sales:amount', '400.00'

まずテーブルを作成する。

hbase(main):001:0> create 'order', 'customer', 'sales'
Created table order
Took 5.0510 seconds
=> Hbase::Table - order

最初の row の値をテーブルに登録する。

hbase(main):002:0> put 'order', '101', 'customer:name', 'John White'
Took 0.6725 seconds
hbase(main):003:0> put 'order', '101', 'customer:city', 'Los Angeles'
Took 0.0318 seconds
hbase(main):004:0> put 'order', '101', 'sales:product', 'Chairs'
Took 0.0988 seconds
hbase(main):005:0> put 'order', '101', 'sales:amount', '400.00'
Took 0.0423 seconds

テーブル全体を scan すると、次のような結果が表示される。

hbase(main):006:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686908392705, value=Los Angeles
 101                              column=customer:name, timestamp=1686908388954, value=John White
 101                              column=sales:amount, timestamp=1686908401071, value=400.00
 101                              column=sales:product, timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.4121 seconds

データ変更

put コマンドを使用して既存 cell の値を変更できる。構文はデータを登録するときと同じである。

次のように新しい値を指定すればよい。

put 'order','101','customer:city','LA'

コマンド実行は次のとおりである。

hbase(main):007:0> put 'order','101','customer:city','LA'
Took 0.0677 seconds

hbase(main):008:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686909532774, value=LA
 101                              column=customer:name, timestamp=1686908388954, value=John White
 101                              column=sales:amount, timestamp=1686908401071, value=400.00
 101                              column=sales:product, timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.1186 seconds

get - データ照会

get コマンドは、HBase のテーブルからデータを読み取るために使用される。構文は次のとおりである。

get '<table name>', '<row id>'

次の例では、get コマンドを使用して order テーブルの 101 row を照会している。

hbase(main):009:0> get 'order', '101'
COLUMN                            CELL
 customer:city                    timestamp=1686909532774, value=LA
 customer:name                    timestamp=1686908388954, value=John White
 sales:amount                     timestamp=1686908401071, value=400.00
 sales:product                    timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.3162 seconds

特定 row 照会

次は、get コマンドを使用して特定 column を照会する構文である。

get '<table name>', '<row id>', {COLUMN => '<column family>:<column name>'}

次は HBase テーブルの特定 column を照会する例である。

hbase(main):010:0> get 'order', '101', {COLUMN => 'customer:name'}
COLUMN                            CELL
 customer:name                    timestamp=1686908388954, value=John White
1 row(s)
Took 0.1450 seconds

delete - テーブルの特定 cell 削除

delete コマンドを使用して、テーブルの特定 cell を削除できる。delete コマンドの構文は次のとおりである。

delete '<table name>', '<row id>', '<column name>', '<timestamp>'

次は特定 cell を削除する例である。ここでは city を削除する。

hbase(main):011:0> delete 'order', '101', 'customer:city', 1686909532774
Took 0.0917 seconds

再度照会すると、前の put コマンドで変更した 'LA' 値が削除され、既存の 'Los Angeles' 値が再び表示されることがわかる。

hbase(main):012:0> get 'order', '101'
COLUMN                            CELL
 customer:city                    timestamp=1686908392705, value=Los Angeles
 customer:name                    timestamp=1686908388954, value=John White
 sales:amount                     timestamp=1686908401071, value=400.00
 sales:product                    timestamp=1686908398256, value=Chairs
1 row(s)
Took 0.2196 seconds

deleteall - テーブル row のすべての cell 削除

deleteall コマンドを使用して、row のすべての cell を削除できる。次は deleteall コマンドの構文である。

deleteall '<table name>', '<row id>'

次は order テーブルの 1 行のすべての cell を削除する deleteall コマンドの例である。

hbase(main):013:0> deleteall 'order','101'
Took 0.1271 seconds
hbase(main):015:0>

scan コマンドを使用してテーブルを確認する。テーブルデータを削除した後のスナップショットは次のとおりである。

hbase(main):015:0> scan 'order'
ROW                               COLUMN+CELL
0 row(s)
Took 0.0518 seconds

scan - データ照会

scan コマンドは HTable のデータを見るために使用される。scan コマンドを使用してテーブルデータを取得できる。構文は次のとおりである。

scan '<table name>'

まず次のようにデータを入れる。

put 'order', '101', 'customer:name', 'John White'
put 'order', '101', 'customer:city', 'Los Angeles'
put 'order', '101', 'sales:product', 'Chairs'
put 'order', '101', 'sales:amount', '400.00'

次の例では、scan コマンドを使用してテーブルからデータを照会している。

hbase(main):019:0> scan 'order'
ROW                               COLUMN+CELL
 101                              column=customer:city, timestamp=1686912065208, value=Los Angeles
 101                              column=customer:name, timestamp=1686912059341, value=John White
 101                              column=sales:amount, timestamp=1686912074891, value=400.00
 101                              column=sales:product, timestamp=1686912070718, value=Chairs
1 row(s)
Took 0.2649 seconds

count - データ数照会

count コマンドを使用して、テーブルの行数を数えることができる。構文は次のとおりである。

count ‘<table name>'

hbase(main):020:0> count 'order'
1 row(s)
Took 0.2992 seconds
=> 1

truncate - すべて削除

truncate コマンドは、テーブルを無効化、削除、再作成する。truncate の構文は次のとおりである。

truncate ‘<table name>'

次は truncate コマンドの例である。ここでは order テーブルを削除して再作成した。

hbase(main):021:0> truncate 'order'
Truncating 'order' table (it may take a while):
Disabling table...
Truncating table...
Took 5.6828 seconds

truncate でテーブルデータを削除した後、scan コマンドを使用して確認する。テーブルに行がないことを確認できる。

hbase(main):023:0> scan 'order'
ROW                               COLUMN+CELL
0 row(s)
Took 1.6790 seconds

HBase セキュリティコマンド(Security tools) - grant, revoke, user_permission

kc@example.com (kc kim) — Sun, 18 Jun 2023 16:13:38 +0900

Security tools

HBase では、ユーザーに権限を付与したり取り消したりできる。セキュリティ目的の3つのコマンドがある。

grant
revoke
user_permission

grant - 権限付与

grant コマンドは、ユーザーにテーブルに対する読み取り、書き込み、実行、管理などの特定権限を付与する。権限付与コマンドの構文は次のとおりである。

grant '<user>' '<permissions>' ['<table>' ['<column family>' ['<column; qualifier>']]

RWXCA を使用してユーザーに権限を付与できる。

R: READ、読み取り権限
W: WRITE、書き込み権限
X: EXEC、実行権限
C: CREATE、作成権限
A: ADMIN、管理者権限

grant 'devkuma', 'RWXCA'

grant 'devkuma', 'RW' 't1', 'cf1', 'qualifier1'

revoke - 権限削除

ユーザーのアクセス権限を削除する。

revoke <user> <permissions> [<table> [<column family> [<column; qualifier>]]

revoke 'devkuma', 't1', 'cf1', 'qualifier1'

user_permission - 特定テーブルに対する権限照会

user_permission コマンドは、特定テーブルに対するすべての権限を照会するために使用される。構文は次のとおりである。

user_permission '<table name>'

特定テーブルに存在するすべての権限を表示する。

user_permission 't1'

HBase 圧縮、コンパクション、およびデータブロックエンコーディング

kc@example.com (kc kim) — Thu, 22 Jun 2023 19:13:23 +0900

圧縮とコンパクション

HBase RegionServer に保存される Region には、Column Family ごとに HStore があり、HStore はその CF の MemStore と HFile で構成される。

MemStore はメモリ上の Column Family データであり、HFile はローカルディスク、つまり HDFS に保存される Column Family データである。このような階層構造になっている理由は、HBase のテーブル構造上、データを Row key でソートする必要があり、ディスクへ直接書き込むのではなく、まずメモリ上でソートする必要があるためである。

HBase で put や update などの書き込み処理が行われると、データはまず WAL (Write Ahead Log) に記録され、その後 MemStore に書き込まれる。scan などの読み取り処理では、まず MemStore を確認し、次に HFile から要求された内容を検索する。

書き込みが繰り返されて MemStore のデータサイズが設定されたしきい値を超えると、MemStore のデータは HFile として保存される。多くの HFile で構成された Region では、HFile が増えるにつれてコンパクションが発生し、複数の HFile がより大きな HFile にマージされる。その結果、多数の小さな HFile は、少数の大きな HFile に整理される。この処理をコンパクションと呼ぶ。

HBase のコンパクションは、Minor Compaction と Major Compaction として実行される。

Minor Compaction

Minor compaction は、最近作成された複数の小さなファイルを、設定されたより大きな HFile サイズへマージする処理である。
データが挿入されると、小さな HFile が多数作成される。ファイル数が多すぎると性能が低下する可能性があるため、HBase は複数の HFile を少数の大きな HFile に作り直し、HFile 数を自動的に管理する。
HFile に保存されたデータはソートされているため、マージソートを使って高速にマージできる。

Major Compaction

Major compaction は、特定 Region 内の Column Family に属するすべての HFile を集め、Column ごとに 1 つの HFile を作成する。デフォルトでは 7 日に 1 回実行される。
この処理中に不要な Cell や期限切れの Cell が削除され、全体的な読み取り性能が改善される。Tombstone Marker が付いたデータも、この時点で最終的に削除される。
この作業が実行されると、大量のファイル読み書きが発生するため、ディスク I/O とネットワークトラフィックが増加する可能性がある。
自動実行をスケジュールできるため、週末や夜間に実行するように設定し、急激な I/O 増加がサービスに与える影響を最小化できる。

コンパクション設定

Minor compaction では、コンパクション対象となる HFile 数を次の設定で指定する。

hbase.hstore.compaction.min
- Minor compaction の最小 HFile 数を設定する。
- デフォルトは 3 で、2 以上に設定する必要がある。
- 値が大きすぎると Minor compaction が遅延し、後でまとめて処理される際に負荷が発生する可能性がある。
hbase.hstore.compaction.max
- Minor compaction の最大 HFile 数を設定する。

次の設定では、コンパクション対象となる HFile サイズを指定する。

hbase.hstore.compaction.min.size: この値より小さい HFile は、ExploringCompactionPolicy によって Minor compaction を検索するとき常に含まれる。この値は hbase.hstore.compaction.ratio と併用され、コンパクション対象の HFile を選択するために使われる。
hbase.hstore.compaction.max.size: このサイズより大きい HFile は Minor compaction から除外される。Minor compaction が頻繁に発生しても効果が小さい場合、この値を小さくして大きなファイルを Minor compaction から除外できる。デフォルト: 9223372036854775807, LONG.MAX_VALUE, bytes。

その他の設定:

hbase.hregion.majorcompaction
- HBase では、1 つの Region に複数の StoreFile が存在することがある。性能改善のため、定期的にこれらのファイルを集め、より大きな 1 つのファイルにまとめる。この処理では CPU 使用量とディスク I/O が大きく、応答時間が低下する場合がある。そのため、応答時間が重要な場合は、ピーク時間を避けて Major compaction を手動実行する方がよい。
- デフォルトは 86,400,000 ms である。この値を 0 に変更すると、定期的な Major Compaction は実行されない。
hbase.hregion.majorcompaction.jitter
- このプロパティのデフォルトは 0.2、つまり 20% である。保存された各ファイルで Major compaction が実行されるタイミングを分散させる。
- これがない場合、Major compaction は 24 時間ごとに同時実行される。

HBase 圧縮およびデータブロックエンコーディング

このセクションで言及する codec は、データブロックまたは row key のエンコードとデコードのためのものである。レプリケーション codec の詳細については、cluster.replication.preserving.tags を参照する。

HBase は、ColumnFamily に対して有効化できる複数の圧縮アルゴリズムをサポートしている。データブロックエンコーディングは、ソート済み row key や対象テーブルのスキーマなど、HBase の基盤設計とパターンを利用して、key 内の情報重複を抑える。Compressor は Cell 内の大きな不透明バイト配列のサイズを削減し、未圧縮データに必要な保存領域を大幅に削減できる。

Compressor とデータブロックエンコーディングは、同じ ColumnFamily で併用できる。

変更はコンパクション中に適用される

ColumnFamily の圧縮またはエンコーディングを変更した場合、その変更はコンパクション中に適用される。

一部の codec は、GZip 圧縮のように Java に組み込まれた機能を使用する。他の codec はネイティブライブラリに依存する。ネイティブライブラリは、HBase ライブラリディレクトリにインストールされた codec 依存関係として提供できるほか、Hadoop codec を使う場合は Hadoop の一部として提供される。Hadoop codec には通常ネイティブコードコンポーネントがあるため、HBase で Hadoop ネイティブライブラリを使用するには、Hadoop native binary support installation instructions に従う。

このセクションでは、HBase で一般的に使用され、テストされている codec について説明する。

どの codec を使用する場合でも、その codec が正しくインストールされ、クラスタ内のすべてのノードで利用可能であることをテストする必要がある。新しくデプロイされたノードで codec の利用可否を確認するには、追加の運用手順が必要になる場合がある。指定した codec が正しくインストールされていることを確認するには、compression.test ユーティリティを使用できる。

HBase で compressor を使用する設定については compressor.install を参照する。ColumnFamily で compressor を有効にする方法については changing.compression を参照する。ColumnFamily でデータブロックエンコーディングを有効にする方法については data.block.encoding.enable を参照する。

Block Compressors

NONE

この圧縮タイプ定数は圧縮なしを選択し、デフォルトである。

BROTLI

Brotli は汎用の可逆圧縮アルゴリズムである。LZ77 の現代的な変種、Huffman coding、二次コンテキストモデリングを組み合わせ、現在利用できる最良の汎用圧縮方式に匹敵する圧縮率を提供する。速度は GZ と同程度だが、より高密度に圧縮できる。

BZIP2

Bzip2 は Burrows-Wheeler block-sorting text compression algorithm と Huffman coding を使用してファイルを圧縮する。通常、LZ のような辞書ベース圧縮より圧縮率はかなり良いが、圧縮と展開はいずれも他の選択肢より遅い場合がある。

GZ(GZIP)

圧縮率を重視する。
gzip は、LZ77 と Huffman coding の組み合わせである DEFLATE アルゴリズムに基づいている。このアルゴリズムは Java ランタイム環境で普遍的に利用できるため、最小公分母として使いやすい選択肢である。ただし、Zstandard などの新しいアルゴリズムと比べるとかなり遅い。

LZ4

圧縮/展開速度を重視する。
LZ4 は、圧縮と展開速度を重視した可逆データ圧縮アルゴリズムである。Brotli、DEFLATE、Zstandard と同じく LZ77 系の圧縮アルゴリズムに属する。マイクロベンチマークでは、LZ4 はその系列の中で圧縮と展開の両方が最も高速であり、一般的に推奨される。

LZMA

LZMA は LZ77 にやや似た辞書圧縮方式である。計算コストの高い予測モデルと可変サイズの圧縮辞書により非常に高い圧縮率を実現しながら、一般的に使われる他の圧縮アルゴリズムと同程度の展開速度を維持する。典型的な圧縮率では LZMA は他のすべての選択肢を上回るが、compressor としては非常に遅く、特に高い圧縮レベルで動作するように設定した場合は遅くなることがある。

LZO

圧縮/展開速度を重視し、追加ライブラリのインストールが必要である。
LZO は、展開速度を重視して実装された別の LZ 系データ圧縮アルゴリズムである。LZ4 ほど速くはないが、それに近い性能を持つ。

SNAPPY

圧縮/展開速度を重視する。
SNAPPY は LZ77 の考え方に基づくが、非常に高速な圧縮速度に最適化されており、その代わり圧縮率は妥当な水準にとどまる。LZ4 と同程度に高速だが、圧縮率はそれほど高くない。HBase は pure Java Snappy codec を提供しており、すべてのハードウェアアーキテクチャ上のすべての Java ランタイムで普遍的に利用できる選択肢として、GZ の代わりに使用できる。

ZSTD

Zstandard は、辞書マッチング段階 (LZ77) と、大きな検索ウィンドウ、および finite-state entropy と Huffman coding の両方を使用する高速なエントロピーコーディング段階を組み合わせる。圧縮速度は最速レベルと最遅レベルで 20 倍以上異なる場合があるが、展開は一貫して高速で、最速レベルと最遅レベルの差は 20% 未満である。
ZStandard は、利用可能な圧縮 codec の中で最も柔軟な選択肢である。レベル 1 では LZ4 と同程度の圧縮率を提供し、性能はわずかに低い。中間レベルでは DEFLATE と同程度の圧縮率をより良い性能で提供し、高レベルでは LZMA に似た圧縮速度で LZMA と同程度の高密度圧縮を提供しながら、展開は常に高速である。

データブロックエンコーディングタイプ

HBase は 5 種類のデータブロックエンコーディングを提供する。

NONE
Prefix
Diff
Fast Diff
Prefix Tree

None

None はエンコーディングを適用しないことを意味し、デフォルトである。

エンコーディングなしの ColumnFamily

次の表は、データブロックエンコーディングを使用しない仮想的な ColumnFamily を示している。

Key Length	Value Length	Key	Value
24	…	RowKey:Family:Qualifier0	…
24	…	RowKey:Family:Qualifier1	…
25	…	RowKey:Family:QualifierN	…
25	…	RowKey2:Family:Qualifier1	…
25	…	RowKey2:Family:Qualifier2	…
…	…	…	…

Prefix

通常、key は同じ prefix を持ち、最後の部分だけが異なることが多い。

たとえば、最初の key が RowKey:Family:Qualifier0 で、次の key が RowKey:Family:Qualifier1 であるとする。Prefix encoding は、現在の key と直前の key の間で共有される prefix の長さを格納する拡張カラムを追加する。この例で、最初の key が直前の key と完全に異なる場合、prefix length は 0 である。2 番目の key の最初の 23 文字が同じであるため、prefix length は 23 になる。

もちろん、2 つの key に共通部分がない場合、Prefix の利点はない。

Prefix encoding を適用した ColumnFamily
次は、同じデータに Prefix data encoding を適用したものである。

Key Length	Value Length	Prefix Length	Key	Value
24	…	0	RowKey:Family:Qualifier0	…
1	…	23	1	…
1	…	23	N	…
19	…	6	2:Family:Qualifier1	…
1	…	24	…	…
…	…	…	…	…

Diff

Diff encoding は Prefix encoding を拡張したものである。Key を 1 つのバイト列として扱うのではなく、各 Key Field に分割し、Key の各部分をより効率的に圧縮できるようにする。

timestamp と type という 2 つの新しいフィールドが追加される。

ColumnFamily が直前の行と同じ場合、現在の行では省略される。key length、value length、type が直前の行と同じ場合、それらのフィールドは省略される。

また、圧縮を改善するため、timestamp は完全な値として保存されず、直前の行の timestamp との差分として保存される。prefix の例で、2 つの row key があり、timestamp が完全に一致し、type も同じである場合、2 番目の行では value length や type を保存する必要がなく、2 番目の行の timestamp 値は完全な timestamp ではなく 0 になる。

write と scan の速度が遅くなるため、より多くのデータをキャッシュできるにもかかわらず、Diff encoding はデフォルトで無効になっている。

Diff encoding を適用した ColumnFamily
この表は、同じ ColumnFamily に Diff encoding を適用したものを示している。

Flags	Key Length	Value Length	Prefix Length	Key	Timestamp	Type Value
0	24	512	0	RowKey:Family:Qualifier0	1340466835163	4	…
5	-	320	23	1	0	-	…
3	-	-	23	N	120	8	…
0	25	576	6	2:Family:Qualifier1	25	4	…
5	-	3384	24	2	1124	-	…
…	…	…	…	…	…	…	…

Fast Diff

Fast Diff は Diff と同じように動作するが、より高速に実装されている。また、データ自体が直前の行と同じかどうかを追跡する 1 ビットを保存するフィールドが 1 つ追加される。同じであれば、データは再度保存されない。

key が長い場合や column が多い場合は、Fast Diff codec を使用する。

データ形式は Diff encoding とほぼ同じであるため、説明用の別画像はない。

Prefix Tree

Prefix Tree encoding は、HBase 0.96 で実験的機能として導入された。Prefix Tree encoding は、Prefix、Diff、Fast Diff encoder と同様のメモリ節約を提供しながら、エンコード速度が遅くなる代わりに、より高速なランダムアクセスを提供する。よいアイデアではあったが、ほとんど使用されず、HBase 2.0.0 で削除された。

参考資料

Appendix D: Compression and Data Block Encoding In HBase

HBase データバージョニング(Data Versioning)

kc@example.com (kc kim) — Thu, 22 Jun 2023 19:13:23 +0900

データバージョニング(Data Versioning)

HBase の特別な機能の1つとして、各セル(cell)の特定 column 値に複数のバージョンを保存できる。

各バージョンには timestamp を使用して実装されており、降順にソートされる。long integer 型として、millisecond に換算した UnixTime を使用する。

HBase は基本的にデータバージョン管理を行う。データが同じ Row key で保存されると、最新データが timestamp でバージョニングされ、降順に保存されるため、ストレージファイルから読み取るときにもっとも新しい値を先に見つける。

Timestamp は明示的に入力することも可能だが、デフォルトで HBase は各 cell の変更を3個まで保持し、基本的に scan で照会すると降順であるため最新データが照会される。

また、以下のように保存されているすべての version のデータを照会することも可能である。

get 't1', 'rowkey1', {COLUMN => 'cf1', TIMESTAMP => ts1}

timestamp 範囲を設定して、その時点の値を見ることも可能である。

get 't1', 'rowkey1', {TIMERANGE => [start_timestamp, end_timestamp]}

バージョニングは既存では自動で指定されるが、手動で指定することもできる。

自動バージョニング
- クラスター内サーバー時間が同一でない場合、バージョン差が発生する可能性がある。
- Put メソッド実行時に timestamp を設定できるが、一般的にはサーバー内の自動バージョニングを推奨する。
- 基本的に最近3個のバージョンを管理するが、Major Compaction 機能が長い周期を持つため、まだ削除されていない過去バージョンが存在することがある。
手動バージョニング
- timestamp をオーバーライドして実装可能である。

HBase VERSIONS=1 の場合でも削除すると列の以前のバージョンが表示される?

前でバージョンは基本的に最近3個のバージョンを管理するが、Major Compaction 機能が長い周期を持つため、まだ削除されていない過去バージョンが存在することがあると述べた。

これに関連して発生する問題について紹介する。

VERSIONS 適用

以下のように ColumnFamily に VERSIONS を適用する。

create 't1', {NAME => 'f1', VERSIONS => 2}

hbase(main):001:0> create 't1', {NAME => 'f1', VERSIONS => 2}
Created table t1
Took 5.9091 seconds
=> Hbase::Table - t1

次にデータを順番に登録する。

put 't1', '101', 'f1:name1', 'test1'
put 't1', '101', 'f1:name1', 'test2'
put 't1', '101', 'f1:name1', 'test2'
put 't1', '101', 'f1:name1', 'test4'

hbase(main):002:0> put 't1', '101', 'f1:name1', 'test1'
Took 0.7153 seconds
hbase(main):003:0> put 't1', '101', 'f1:name1', 'test2'
Took 0.0318 seconds
hbase(main):004:0> put 't1', '101', 'f1:name1', 'test3'
Took 0.0418 seconds
hbase(main):005:0> put 't1', '101', 'f1:name1', 'test4'
Took 0.0255 seconds

そして delete コマンドで1つずつ順番に削除しながら確認してみる。

delete 't1', '101', 'f1:name1'

hbase(main):013:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426826665, value=test4
1 row(s)
Took 0.3049 seconds
hbase(main):014:0> delete 't1', '101', 'f1:name1'
Took 0.0160 seconds
hbase(main):015:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426822568, value=test3
1 row(s)
Took 0.1760 seconds
hbase(main):016:0> delete 't1', '101', 'f1:name1'
Took 0.0605 seconds
hbase(main):017:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426817569, value=test2
1 row(s)
Took 0.0710 seconds
hbase(main):018:0> delete 't1', '101', 'f1:name1'
Took 0.0337 seconds
hbase(main):019:0> scan 't1'
ROW                                                                  COLUMN+CELL
 101                                                                 column=f1:name1, timestamp=1687426813634, value=test1
1 row(s)
Took 0.0265 seconds
hbase(main):020:0>

すると、その直前に登録したデータが順番に照会されることがわかる。

VERSIONS に関する疑問

ここでの疑問は、明らかに VERSIONS は1個だけ保存されると言われているのに、VERSIONS => 2 と指定してもそれ以上のバージョンの列が保持されているように見える点である。一見するとバグではないかと疑われる。

検索してみると、以下のように同じ疑問を持った人を見つけることができた。
Delete reveals older version of a column even when VERSIONS=1

上記質問には以下のような回答がある。

圧縮が行われるまでは以前のバージョンが実際には消えないという。圧縮は major compaction 設定を変更していない場合、またはリージョンが分割されるたびに、1日に1回実行されるべきだという。

これは Major Compaction がまだ行われていないために発生する問題である。

VERSIONS 適用の確認方法

では、VERSIONS はどう確認できるだろうか。方法は get コマンドを利用して VERSIONS => 4 のように詳細照会してみれば確認できる。

get 't1', '101', {COLUMN=>'f1:name1',VERSIONS => 4 }

hbase(main):005:0> get 't1', '101', {COLUMN=>'f1:name1', VERSIONS => 4 }
COLUMN                                                               CELL
 f1:name1                                                            timestamp=1687427184339, value=test4
 f1:name1                                                            timestamp=1687427181122, value=test2
1 row(s)
Took 0.5028 seconds
hbase(main):006:0>

すると上記のように、テーブル作成時に指定した VERSIONS => 2 どおり2件が出ることがわかる。

HBase ブルームフィルター(BloomFilter)

kc@example.com (kc kim) — Fri, 23 Jun 2023 19:01:58 +0900

BloomFilter とは?

BloomFilter は、1970年に Bloom が提案した多重ハッシュ関数マッピングのための高速検索アルゴリズムである。このアルゴリズムは、一般的に要素が集合に属するかどうかを素早く判断する必要がある状況で使用されるが、厳密に100%正確である必要はないという考えから始まっている。

詳しい理論はわかりやすく説明するブルームフィルター(Bloom Filter)データ構造ページを参照すること。

HBase BloomFilter

HBase の BloomFilter のデータは StoreFile のメタデータに保存され、一度作成されると StoreFile は変更できないため更新できない。

BloomFilter は Column family レベルの構成属性である。テーブルに BloomFilter が設定されている場合、HBase は MetaBlock と呼ばれる StoreFile を作成するときに BloomFilter 構造のデータ断片を含める。 MetaBlock および DataBlock(実際の KeyValue データ)は LRU BlockCacheMaintenance で一緒に使用される。

したがって、BloomFilter を設定すると、特定のストレージおよびメモリキャッシュのオーバーヘッドが発生する。

HBase BloomFilter の設定方法

特定の Row key を含んでいるかを探索するとき、既存のブロックインデックスに比べて不要なブロックロードを減らし、クラスター全体のスループットを改善する。

セルサイズ、セル数、データ保存方式、読み取り方式などに応じてブルームフィルターを選択する必要がある。

HBase ドキュメントによれば、ほとんどの場合 BloomFilter の使用が推奨されている。

BloomFilter には NONE(デフォルト)、ROW、ROWCOL の3つのパラメータがある。

ROW: KeyValue の行(Row)を基準に StoreFile をフィルタリングする行レベル Bloom フィルターを示す。
ROWCOL: KeyValue の行(Row) + 列(Column)に従って StoreFile をフィルタリングする列レベル Bloom フィルターを示す。

したがって、ROWCOL の空間オーバーヘッドは ROW より高い。

該当リージョンに StoreFile が多いほど BloomFilter の効果は高く、リージョンの StoreFile 数が少ないほど HBase の読み取り性能は向上する。

次のように BloomFilter コマンドを有効にするため、HBase で Column family を設定する。

create 't1',{name => 'c1', BLOOMFILTER => '<ROW または ROWCOL>'}

Cassandra

kc@example.com (kc kim) — Fri, 28 Oct 2022 01:02:00 +0900

Cassandra の概要

Cassandra(カサンドラ)は、高い拡張性と可用性を兼ね備えた OSS の分散データベース管理システムである。
Cassandra はもともと Facebook で大容量データを保存するために開発され、2008年にソースコードが公開された。その後、Facebook が Google の Bigtable をモデルにした別製品である HBase を採用した流れから、採用する企業は限定的だったが、最近では Apple や Netflix などの企業が可用性などの観点から自社の大規模システムに Cassandra を採用した事例もあり、再び注目されている。

Cassandra はオープンソースプロジェクトであるため、無料でソースコード取得やプロダクション利用などが可能だが、テスト済みでサポートを受けられる DataStax 社による商用製品版も存在する。

2021年7月にメジャーリリースである 4.0.0 がリリースされた。

この主要リリースでは、以下のように機能が進化した。

Java 11 および一時レプリケーションへの実験的サポートを追加
メトリクスおよび YAML 構成情報を公開する Virtual Tables 機能を追加
コンプライアンスおよびデバッグに有用な監査ログ機能を追加
ライブトラフィックのキャプチャと再生のための Full Query Logging(FQL) 機能を追加
ノード間メッセージプロトコルを最適化
クラスターノード間のデータ交換に使用されるストリーミングを改善

Cassandra の主な特徴

Cassandra の主な特徴は次のとおりである。

マスターレス方式

データベースのクラスターアーキテクチャとしては「マスタースレーブ方式」が多いが、Cassandra は「マスターレス方式」になっている。
この方法では各ノードが等価であり、ノードを統括するマスターは存在しない。したがって、単一障害点が存在しない。また、レプリケーション設定により、各ノードに登録されたデータは自動的に他のノードへ伝播されるため、高い可用性を実現できる。

スキーマ定義がある

MongoDB のようなドキュメント DB や Redis のような Key-Value ストアとは異なり、Cassandra にはスキーマ定義がある。これにより、アプリケーションの開発や運用時に、開発者や運用者がデータ内容を把握しやすくなる。また、Cassandra は RDB と異なりスキーマに完全には依存せず、1つの列に複数の値を挿入するなど、ある程度自由なテーブル構成ができる。

性能が線形にスケール

Cassandra はノードを追加して処理を拡張できる。
Cassandra は公式に性能が線形にスケールすると主張しており、Netflix が実施したベンチマークがこれを裏付けている。
Apple の iCloud など大規模システムで Cassandra が採用されている理由の一端には、このようなスケール性能があると考えられる。

SQL に似たクエリが使用可能(CQL)

Cassandra では、CQL(Cassandra Query Language)という SQL のようなクエリで操作できる。 SELECT や UPDATE、DELETE など基本的なクエリは SQL とほぼ同じように実行できる。GROUP BY はバージョン 3.4.3 から実装され、サポートされている。しかし、JOIN のような集計は実装されていない。
また、関数や ORDER BY などのソートにも制限があるため、注意が必要である。

Cassandra のライセンス

Cassandra のライセンスは「Apache License version 2」に従って公開されており、営利、非営利を問わず誰でも自由かつ無料で利用、変更、再配布できる。

Cassandra の運用環境

Cassandra は Java アプリケーションである。

Oracle Java Standard Edition 8 または OpenJDK 8 の最新バージョンが必要である。Java 11 はまだ実験的サポートであり、プロダクション環境での使用は推奨されない。
cqlsh を使用するには Python 3.6 以上の最新バージョンが必要である。

Cassandra ダウンロード

http://cassandra.apache.org/download/