はじめてのActian Zen「NoSQL？それともRDB？」編

   

「はじめてのActian Zen」シリーズ・第3回目では、Actian Zenはリレーショナルデータベース（以下RDB）もしくはNoSQL データベースのどちらに分類されるのか？という内容を紹介していきます。ですが、その前に。「NoSQL」という言葉の意味を理解することが大切です。

   

＜はじめてのActian Zenシリーズの一覧＞

１）「４つの”S”」編
２）「Pythonからのデータアクセス」編
３）「NoSQL？それともRDB？」編（←当ページ）
４）「データヒストリアン」編

   

＊目次＊

1. NoSQLとは？
2. NoSQLデータベースのメリットとデメリット
3. Actian ZenはNoSQLデータベースのひとつ
4. 限りなくRDBに近いActian Zen
5. まとめ「結局のところ、NoSQL？それともRDB？」

 

NoSQLとは？

「NoSQL」という言葉は「Not only SQL」を略したものと言われており、今では大変メジャーなものになりました。しかし、その意味を正しく理解できている人は、まだまだ少ないのではないでしょうか。「NoSQL」はRDB以外のデータベースという括りで理解されることが多いようですが、実際にはその他にも様々な意味を持ちます。

 

例えば、データベース製品のことを意味していたり、SQLではないインターフェイス（データへのアクセス方法）のことを意味していたりします。ですので「NoSQL」という言葉を使うときは、NoSQLデータベースやNoSQLインターフェイス（NoSQL API）またはNoSQLアクセスというように、その「NoSQL」が何を意味しているのかを明確にすることが望ましいです。さらに、NoSQLデータベースには複数の種類があり、それぞれ仕様が異なるデータモデルをベースとしています。

 

NoSQLデータベースの１つがキーバリューストア（以下KVS）です。キーと値を組み合わせた単純な構造からなるデータベースのことで、キーに対して１つの値をもつ「キーバリュー」と、複数の列をもつ「ワイドカラム」の２つのデータモデルに分類できます。

 

KVS以外の主要なデータベースには、ドキュメント指向型データベース（以下「ドキュメントDB」）とグラフ指向型データベース（以下「グラフDB」）があり、他には時系列データをもつデータベース（以下「時系列DB」）やオブジェクトを格納することに特化したデータベース（以下「オブジェクト指向DB」）がNoSQLデータベースとして挙げられます。以下の分類表で、それぞれの種別の特徴を見ていきましょう。

 

【NoSQLデータベースの分類表】

データベースの種類	データモデル	特徴
KVS	キーバリュー	キーに対して１つの値をもつ。	（KVS共通）スケールアウト（＝サーバーの「台数を増やす」ことによる容量拡張）して処理を分散することで、ビックデータに対するCRUDに短い時間で応答できる。そのためウェブやIoTでの使用に特に適している。
	ワイドカラム	キーに対して複数の列をもつ。
ドキュメントDB	ドキュメント	JSONやXMLといった階層構造をもつドキュメント形式のデータを格納して、高度な検索を行うことができる。（この点がKVSとの大きな違いになる。）スキーマレスであり、スクリプト言語で扱いやすいため、開発の高速化が期待できる。
グラフDB	グラフ	RDB以上に複雑なデータ（SNSの人間関係のような複数のモノとモノのつながりを表すデータ）を格納できるため、つながりを辿っていくための結合が多くなるようなクエリでも高速に実行できる。ただし、スケールアウトはRDB以上に困難になる。
時系列DB	タイムスタンプ	センサー等から出力された大量のデータ、サーバーのログデータなどを時刻情報（タイムスタンプ）と共に格納することを目的としている。データヒストリアン システムで利用されることが多い。（データヒストリアンの詳細はこちらの記事へどうぞ。）
オブジェクト指向DB	オブジェクト指向	オブジェクト指向プログラミング言語で定義したオブジェクトをそのままの形で格納でき、さらに変換することなく他のプログラム上で再利用できる。

 

いかがでしょうか。ひとことに「NoSQLデータベース」といってもデータモデル間で仕様や特徴に違いがあることがお分かりいただけるかと思います。NoSQLデータベースの採用を検討する際は、システム要件に適したデータモデルはどれに該当するのかを事前に確認することが重要です。

NoSQLデータベースのメリットとデメリット

NoSQLデータベースは、RDBでは対応できない問題を解決するために誕生しましたが、RDBにはないデメリットもあります。データベースの選択を誤らないようにするためにも、メリットとデメリットを十分に理解する必要があります。RDBと比較しながら、主にKVSとドキュメントDBに共通するメリットとデメリットを挙げていきます。

メリットその１）スケールアウトによって、データ量や負荷の増加に対応できる

RDBはACID特性 (※1) に準拠した厳格なトランザクション処理を行うので、容量拡張のためにはスケールアップ（＝CPUやメモリの増強、ストレージの追加など、単一サーバーの「性能を上げる」ことによる容量拡張）を選択することが望ましいです。ACIDを保ちながら、複数のサーバーに対して処理を実行することは困難であるためです。

 

(※1) Atomicity (原子性)、Consistency (一貫性)、Isolation (独立性)、Durability (永続性) の頭文字をとったもの

 

NoSQLデータベースはRDBほどのデータ整合性は保証しておらず（＝最終的には整合性が取れる状態になる「結果整合性」を主に採用しています）、分散しやすいデータ構造になっています。スケールアウトが容易に行えますので、データ量の増加やデータベースへの負荷分散にも対応しやすくなります。（RDBにもスケールアウト用のソフトウェアはありますが、高価なものが多いです。）

メリットその２）スケールアウトによって、コストダウンできる

ビッグデータに対してリアルタイムで処理する場合、NoSQLデータベースはRDBのように高価なストレージで大容量を確保する必要は無く、複数台のサーバーに安価なストレージを用意すれば事足ります。

 

また、ビッグデータに備えて、システム稼働時から大容量のストレージや複数のサーバーを用意する必要はなく、データ量やデータベースへの負荷の増加に応じて、適宜サーバーの台数を増やすなどスケールアウトを行えばよいので、初期コストが抑えられます。

メリットその３）スキーマレスであるため、様々な種類のデータを柔軟に格納できる

RDBは表形式であり、列の属性は完全に固定です。インターフェイス先のデータ仕様が更新されると、その都度スキーマの定義を変更しなければなりませんが、その場合、システムに大きな負荷がかかってしまいます。

 

反対に、NoSQLデータベースの多くはスキーマレスであり、受け取ったデータを（それがBLOBやCLOB (※2) であっても）そのままの形で格納できます。インターフェイス先のデータ仕様の更新にも影響を受けません。事前のスキーマ定義が不要となることで、開発速度を高めることもできるようになります。

 

(※2) BLOB：バイナリデータを格納できるデータ型のこと、 CLOB：数GBの巨大な文字列を格納できるデータ型のこと

 

最近では、RDBもJSONといった構造体をもつデータを格納することは可能になってきましたが、制約が多くNoSQLデータベース（ドキュメントDB）ほどの柔軟性や検索スピードはありません。

 

 

続いてデメリットです。

デメリットその１）トランザクション機能がなく、完全な整合性を保証できない

上記メリットその１とはトレードオフの関係性にあります。このデメリットがあるため、NoSQLデータベースは、容易なスケールアウトが可能となっています。何事にも表と裏、光と闇があるということの良い例です。

 

トランザクション機能は複数の処理をまとめて行い、１つでも処理が完了しない場合は、他の全ての処理が無かったことになるというものです。例えば（よく紹介される例ですが）「銀行口座への振込」という処理では・・・

　１）A銀行の口座からB銀行にある金額が振り込まれる

　２）A銀行の口座の残高が更新される

　３）B銀行の口座の残高が更新される

という流れになりますが、システム障害によって、３）でB銀行の口座の残高が更新されなかった場合、すべての処理が無効となります。

 

トランザクション機能が搭載されていないNoSQLデータベースで、上記のようなシステム障害が発生した場合、口座間の残高に矛盾が生じてしまうため、整合性を保つことができなくなるというわけです。

デメリットその２）製品毎に仕様が大きく異なるため、導入時の学習コストが高くなる

RDBのいずれか１つの製品を熟知し、SQLを習得すれば、他のRDB製品も比較的楽に取り扱うことができるようになるでしょう。新しいRDB技術者の確保も容易になります。

 

NoSQLデータベースは、製品によってAPIやクエリが大きく異なるため、培ってきたスキルを他のNoSQLデータベースで活かすことが難しくなります。最近ではSQLによく似たクエリを搭載したNoSQLデータベースが出始めてきましたが、やはりRDBと比較すると、初期の学習コストは高くなってしまいます。

デメリットその３）スキーマレスであるため、間違ったデータ型を挿入できてしまう

上記デメリットその１）と同様に、上記メリットその３とトレードオフの関係性にあります。例えば、インターフェイス先からは数値型を受け取るという前提で開発されているとします。スキーマレスの場合、論理的には文字型や日付時刻型のデータでも受け取ることが可能になってしまうため、アプリケーション側でデータ型の不一致によるエラーが発生する可能性があります。

 

NoSQLデータベースはオンラインでのリアルタイム処理で使用されることに向いていますが、スキーマレスであるがゆえに、何らかのオペレーションで間違ったデータが入力されてもエラーなく挿入できてしまうというリスクがあります。（ただし、最近ではNoSQLデータベースにバリデーション機能が搭載されているケースも増えてきています。）

 

Actian ZenはNoSQLデータベースのひとつ

Actian Zenは、マネジメントシステムに索引順次アクセス方式 (以下ISAM)を採用しており、このISAMがKVSの起源と言われているため、NoSQLデータベースに分類できそうですが、実際は「NoSQLデータベースの原型」と表現するのが適しています。さて、一体どういうことでしょうか？

 

「はじめてのActian Zenシリーズ１ 「４つの”S”」編」で紹介したように、Actian Zenは、1982年に米国SoftCraft社がBtrieveとしてリリースした、40年近い歴史をもつ伝統あるデータベースです。

 

そもそも、「NoSQL」という言葉が生まれ広まったのは、2006年にGoogle社によって「BigTable」というKVS（ワイドカラム）をベースとしたデータベースがリリースされ、続いて2007年にAmazon社によって「Dynamo」というKVS（キーバリュー）をベースとしたデータベースがリリースされた後、2009年にサンフランシスコで「NoSQL Meetup」というイベントが開催されたことがきっかけと言われています。

 

つまり、「NoSQL」が誕生したずっと以前から「Actian Zen」は存在していました。よって「NoSQLデータベースの原型」と言えるのではないでしょうか。

 

ではここで、Actian Zenが「NoSQLデータベースの原型」であることをより理解いただけるように、データモデルについて簡単に説明していきます。まずは、以下の２つのデータモデル図をご覧ください。KVS（ワイドカラム）とActian Zenの共通点と相違点を確認してみましょう。

 

 

 

Actian ZenはISAMをベースとしていますので、キーをもつ「インデックスページ」とバリューをもつ「データページ」に分かれており、ページ番号とアドレスでキーとバリューがリンクされています。バリューにはデータ型に縛られることなく、テキストデータや、画像・音声・動画などのバイナリデータまで格納できます。

 

また、アプリ側でバリュー内の値を区切るような範囲指定をすることで、複数の列を持ったかのように扱うことができます。これらの図から分かるように、データモデルはKVS（ワイドカラム）とよく似ており、Actian Zenはまさに「NoSQLデータベースの原型」なのです。

 

ところが、データベースのランキングサイト「DB-Engines Ranking」では、Actian Zenが「Relational」（＝RDB）にカテゴライズされています。（注：旧名の「Actian PSQL」としてランキングしています。）つまりは、データベースの世界では、Actian ZenはNoSQLデータベースではなく、RDBだと認識されているのです。

 

その理由は恐らくですが、Actian ZenがACIDに準拠したトランザクション処理やANSI SQLインターフェイスを採用していることにありそうです。

 

限りなくRDBに近いActian Zen

RDBの特徴のひとつに、SQLを用いて、ACID特性に準拠したトランザクション処理を行うことが挙げられますが、この特徴をActian Zenは持っています。ACIDのうち、Atomicity (原子性)とConsistency (一貫性)によってデータ間の整合性が確保されます。その整合性を諦めることでスケールアウトを容易にしているのがNoSQLデータベースの最大の特徴ですが、Actian Zenはスケールアウトではなく、整合性の確保を選択しました。

 

さらに、スキーマレスのデータベースでありながら、構造化されたデータであればスキーマを定義することもできます。スキーマ定義により、NoSQLインターフェイスだけでなく、SQLインターフェイスを使用することが可能です。SQLによるデータアクセスによって、Actian ZenはRDBと何ら変わりないデータベースとして扱えるようになるのです。

 

 

まとめ「結局のところ、NoSQL？それともRDB？」

結論、Actian Zenは「キーとバリューをもつスキーマレスのNoSQLデータベースであり、トランザクション機能やANSI SQLインターフェイスといったRDBの特徴を兼ね備えた、まさにマルチモデルのデータベース」と言えます。

 

現在では、あらゆるデータベースが、NoSQLデータベース・RDB・DWH・Hadoopそれぞれの持つ特徴を兼ね備えようと進化を続けています。NoSQLデータベースの多くが、これまでに説明したメリットやデメリットに該当しない場合も増えてきています。ですが、データベースの基礎となるアーキテクチャはどれだけ進化しようとも変わりありません。

 

そのアーキテクチャがそれぞれのデータベースの特徴となるのです。繰り返しになりますが、それぞれの特徴をしっかりと理解した上で、データベースを選別する必要があります。そこで、これまでに取り上げてきたActian Zenの特徴をまとめてみましょう。

 

特徴1）KVSの基になったISAMを採用し、キーを持つインデックスページとレコードを持つデータページに分かれている。（特定のレコードに対してダイレクトに高速なアクセスが可能）

 

特徴2）独自のAPIをもちながら、ANSI SQLも使用できるデュアルインターフェイスを搭載している。（速度が重視される書き込みには NoSQL、複雑な検索には SQLといった使い分けが可能）

 

特徴3）スキーマレスでありながら、ACID特性に準拠したトランザクション機能を搭載している。（そのためスケールアウトすることには向かないが、データの整合性は確実に保証）

 

ひとつひとつの特徴を個別に見ると、他のデータベースと大差ないように見えますが、上記以外にも様々な特徴を持っているデータベースであり、その点がActian Zenの最大の特徴とも言えます。他の特徴や製品の詳細については、以下のページを参照いただければ幸いです。

 

– Actian Zenの製品詳細について
▼ https://www.agtech.co.jp/actian/product/

 

また、実際に製品を試してみたいという方のために評価版を用意しています。

 

– Actian Zen v15評価版について
▼ https://www.agtech.co.jp/actian/zen/v15/trial/

 

 

長くなりましたが、ここまで読み進めてくださりありがとうございます。ここで最後にもうひとつだけ・・・。NoSQLデータベースのデメリットとして「導入時の学習コストが高くなる」ことを挙げましたが、Actian Zenについても同様で、独自のAPI「Btrieve API」の使用方法をマスターする際には、それなりの学習コストが必要なります。

 

ですが！その点をカバーするべく、以下のようなトレーニングや技術情報を提供していますので、是非ご活用ください。

１）Actian Zen オンライントレーニング

Cisco Webex を使用したオンライン上でのトレーニングを定期開催しております。Actian Zen を初めてお使いになる方向けの内容となります。どなたでも無料で参加いただけます。

 

-トレーニングの参加申し込み
▼ https://www.agtech.co.jp/actian/training/

２）新しいAPI「Btrieve 2 API」の詳細な説明

2018年に、オブジェクト指向スクリプト言語に対応した「Btrieve 2 API」が新しく追加されました。Btrieve APIに比べるとよりシンプルになっており、関数などの学習コストを大幅にカットすることができます。「Btrieve 2 API」の詳細な説明をブログ記事として公開しています。

 

– はじめてのActian Zenシリーズ2「Pythonからのデータアクセス」編
▼ https://www.agtech.co.jp/blog/2020/07/data_access_from_python/

 

– Pythonから Btrieve 2 API を利用したプログラミング手法
▼ https://www.agtech.co.jp/blog/2020/11/sample_using_btrieve2api_python/