日本ソフトウェア科学会第 34 回大会 (2017 年度) 講演論文集

ユニケージ開発手法に基づく Unix ファイルシステムとシェルを用いたデータベースの構築と操作
中村 和敬

當仲 寛哲

ユニケージ開発手法は UNIX 哲学に基づいたシステム開発手法である。企業システムの開発に 20 年の実績がある。
近年のほとんどの企業システムは RDBMS を用いて構築される。全てのデータは RDBMS に格納され、Java などにより開発されたプログラムによりデータを処理する。これに対して、ユニケージにより開発されたシステムはUnix の機能のみにより構築される。これは、ユニケージはデータベースを構築する事ができるからである。全てのデータは Unix ファイルシステムのテキストファイルに格納され、シェルコマンドによってデータを処理する。この
シェルコマンドはシェルスクリプトによって起動され、Unix パイプによって連携するものである。本稿では、ユニケージよりどのようにデータベースを構築し、データを操作するか述べ、ユニケージシステムの性能を測定し、類似の製品との比較を行なう。

Unicage is a system development method based on UNIX philosophy and has been applied on businesssystem integration for 20 years. In these days, almost all business system is based on RDBMS. All datais stored in RDBMS and processed by some programs written in programming language such like Java.
In other hands, the systems developed by Unicage is based on only Unix functions, because Unicage canbuild database system. All data is tored in text files of Unix file system and processed by shell commands
those are invoked by shell script and cooperating by Unix pipe. In this paper, the authors explain how toconstruct databese and operate the data bye Unicage, and about comparison between Unicage system and
RDBMS based system.

し、カスタマイズ無しで使用する事で最大の費用対効

1 はじめに果を上げる事ができる。

近年の企業活動、すなわち業務に、情報システムに一方で、他社と大きな差異のある業務も存在する。

よるサポートは欠かせないものとなっている。これに個々の企業の競争力の差を生み出す要因の一つは、企応えるため、さまざまなパッケージ製品やフレーム業の経営資源をどのように運用するかの違い、すなわ

ワークが開発されている。

ち業務の違いである。そのため、各企業は常に業務にあるひとつの企業の業務をみた場合、その中には他

独自の工夫を加え、他社との差別化を図ろうとする。

社との差異のほとんどない業務が存在する。たとえさらにそういった業務は、市場環境の変化に応じて、ば、法律による規定のある財務会計や労務管理などで常に変化し続けることが求められる。

ある。こういった業務をサポートするシステムには、したがって、そういった個々の企業の競争力の差をパッケージ製品が最適である。パッケージ製品を導入

生み出す業務をサポートするシステムは、パッケージ
製品ではカバーする事が難しい場合が多く、フレーム

Unicage : Database development method by Unix File
System and Schellscript
This is an unrefereed paper. Copyrights belong to
the Author(s).
Nakamura Kazutaka
Tounaka Nobuaki, 有限会社ユニバーサル・シェル・プログラミング研究所, Universal
Shell Programming Laboratory Ltd..

ワーク、ミドルウェアなどを組み合わせて、スクラッチから構築されることが多い。現代の企業システム開発においては、RDBMS†1 と Java の組み合わせが†1 Relational DataBase Management System

一般的となっている。そのため、システムを理解するめに開発されたシェルコマンドのセット、Tukubai コ

ためにはさまざまな製品の知識が必要となっている。

マンドセットを利用する。そのため Tukubai コマン

したがって、従来手法の学習コストは高いものになっドセットやシェルスクリプトの書き方が注目されるこている。

とが多いが、それ自体はユニケージの一面でしかない。ユニケージにおいて特に重要なのはシステムアー

1. 1 ユニケージ開発手法

キテクチャであり、ここからその他の規範が派生してこれに対し、ミドルウェア、 DBMS 等を全く使用いる。

せず、Unix 上でのシェルスクリプトによるテキスト処理のみによって企業システムを開発する手法が、有1. 3 本稿の内容

限会社ユニバーサル・シェル・プログラミング研究所

本稿ではユニケージ開発手法に基づく、Unix ファ(USP 研究所) の提唱するユニケージ開発手法 (以下イルシステムとシェルを用いた、データベース構築とユニケージ) [3] である。ユニケージは他にも様々な工操作の方法について概説し、類似手法との簡単な比夫にもとづき、生産性、柔軟性が高く、性能の高いシ

較を行なう。ユニケージは包括的な開発手法であり、ステムを安価に開発できる事を目指してしており、ユカバー範囲は多岐に渡る。本稿ではユニケージのシ

ニケージは主に伝票などの文字データ、数値データをステムアーキテクチャのうち、特にスタンドアロンの処理する企業システムの開発に 20 年の実績がある。

データベースシステムの構築に必要な部分にのみ焦ユニケージはその基礎を UNIX 哲学 [2] におき、点を当てて説明する。

KISS 原則の徹底、プログラムの依存関係の排除、な

まずユニケージシステムのアーキテクチャについど独自の規範を取り入れて発展した、包括的なシステて概観し、次にユニケージに特有のデータ処理の方ム開発のための規範である。これらは、 UNIX 哲学

法について見て行く。続いて、 SQL データベースとを実際の企業システム開発に適用し続けた結果、自然の比較を行なう。まず機能的な側面の違いについて述と取り入れられたものである。

べ、次にユニケージシステムの性能を測定する。これに加えてユニケージの関連研究について述べ、最後に

1. 2 ユニケージのカバー領域
その結果ユニケージは、以下のようにシステム開発の様々なフェーズをカバーするようになった。

• システムアーキテクチャ

ユニケージの利点を検討する。

Tukubai コ マ ン ド セット に は 、商 用 版 の usp
Tukubai コマンドと、オープンソースの Open usp
Tukubai とがある。商用版はオープンソース版にく– データストアポリシー

らべ高速化と、さまざまな細かい機能の追加が行なわ– ノード分散ポリシー

れている。本稿では商用版の usp Tukubai を説明、

• シェルスクリプトの書き方

性能評価に用いる。

– シェルコマンド利用ポリシー (Tukubai コ
マンドセット)• プロジェクト運営手法

2 ユニケージシステムのアーキテクチャ
本節ではユニケージシステムのアーキテクチャ(ユ– ドキュメントに対する考え方

ニケージアーキテクチャ) について見て行く。まず、– テストに対する考え方

ユニケージアーキテクチャが基礎をおく、 Unix シス• システムインテグレーション契約のポリシー

テムの要件を述べる。つづいて、ユニケージアーキテ

ユニケージでは、 Unix 系 OS のインストールさ

クチャについて説明する。

れたシステム上で、シェルスクリプトによってシステムを開発する。シェルスクリプトでは一般的な Unix
コマンドのほか、USP 研究所によりユニケージのた2. 1 Unix システム要件である。これにより、部署毎の段階的な業務システム

まずは、 Unix システムに対する要件について述べ

開発やシステム改修を容易にし、対障害性を確保してる。ユニケージシステムは現代的な Unix 系 OS のいる。しかし、本稿では簡単のため 1 ノードに閉じシステム環境に構築される。多くの場合、標準的なたスタンドアロンシステムに焦点をあてて解説する。

Unix 環境に加えて、 Tukubai コマンドがインストールされる。以下では、 Unix 標準のコマンドのほか、

2. 2 構成要素

パッケージシステムなどでインストール可能なコマン

以降の節ではユニケージアーキテクチャについて述

ドと、Tukubai コマンドセットのコマンドを総称しべる。ユニケージシステムの構成要素は以下の 3 つて、単にコマンドと呼ぶ。

である。

2. 1. 1 コマンドとその開発指針

2. 2. 1 データファイルツリー (ファイル)

ユニケージシステムで用いられるコマンドは Unix

第一が処理対象データの格納されたファイルツリー

哲学に基づく、単機能のコマンドである。システム開である。ユニケージシステムの内部データは UTF-8

発に伴い必要に応じてコマンドを開発する事もある

エンコードのテキストでファイルに格納され、基本的が、その場合でも Unix 哲学に基づいて開発する。そに行指向、スペース区切りのテーブル形式である。入のため、ほぼ全ての場合で業務に関するアルゴリズム

力データ、出力データはその限りではない。

は含むコマンドが開発されることはない。コマンドは

通常、一つのテーブルは一つのファイルに格納さ純粋なデータ処理、システムの入出力処理のみを行れる。特に応答性能を向上させたい場合などは、ディなう。

レクトリツリーを工夫する事で、データ格納のみな2. 1. 2 サービス、ネットワーク、設定他

らず、検索にもファイルシステムを活用する。この場

Unix 標準のサービスとしては、ユニケージシステ

合、一つのテーブルがあるディレクトリ以下のファイ

ムのスクリプトを起動するために crond が、プリミ
ティブなユーザインターフェースとして sshd を通じてのシェルがよく使われる。グラフィカルなユーザイ

ルツリーに分割して配置される。
以下ではデータの格納されたファイルもしくはファ
イルツリーを、単にファイルと呼ぶ。

ンターフェースが必要な場合には、httpd を利用して

2. 2. 2 データ処理スクリプト (スクリプト)

Web インターフェースを作成することがおおい。本

第二はデータを処理するシェルスクリプトである。

稿ではシェルユーザインターフェースとしてシェルをスクリプトは通常いくつかのファイルを読み込み、利用する。

一つのファイルを書き出す。このとき、スクリプトはネットワークに関しては、セキュアなネットワーク

自身が書き出したファイルを読み込む事はない (スクを利用する事が推奨されている。これはシステムのリプト中で作成され、スクリプトの終了とともに消セキュリティ機能をある程度省略して開発コストを去されるテンポラリファイルを除く)。これはつまり、下げることが出来るからである。本稿でも深刻なセスクリプトは状態をもたないという事である。

キュリティ上の脅威がないことを前提として解説す

データを処理するスクリプトはコマンドのみを呼びる。その他 RAM ディスクや Unix のセキュリティ

出し、他のデータを処理するスクリプトを呼び出すこ

機能、NFS などの分散ファイルシステムやその他ミとはない。これは後述するデータフローの観点から、

ドルウェアなどの利用については、個々のプロジェク

システムの構成要素の依存関係を簡潔に保つためで

トの裁量に任されている。

ある。

2. 1. 3 分散システム
ユニケージアーキテクチャは、本来的に冗長構成の分散システムとして考えられている。これはシステムのハードウェア構成を企業の組織構造に合わせるため

以下ではデータを処理するシェルスクリプトを、単にスクリプトと呼ぶ。

2. 2. 3 スケジューラスクリプト (スケジューラ)

ジューラによって決められる。最終的な出力データを

第三は、データを処理するスクリプトを予め定めら作成するスクリプトについては、必要となった時に起れた順序で起動する、シェルスクリプト、スケジュー
ラスクリプトである。
スケジューラスクリプトはデータを処理するスク
リプトの呼び出しを行ない、データの格納されたファ

動されるケースもある。
この性質により、ユニケージシステムは入力データを保存しておく事で、任意の時点でのシステムの状態を再現することができる。

イルの読み書きを行なわない (ログなどのファイルは除く)。

2. 4 システム階層

スケジューラスクリプトは通常、日毎、月毎などのある程度以上の規模のユニケージシステムには、複起動タイミング毎、および後述するシステム階層毎に数の種類の入力データと、複数の種類の出力データが作成され、crond などから呼び出されるように設定さあり、それぞれの出力データについてデータの流れが

れる。

ある。

以下ではスケジューラスクリプトを、単にスケジュー
ラと呼ぶ。

この複数のデータの流れが混乱せず、企業の各部署で分担してシステムを開発、更新できるようにするため、ユニケージシステムは 2 階層のシステム階層、52. 3 処理モデル
ユニケージシステムはファイルを通じたデータフ
ローシステムである。
ユニケージシステムは、後述する 5 段階のデータ分類にしたがってデータを処理する。入力データはま段階のデータ分類に基づき構築される。

2. 4. 1 データ基盤系
システム階層の第 1 階層はデータ基盤系である。入力データから段階を追って整理データを作成し、整理データをシステム全体に提供する。

ずファイルに格納され、これをスクリプトによって段

通常データ基盤系用に起動タイミング毎のスケ階的に処理を行ない、最終的なシステムの出力データ

ジューラが作成される。データ基盤系用のスケジューを得る。

ラは DATAMASTER などと呼ばれる。

このとき、それぞれのスクリプトは自身の書き出す
ファイルより、より出力に近いファイルを読み込むことはない。したがって、データの流れが閉路をつくる
ことはない。
また、それぞれのスクリプトは他のデータ処理スク
リプトを呼び出すことはない。これはスクリプトのL1:入力データ
データ分類の第 1 段階は入力データである。L1(レベル 1) ファイルなどと呼ばれることもある。
システムに対する入力データは、入力の単位毎にファイルに格納される。たとえば一つの売上伝票の入力は、一つの L1 ファイルに格納される。

依存関係を排除するということである。一方で、ファ入力データはユニケージシステムの外部からやって

イルは、さまざまなスクリプトから読み出されうる。

来るものであり、必ずしもテキストデータには限定さ

これは、各スクリプトの間ではファイルにより依存関れない。

係が成り立っているということである。モジュール化

L1 ファイルが存在すればこれ以降の全てのデータを行ないたいばあいは基本的に、新しいファイルを作は作成出来るので、L1 ファイルは特に厳重に保管さ成する、そのファイルを出力するスクリプトを開発れる。L1 ファイルは特に数が増えやすい傾向にあるすることによって行なう。スクリプトから呼び出されため、適当なタイミングでアーカイブするなどしてる、モジュールとなるスクリプトの開発は禁止されてファイル数を抑える。

いる。これによりユニケージはシステムの構成要素の依存関係を簡潔に保っている。
それぞれのスクリプトの起動タイミングはスケ

L1 ファイルを取得するスクリプトは、L1GET などと呼ばれることがある。

L2:確定データなど) を作成する。例えば、商品の名前、原価、販売

データ分類の第 2 段階は確定データである。L2(レ価格などの格納されたテーブル、商品マスタである。

ベル 2) ファイルなどと呼ばれることもある。

L2 ファイルは、L1 ファイルをある程度の数まとL3 ファイルの整理、更新の標準的なテクニックについては後述する。

め、必要であればテキストのテーブル形式に変換しL3 ファイルの数は必要最小限に抑えられることがたものである。たとえば、一日分の複数の売上げ伝望ましいが、一方で必要に応じて自由に新しい L3

票の L1 ファイルから、一日分の一つの売上げ伝票のファイルを作成してよい。L3 ファイルはデータベー

L2 ファイルを作成する。

スにおけるテーブルと対比されることが多いが、ユニ

L2 ファイルを作成するにあたっては、原則データ

ケージシステムはあくまでデータフローに基づきファの取捨選択などは行なわない。可能な限り全てのデー

イルを処理するシステムである。データのフローは必

タをそのままテーブル形式に変換する。

要に応じて整備される。

画像データなどテーブル形式への変換が困難なものであり、特に変換の必要性のないデータについては、

L3 ファイルを作成するスクリプトは、L3MAKEなどと呼ばれることがある。

別途ディレクトリなどを用意して格納しておく。本稿

2. 4. 2 アプリケーション系

ではこのケースについては取り上げない。

システム階層の第 2 階層はアプリケーション系で

Tukubai コマンドには、L1 ファイルを L2 ファイある。一つのシステムには複数のアプリケーションがルに変換するためのコマンドが多数用意されている。

存在する。それぞれのアプリケーションは整理データ

例えば Execl ファイルからデータをテキスト形式でを参照し、出力データを作成する。また、特に必要な読み出す rexce コマンドである。本稿ではその詳細

場合に、入力データを直接参照することもある。

には触れない。

L2 ファイルを作成するスクリプトは、L2MAKEなどと呼ばれることがある。

それぞれのアプリケーションはファイルの依存関係が発生しないように構築される。そのため、新しいア
プリケーションが必要となった場合でも影響調査など

L3:整理データは必要なく、気軽にアプリケーションを開発していく

データ分類の第 3 段階は整理データである。L3(レことが可能である。

ベル 3) ファイルなどと呼ばれることもある。

通常それぞれのアプリケーションについて、起動タ

L3 ファイルは、L2 ファイルと過去の L3 ファイル

イミング毎のスケジューラが作成される。アプリケーから作成される。参照するファイルは過去の L3 ファションのスケジューラは APPMASTER などと呼ばイルに限定されるので、データの流れが閉路をなすこ

れる。

とはない。

L5:出力データ

L3 ファイルは後述するアプリケーションの実装を

データ分類の第 5 段階は出力データである (第 4 段

しやすいように整理され、提供される。L3 ファイル階については後述)。L5(レベル 5) ファイルなどと呼はその性質により大きく 2 種類に分類できる。

ばれることもある。

1 種類目がトランザクション (トラン) である。こL5 ファイルはシステムの出力データであり、出力

れは時々刻々と蓄積される種類のデータであり、L2の単位毎に作成される。たとえばある店舗の今月の売ファイルから作成される。例えば売上げ伝票トラン

上げのリアルタイムレポートは、要求のある度に作成

であり、日毎、地域毎などに別々のファイルに格納さ

される。

れる。

L5 ファイルは通常 L3 ファイルから作成される。

2 種類目がマスタである。これはキーに紐づく各

ただしいくつかの場合、L1 ファイルや、次節で述べ種の値のテーブルであり、L2 ファイルと、過去の L3

る L4 ファイルも利用して作成されることもある。L5

ファイル (前日など) から、新しい L3 ファイル (当日ファイルは標準出力に出力されるケースもある。L1

ファイルを使用する例については後述する。

L5 ファイルは多くの場合、ユーザから要求をうけた時に作成される。大抵の場合作成された L5 ファイ

成するアプリケーションをとりあげる。特に断りのない場合、全てのファイルは日毎の営業時間外に更新される。

ルは、ユーザに送信されるなどした後は削除される。

本節では最低限のシステム構築に必要な部分のみとL5 ファイルはユニケージシステムの外部に提供すりあげる。実際のユニケージシステムに必要なログ取る物であり、必ずしもテキスト形式には限定されない。

得や分散環境での連携に必要な部分などには触れな

Tukubai コマンドには、テーブル形式のデータをい。スケジューラについては、単にスクリプトを順次様々な形式に変換するためのコマンドが多数用意され起動するものなのでその内容には触れない。スクリプている。例えばテーブル形式を Execl ファイルに書トについては抜粋にて説明し、詳細な書き方についてき出す wexce コマンドである。本稿ではその詳細には触れない。以下の例では分かりやすさのため、テーは触れない。

ブル形式の出力は桁揃えをした形で記述している。

L5 ファイルを作成するスクリプトは、L5MAKEなどと呼ばれることがある。

L4:アプリケーションデータ
データ分類の第 4 段階はアプリケーションデータ
である。L4(レベル 4) ファイルなどと呼ばれることもある。

3. 1 ディレクトリツリー
ユニケージシステムのファイルとスクリプトは以下のようなディレクトリツリーに格納される。

• DATA : データ基盤系を格納– L1 : L1 ファイルを格納 ($lv1d)

L3 ファイルから直接 L5 ファイルを作成する場合、– L2 : L2 ファイルを格納 ($lv2d)

スクリプトが複雑になったり、処理時間がかかりすぎ– L3 : L3 ファイルを格納 ($lv3d)たりする場合がある。そのような場合に、L5 ファイ– SCRIPT : データ基盤系スクリプトを格納

ル作成のリクエスト時に渡される情報なしでも出来• APP : アプリケーションを格納るところまで L3 ファイルを処理して、L4 ファイル

– REPORT : レポートアプリケーションを格納として保存しておく。例えば、L5 ファイルとしてあ∗ L4 : L4 ファイルを格納 ($lv4d)

る店舗の今月の売上げのレポートを作成する場合、前∗ SCRIPT : レポートアプリケーションの日の全店舗分の売上げレポートを作成しておく。そのスクリプトを格納上で、リクエストのあった店舗のレポートを抽出して• SHCED : スケジューラスクリプトを格納応答する。

このディレクトリツリーはユニケージアーキテク

L4 ファイルはアプリケーションのキャッシュ的なチャの 2 階層 5 段階のシステム階層、データ分類に基位置づけである。他のアプリケーションの L4 ファイ

づいたものである。データ基盤系のファイルは DATA

ルを参照してはいけない。また、適切なタイミング

ディレクトリ以下に、レポート作成アプリケーション(日毎など) で全て消去し、新しいデータを作り直す。

は、APP/REPORT ディレクトリ以下に格納される。

L4 ファイルを作成するスクリプトは、L4MAKEなどと呼ばれることがある。

これらのディレクトリのパスはスクリプト中ではシェル変数に格納され、たとえば、 DATA/L1 は lv1dなどのシェル変数で参照される。以下では各ディレク

3 ユニケージシステムの実装

トリを上記箇条書き中の $lv1d のように参照する。

本節では、本稿で性能測定に用いるユニケージシス$lv1d 〜 $lv3d の各ディレクトリ以下には、このテム (例題システム) を例にあげ、ユニケージシステシステムで取り扱う 3 種類のデータ、店舗マスタのムの実装について概説する。例題システムは小売業

ディレクトリ、 TENPO と、売上データのディレクトのための簡単なシステムであり、アプリケーションとリ、URE が作られる。また、 $lv3d 以下には、店舗

しては、ある店舗のある月の売上げのレポートを作

毎月毎売上データのディレクトリ、 URE_TEN_MON も作られる。

3. 2. 2 店舗マスタ
次に、整理データの一種、マスタの例として、店舗

3. 2 テーブルの例

マスタをみてみる。今回、店舗マスタは、店舗 ID、

本節では、システムで取り扱うデータについて、例

店舗名、電話番号から成る以下のようなテーブルでを示しながら説明する。ここで述べるのは論理的なある。

データの内容である。実際にどのような形でファイル

0001 千代田区店 0311111111に格納されるかは、次節以降で述べる。

0002

中央区店 0322222222

3. 2. 1 売上データ

0003

港区店 0333333333

まず、整理データのもう一つの種類、トランの例と0005

新宿区店 0355555555

0006

文京区店 0366666666

して、売上データをみてみる。
プリミティブな売上げデータは POS レジから出力

マスタはキーでソートされた状態で保存される。こされるデータほぼそのままのデータであり、店舗 ID、の店舗マスタの場合、店舗 ID でソートされた状態で売上時刻、商品 ID、金額、個数からなる以下のよう保存される。

なテーブルである。

店舗マスタ操作データ

0001 20170401102340 1234567890123 2280 19

多くの場合、マスタデータに対する入力データは、

0001 20170401102340 2345678901231 2040 17

マスタそれ自体ではなく、マスタに対する操作のデー

0001 20170401012340 3456789012312 2760 23

タである。例えば、店舗マスタの操作のデータは、店

0001 20170401103052 1234567890123 2280 19

舗マスタに操作と操作時刻を追加した以下のような0001 20170401013052 3456789012312 2760 23

データである。

0001 20170401103052 4567890123123 2400 20

0001 千代田区店 0311111111 削除 20170401102555

トランザクションデータは、通常キーと日付でソー0002

中央区店 0322224444 更新 20170401102326

トされた状態で保存される。この売上データの場合、

0002

中央区店 0322223333 更新 20170401102401

店舗 ID、売上時刻を連結した文字列でソートされた

0003

港区店 0333334444 更新 20170401102433

状態で保存される。店舗 ID に紐づく情報は、店舗マ

0004

台東区店 0344444444 作成 20170401102624

スタから取得することができるので、テーブルには含めないことが多い。

マスタ操作データには、レコード作成、もしくは更新の場合は、キーで指定されるレコードの新しい内容

店舗毎月毎売上げデータが格納される。レコードの削除の場合は、意味を持つ

売上げデータのようなデータは、通常ある程度加工のはキーのみである。

されて扱われる事が多い。例えば、売上げデータであマスタ操作データはキーと操作時刻でソートされれば、店舗毎月毎売上げデータのように加工されて出た状態で保存される。この店舗マスタ操作データの場

力される。

合、店舗 ID と操作時刻を連結した文字列でソートさ

月毎店舗毎売上げデータは、店舗 ID、売上月、金れた状態で保存される。

額からなる以下のようなテーブルである。

店舗毎月毎売上げレポート (出力データ)

0001 201611 3680187304

出力データは他システムや人の目に触れる形で提0001 201612 4080081360

供される。例題システムでは、店舗毎月毎売上げレ

0001 201701 4971217222

ポートが出力であり、これは、店舗 ID、店舗名、売0001 201702 3386136033

上月、売上金額からなる以下のようなデータである。

0001 201703 4760390169

0001 千代田区店 2016/11 3,068,087,304

店舗毎月毎売上データの場合も、店舗 ID、売上月

最終的に人の目に触れるものであるため、店舗 IDを連結した文字列でソートされた状態で保存される。

に対して店舗名が付加され、売上月は YYYY/MMの形式で、売上金額は商業文書の習慣に則り 3 桁毎を、シェルのワイルドカード展開で取得している。2にカンマを打っている。

行目でファイルを連結して出力している。

以降では、5 段階のデータを作るための処理について述べる。

シェルのワイルドカード展開を行なった時点で、ファイル名は店舗 ID、売上時刻でソートされるため、

cat コマンドにより連結された出力は店舗 ID、売上
3. 3 L1GET:入力データの処理

げ時刻でソートされた状態になっている。

L1 ファイルは、ユーザがターミナルや Web をインマッチするファイル数が多い場合、コマンドの引数

ターフェースを通じて作成するか、外部システムからの上限をオーバーしてしまう事がある。xargs を使用

受け渡される。これを受け取り、ディレクトリツリー

するのは、これを回避するためである。

の中に正しく配置するのが、L1GET の処理である。

L2MAKE はファイルのオープンクローズをとも

入力データは入力の単位毎にファイルに格納される。

なうため、コストのかかる処理である。L1 ファイ

入力データは様々な形式を許容する。ただし例題シルの分量が多いばあい、営業時間内であっても適宜

ステムでは簡単のため、3. 2 節で述べたテーブルと同

L2MAKE を実行する事が望ましい。

じ形式のデータを入力とする。例えば、売上げデータの L1 ファイルは以下のようになる。

3. 5 L3MAKE:整理データの処理$ cat $lv1d/URE/0001/20170401102340.923 |

整理データはトランとマスタとで異なる形でファイ

0001 20170401102340 1234567890123 2280 19

ルツリーに格納される。また、更新の方法も異なる。

0001 20170401102340 2345678901231 2040 170001 20170401012340 3456789012312 2760 23
ここでは店舗 ID のディレクトリを作成し、ファイ

以下ではそれぞれのファイルツリーの形、更新の方法について述べる。

3. 5. 1 トランザクションの整理

ル名を <YYYYMMDDHHMMSS>.<プロセス ID> のように

トランは時々刻々と蓄積される種類のデータであして、異なる入力でファイル名が重複しないようにしる。トランのデータ量は時間の経過とともに増大すている。
この例では、3 つの商品が同じタイミングで購入されたので 3 レコード同時に入力されている。

L1 ファイルは入力のタイミングで作成されるため、日毎に作成されるとは限らない。

L1GET の処理の詳細は入力インターフェース毎に異なるので、本稿ではその詳細には触れない。

る。1 ファイルあたりのデータ量が多くなり過ぎると性能面で悪影響があるので、これを抑えるため、日毎、地域毎などの単位で別々のファイルに格納される。例題システムの売上データは、例えば月毎のファ
イルに分割して格納される。2017 年 4 月のデータであれば、L3 ファイルのパスは以下のようになる。

$lv3d/URE/201704
このデータ分割の指針は、あつかうデータ量に応じ3. 4 L2MAKE:確定データの処理
L2 ファイルは L1 ファイルをテキストに変換してある程度まとめたものである。例題システムの L1 ファて変更する。

L3 ファイルの内容は 3. 2. 1 節で述べたように、ソートされて格納される。

イルは、前節で述べたように 3. 2 節で述べた形式で

3. 5. 2 トランザクションの更新あるので、テキストへの変換は必要ない。

トランに対する更新は、その性質上追記のみであ

例えば、ある日の売上げデータの L1 ファイルから

L2 ファイルを作成する処理は、以下のようになる。
echo $lv1d/URE/????/20170401??????.* |xargs cat > $lv2d/URE/20170401
1 行目で 4 月 1 日の全ての売上 L1 ファイルの名前る。当日分の L2 ファイルを前日の L3 ファイルに追記する形で、当日の L3 ファイルが作成される。
例えば、売上データの当日分の L2 ファイルから、当日分の L3 ファイルを作成する処理は以下のようになる。

up3 key=1/2 $lv3d/URE/201704 \スでも、それぞれの値について別々のファイルに保存$lv2d/URE/20170401 > $lv3d/URE/201704.new する。
mv $lv3d/URE/201704{.new,}
1 行目〜2 行目は up3 コマンドを使用して key=1/2
オプションにより、第 1 フィールドの店舗 ID と第 2

例題システムの店舗マスタは、店舗 ID をキーとするテーブルである。以下のようなキーと値を組みとする 2 つのファイルに分割される。

フィールドの売上時刻をキーとして前日分の L3 ファ• $lv3d/TENPO/ID_NAME : 店舗 ID, 店舗名

イルと当日分の L2 ファイルをマージしている。3 行• $lv3d/TENPO/ID_TEL : 店舗 ID, 電話番号

目では 2 行目で書き出されたマージした内容を、mv

例えば、 $lv3d/TENPO/ID_NAME の内容は以下のコマンドでもとのデータに上書きをしている。

とおりである。

加工データの更新

0001 千代田区店

店舗毎月毎売上げデータのように、加工されたデー

0002

中央区店

タの場合であっても、基本的な方針は同じである。

0003

港区店

例えば、売上データの当日分の L2 ファイルから、

0005

新宿区店

当日分の店舗毎月毎売上げデータの L3 ファイル、

0006

文京区店

$lv3d/URE_TEN_MON/2017 を作成する処理は以下のこういった分割されたファイルを利用する際には、ようになる。

以下の様に loopj コマンドを用いて必要な値を連結

self 1 2.1.6 4 $lv2d/URE/20170401 |して使用する。

up3 key=1/2 $lv3d/URE_TEN_MON/2017 -|$ loopj num=1 $lv3d/TENPO/ID_{NAME,TEL}

sm2 1 2 3 3 > $lv3d/URE_TEN_MON/2017.new

0001 千代田区店 0311111111

mv $lv3d/URE_TEN_MON/2017{.new,}0002

中央区店 0322222222

1 行目は self コマンドの引数により第 1 フィール

0003

港区店 0333333333

ド、第 2 フィールド、第 4 フィールドを選択してお0005

新宿区店 0355555555

り、特に第 2 フィールドについては 2.1.6 のように

0006

文京区店 0366666666

指定することで、YYYYMMDDHHMMSS 形式の時

loopj コマンドは同じキーのレコードを突合わせ

刻から YYYYMM の月部分のみを取り出している。

て、一つのテーブルを作成する。num=1 はファイルの2 行目は先ほどと同様に up3 コマンドによりマージ

先頭 1 フィールドをキーと解釈するという意味であを行なっている。3 行目は sm2 コマンドにより、第 1る。この例では値は 2 つであったが、より多くの値がフィールドから第 2 フィールドをキーとして、キーがある場合でも同様に記述して、必要な値のみからなる

同じレコードの第 3 フィールドの値を合計している。

テーブルを作成する。

これにより、3. 2. 1 節で述べたようなテーブルを作成できる。

3. 5. 4 マスタの更新
マスタに対する更新は、マスタ操作データを通じ

3. 5. 3 マスタの整理て行なう。前日分の L3 ファイルに、当日分のマスタ

多くの場合、マスタは少数のキーに対して沢山の値

操作データの L2 ファイルを重ね合わせて、当日分のが紐づけられたデータである。時には数百種類の値がL3 ファイルを作成する。

紐づけられる事もあるが、個々の処理にはその全てをある日のマスタは、その日までのマスタ操作データ用いるわけではない。また、多くのフィールドを含む全てから作成することが可能である。指定された日ま

レコードはデータ量が多く、可読性も下がる。

でのマスタ操作データについて、各キーについて最新

こういった問題を解決するため、マスタはキーと値の形式で保存する。この時、レコードはキーに基づいてソートされる。キーに複数の種類の値が紐づくケーのレコードを抽出し、削除操作のレコードを除いた物
がその日のマスタである。
しかしマスタ操作データの蓄積量が多くなると、これでは処理時間がかかり過ぎる。これを避けるため

3. 6 L4MAKE:アプリケーションデータの処理に、直前までの更新データの蓄積である、直前の L3

L4 ファイルはアプリケーション毎に作成される。

ファイルを利用して新しい L3 ファイルを作成する。

例題システムのアプリケーションは、3. 2. 2 節で述べ

例えば、店舗マスタ操作データの当日分の L2 ファ

た店舗の月毎の売上げのレポートを作成するアプリ

イルが、$lv2d/TENPO/TENPO_OP.20170401 であるとすると、当日分の L3 ファイルを作成する処理は以下

ケーションである。

L4 ファイルは特に応答時間が短いことが要求されのようになる。

るインタラクティブシステムなどにおいて、L5 ファ$ loopj num=1 $lv3d/TENPO/ID_{NAME,TEL} |イル作成のための応答時間を短縮するためのもので> up3 key=1 - $lv2d/TENPO/TENPO_OP.20170401 | ある。そのための加工の処理は大きく分けて、前処理> getlast key=1 |と分割の二種類である。

> delr 4 削除 |以下ではこの 2 つの方法について述べる。

> self 1/3 > $lv3d/TENPO/new

3. 6. 1 前処理

self 1 2 $lv3d/TENPO/new > $lv3d/TENPO/ID_NAME

L5 ファイルは L3 ファイルを加工して作られる。前self 1 3 $lv3d/TENPO/new > $lv3d/TENPO/ID_TEL 処理は、L3 ファイルを可能な限り L5 ファイルの形
rm $lv3d/TENPO/new

式に近づけておくことである。

1 行目〜5 行目までが当日分のテーブルを作成する

例題システムのアプリケーションの場合、3. 2. 2 節処理である。6 行目、7 行目ではフィールドを選択しで述べた出力データの形式に近づけることであり、こてキー、値の形式のファイルを作成して上書きしていの処理は以下のようになる。

る。8 行目では中間ファイルである当日分のテーブル

join2 key=1 $lv3d/TENPO/ID_NAME \を削除している。

$lv3d/URE_TEN_MON/2017 > $lv4d/2017

当日分のテーブルを作成する手順は以下のとおりで

1 行目〜2 行目は join2 コマンドにより、店舗毎月ある。1 行目で loopj コマンドを使用して前日分の毎売上トラン$lv3d/URE_TEN_MON/2017 に、店舗名

テーブルを作成している。2 行目で up3 コマンドを使の格納された店舗マスタ、$lv3d/TENPO/ID_NAME を用して key=1 オプションにより、第 1 フィールドを突き合わせている。key=1 はトランの第 1 フィールドキーとして前日分のテーブルと当日分のマスタ操作

をキーと見なすという意味である。マスタのほうは、データをマージしている。このとき、ファイル間で同常に先頭から指定された数のフィールドをキーと見じキーのレコードは引数で指定した順序でマージされなす。

る。3 行目で getlast コマンドを使用して key=1 オ$lv4d/2017 の内容は以下のようになる。

プションにより、第 1 フィールドをキーとして、最後

0001 千代田区店 201611 3680187304に現れるレコードを出力している。これによりそれぞ

0001 千代田区店 201612 4080081360

れのキーの最新の操作レコード (操作の無い場合はも0001 千代田区店 201701 4971217222とのレコード) が出力される。4 行目で delr コマンド

0001 千代田区店 201702 3386136033

を使用して第 4 フィールド、操作が削除であるレコー

0001 千代田区店 201703 4760390169

ドを削除している。5 行目で self(SELect Field) コ
マンドを使用して、引数の 1/3 により、元のテーブルに必要な第 1 フィールドから第 3 フィールドまでを選択して、中間ファイルである$lv3d/TENPO/new に書き出している。

月の形式の変換と、金額へのカンマの挿入は、L5
ファイル作成時に行なう。
このように事前に加工を済ませておく事で、L5 ファ
イルの要求を受けた時の処理量を減らしておく。

3. 6. 2 分割
前処理でみたように、L4 ファイルによる応答高速化の基本戦略は、全ての回答をあらかじめ作成しておくというものである。そのため、全体としての L4

1 行目では selr コマンドを利用して、店舗 ID0001

ファイルのサイズが大きなものになることがある。

のファイルから第 3 フィールドが 2017/04 であるレ

分割は、要求時に与えられるパラメータで L4 ファ

コードを抽出している。実際には店舗 ID や月はシェ

イルをあらかじめ分割しておく事である。この処理

ル変数に格納されるなどして与えられるので、適は、前節の処理結果を利用して記述すると以下の様に当な方法で加工してこの処理を実行する。2 行目はなる。

dayslash コマンドにより日付の加工を行なっている。

keycut $lv4d/%1.2017 $lv4d/2017

引数で第 3 フィールドを指定し、 YYYYMM 形式の1 行目で、keycut コマンドを利用して、ファイル

日付を YYYY/MM 形式に加工している。3 行目は$lv4d/2017 を店舗毎、月毎のファイルに分割していcomma コマンドにより、商業文書の慣習に従った金額る。例えば、 $lv4d/0001.2017 には、店舗 ID 0001の加工を行なっている。引数で売上金額のはいった第の、2017 年のレコードのみが格納される。実際のス

4 フィールドを指定して、3 桁毎にカンマを挿入してクリプトではほとんどの場合前節の処理と合わせている。

一つのパイプラインで記述される。

これにより、最終的な出力が得られる

3. 7. 1 リアルタイム処理

書き出しファイル名は、ディレクトリツリーである
こともある。例えば、$lv4d/0001/2017 のような形

例題システムのファイルは、日毎の営業時間外に更である。これはレコードの探索木をディレクトリツ

新される。一方で営業時間内に、その日の売上を加算

リーを利用して実装するテクニックである。このよしたデータを知りたいという場合もある。しかし、新うにする事で、L5 ファイルを要求された場合、店舗

しい L1 ファイルが到着する度に、L4 ファイルまで

ID で絞り込まれたデータを読み出すこととなり、応を構築しなおすのでは、処理時間がかかり過ぎる。

答時間の短縮が見込まれる。

リアルタイム処理はそのような要求があるばあい

ただし、あまり細かいファイルを大量に作成してに、もとの L4 ファイルに含まれていない L1 ファイ

も、性能の劣化が発生することがある。分割の目安とルの内容を反映して、L5 ファイルを作成する処理でしては、1 ファイルが 500MBi を越えたあたりから、ある。例えば、2017 年 4 月 2 日に、店舗 ID0001 のディスクに格納されたファイルであれば読み出し時間

月 201704 の、当日分のデータを反映したレポートをが 1 秒を越えるので、こういった分割を考える。

作成する処理は以下のようになる。

分割の方法には様々なパターンがあり得る。たとえ

そのような場合の処理は以下のようになる。

ば、店舗 ID が連番振られている場合は、店舗 ID の{下 N 桁によりファイルを分割する、等である。これ

selr 3 201704 $lv4d/0001.2017

により各ファイルのサイズが均等にならされると期待できる。

cat $lv1d/URE/0001.20170402??????.* |self 1 2.1.6 4 |3. 7 L5MAKE:出力データの処理

join2 key=1 $lv3d/TENPO/ID_NAME

前節までで作成された L4 ファイルから、最終的な} |出力である L5 ファイルを作成する。例えば、店舗

sm2 1 3 4 4 |ID0001 の月 201704 の L5 ファイルを作成する処理

dayslash yyyy/mm 3 |は以下のようになる。

comma 4selr 3 201704 $lv4d/0001.2017 |1 行目〜7 行目までグルーピングを用いているが、dayslash yyyy/mm 3 |4 行目〜6 行目、8 行目を除いた場合、前述の L5 作

comma 4

成処理と同じである。

4 行 目 〜6 行 目 は 、店 舗 ID 0001の 2017 年

4 月 2 日 分 の デ ー タ を 読 み 出 し て 、L4 デ ー タ

合に、そのファイルを作成するためのスクリプトが必$lv4d/0001.2017 と同じ形式に加工している。1 行

ず、L1GET → L2MAKE → L3MAKE → L4MAKE

目〜7 行目までグルーピングを用いているので、前日の順で起動されるという事である (L5MAKE はユーに作成された 4 月の売上げデータと当日分の売上げ

ザから要求を受けたときに実行される)。それぞれのデータが、8 行目のコマンドの入力となる。

スクリプトが段階を踏んで起動されるため、同じ一つ

8 行目では、sm2 コマンドを用いて、前日までののファイルが同時に読み書きされることはなくなる。

データに当日のデータを加算している。最後に、94. 1. 2 OS アトミック処理による排他制御の実現

行目、10 行目でデータの見た目を加工して出力してスケジューリングにより排他制御を回避出来ない場いる。

合もある。たとえば、3. 7. 1 節で述べたリアルタイム
処理を行なうようなシステムの場合である。そのよ

4 ユニケージシステムの特に留意すべき特徴

うなシステムの稼動中に作成される L1 ファイルは、

ユニケージシステムはファイルを通じたデータフ

L5 ファイルを要求される任意のタイミングで参照さ

ローシステムである。そのため、データベースに対すれる。ここで、L1 ファイルの格納されるディレクト

る読み書きを基礎におく RDBMS とは、大きく異な

リに直接データをリダイレクトした場合、作成途中のる部分も多い。本節ではそのような特に留意すべき特ファイルが参照されてしまう可能性がありうる。

徴について述べる。

このときは、 OS のアトミックな処理を利用して排他制御を実現する。Unix ファイルシステムにおい4. 1 排他制御て、同じパーティション上での rename(2) システム

RDBMS における排他制御はレコード等、データ

コールはアトミックに処理される。これはつまり、あベース上のオブジェクトに対する読み書きを制御する

るディレクトリに内での、 “mv file.new file ” とものである。

いうコマンドは、アトミックに処理されるということ

ユニケージシステムにおける排他制御は、二つのス
クリプトが同じ一つのファイルに対して同時に読み込である。この性質を利用し、ファイル単位での排他制御を行なう。

み、書き込みを行なわないようにするためのものである。これは、書き込まれている最中のファイルを読4. 2 BASE トランザクション

み込んだ場合、不完全なデータを得てしまうためでここまでからわかるように、ユニケージシステム

ある。

は、基本的に BASE トランザクションである。分散ユニケージシステムはこれに対して、スケジューシステムとして構築されたユニケージシステムがそうリングと OS アトミック処理により排他制御をあつであるのはもちろん、スタンドアロンシステムであっかう。

ても、LV1 ファイルが到達するタイミングによって、Tukubai コマンドには排他区間を作成するための一時的な不整合が発生する可能性がある。

コマンドも存在するが、捕捉のしにくいバグや、性能

排他区間を作るコマンドを使用し ACID トランザの低下を引き起こすため、可能な限り使用を回避す

クションを実装することも可能ではある。しかし前述る。このコマンドについては本稿では触れない。

のような問題があり、実装される事は稀である。

4. 1. 1 スケジューリングによる排他制御の回避
まず、ユニケージシステムではスケジューリングにより排他制御を回避する。スケジューラによってスクリプトが正しい起動順序で起動されるならば、排他制
御の必要はなくなる。
これは例えば、日次で更新されるファイルがある場

5 ユニケージシステムの性能測定
筆者らは 3 節で解説した例題システムの性能を測定した。

5. 1 測定方法

チェーン店のデータ量はイオングループのおおよその性能測定に際しては、例題システムのレポートを規模に倣った。一人当たり購入点数は 10 とした。
来客数
売上データ
規模
店舗数
人/日
レコード/日

生成する処理を行い、time コマンドを用いて処理時間を測定した。ユニケージシステムについては、L1
ファイルから L4 ファイルまでを生成する日毎の処理(日次更新処理) と、要求に応じて L5 ファイルを生成する処理 (リアルタイム処理) の時間を測定した。
実際に実行されるスクリプトは以下のとおりである。

• 日次更新処理– L2MAKE.URE : 売上データの L2MAKE– L3MAKE.URE_TEN_MON : 店舗別月別売上デー
タの L3MAKE– L4MAKE.URE_TEN_MON : 店舗別月別売上レ
ポートの L4MAKE• リアルタイム処理

小規模

10

150

15 ∗ 103

中規模

100

750

75 ∗ 104

大規模
1000
4500
45 ∗ 106
例題システムのデータ量は、小規模から中規模では50 倍、中規模から大規模では 60 倍となっている。
ユニケージシステムはとりあつかうデータ量に合わせてデータファイルの分割方法を変える。また、このケースでは大規模以上の場合特に、L1 ディレクトリのファイル数が増大するため、営業時間内に L2MAKEを実行することが望ましい。しかし、今回は比較のため、分割方法や L2MAKE 実行タイミングの調整はおこなわなかった。

– L5MAKE.URE_TEN_MON : 店舗別月別売上レ
ポートの L5MAKE(リアルタイム処理)

L5MAKE.URE_TEN_MON には、3. 7. 1 節で述べたリア

5. 2 結果と考察

ルタイム処理である。それ以外の各スクリプトの内容

測定の結果は以下のとおりである。
規模
日次更新処理 リアルタイム処理

は、3 節で解説したものとと同等である。

小規模

0.14 秒0秒

中規模

1.71 秒0.01 秒

性能評価環境は以下のとおりである。

• CPU : Intel(R) Xeon(R) W5580 @ 3.20GHz– 8 Cores

大規模103.91 秒
0.09 秒
例題システムの日時更新処理は、小規模から中規• Mem : 47 GiB

模では約 12.2 倍に、中規模から大規模では約 60.7 倍• OS : CentOS Linux release 7.2.1511 (Core)になっている。また、処理時間の大部分を L2MAKE• MySQL : Ver 14.14 Distrib 5.7.18, for Linux処理が占めていた。

(x86 64) using EditLine wrapper

中規模から大規模での処理時間の増加がデータ量– 文字コードを UTF-8 に設定したの増加に一致している。これは、店舗毎月毎売上げ– それ以外は yum コマンドによりインストー

データの L3 ファイルを更新するさいに、その日の売ルをしたままである。
ユニケージシステムのデータは全てファイルに保存

上データの L1 ファイルを全て読み込むためと思われる。

される。一方で Linux ファイルシステムは読み込ん

小規模から中規模での処理時間の増加はそれほどだファイルをメモリ上にキャッシュする。このため同ではないのは、小規模の場合はデータ処理時間そのもじファイルを読み込む処理を短い時間内に複数回実行のよりも、プロセスの起動と終了のための時間が大半すると、2 回目以降が高速になる傾向がある。今回はをしめているためであると思われる。

全て 11 回の測定を行ない、始めの 1 回を除外した測定結果の平均を取った。

応答時間についてはほぼ変化がなかった。小規模のケースで 0 秒となっているのは、time コマンドではシステムを適用する小売りチェーン店の規模を、小測定できなかったということである。これは大規模の規模、中規模、大規模と想定し、それに合わせて以

ケースであっても、L4 ファイルの 1 ファイルあたり

下の 3 通りのデータ量で測定をおこなった。大規模

のデータ量はたかだか 12 レコードであり、また、当しながら、業務システムを開発するためのシステム

日分の L1 ファイルも最大で 4.5 万レコード程度と少アーキテクチャは提供されていない。

数であったためと思われる。

6. 3 POSIX 中心主義

6 ユニケージの関連研究と定性的比較

これまでの手法は、様々な言語やミドルウェアなど

本節ではユニケージの関連研究を見て行く。そのうの製品を用いる手法が主流であった。こういった製品

ちいくつかとは、ユニケージとの定性的な比較を行

は変遷が激しいことが多く、これらの製品を利用してなう。

作成したシステムの寿命は短い。

POSIX 中心主義は、UNIX の標準規格である、
6. 1 POSIX コマンドとユニケージ

POSIX に極力のっとったシェルスクリプトを記述す

ユニケージはテキストファイルをデータベースとしることで、移植性、持続性に優れたシェルスクリプて用いる手法である。実は POSIX コマンドにもそトを記述することを目的とする [5]。POSIX の変遷、のような使い方の萌芽をみることができる。

各 Unix 系 OS の POSIX 準拠状況などを調査してまず、 Unix version 7 から登場した join(1) コいる。

マンドである。これは SQL における join と同等のユニケージもほぼ POSIX 準拠のスクリプトを記処理を行なうコマンドである。また他にも、cut(1)、述する。そのため、移植性、持続性にすぐれたシステ

paste(1) などテーブル形式のカラムを操作するコマムを開発することが出来る。

ンドや、sort(1) コマンドの-k オプションや-m オプ

6. 3. 1 クラスタ処理

ションなど、テーブル形式のファイルの基本的な操作

ユニケージはファイルを通じたデータフローシスに必要なコマンドが一通り揃っている。

テムである。そのため特段のミドルウェア等なしでこういったコマンド群に加え、 awk(1) コマンドがも、ファイルコピーによってデータベースに対する操存在するため、Tukubai コマンド無しでもユニケー

作を他のノードに伝搬することが可能である。ユニジシステムを構築することが可能である。

ケージはスケールアウトがしやすいシステムである。

USP 研究所では、ビッグデータを処理するためのア
6. 2 ファルマにおけるシステム開発と NYSOL
プロジェクトプライアンス製品として、InfiniBand を用いたクラスタ、 usp BOA を開発し発売している。

ユニケージが特に影響をうけたプロジェクトとしまた、ユニケージシステムの分散処理性能について、1970 年代に創業した関西地方を拠点とする薬局て、現在分散環境での Hadoop との比較を行なってのボランタリチェーン、ファルマにおけるシステム開いる。

発がある。同社の創業者の一人、松田康之氏は独特のシステム開発手法を編み出していた [4]†2 。

7 ユニケージの利点

これは、データを中心におき、データを処理するプ

最後に、本稿でみたユニケージの説明と性能測定か

ログラムはスクリプト言語 (RPG 言語) を用いて開発ら説明可能な、ユニケージの利点について述べる。

し、必要に応じて書き捨てるという考え方であった。
現在ファルマでの成果の一部は NYSOL プロジェ

7. 1 高い性能が得やすい

クト [1] に受け継が れ、公開されている。NYSOL

5 節でみたように、ユニケージシステムは数千億レ

プ ロ ジェク ト で は KDD(Knowledge Discovery in

コードの処理に対しても 2 分未満で処理をすること

Database) プロセスに基づき処理を組み立てる。しかが出来た。また、特に応答性能が求められるシステム†2 実際には、松田氏と同社に勤務した多くの技術者らが共同で編み出したもののようであるについても、高い性能を示した。大規模ケースのデー
タ量は日本国内有数の大規模小売りチェーン店から取ったものだが、そのような企業のデータ処理に対しても十分対応可能な性能が得られると言える。

7. 4 バグの少ないシステムを容易に開発できる
ユニケージシステムはバグが発生しにくい。シェル

また、この性能はユニケージの標準的な技法に基づのパイププログラムは状態をもたず、また、ユニケー

いて構築されたシステムによって得られたものであジアーキテクチャのスクリプトも状態を持たない。こる。ユニケージシステムは容易に高い性能を得る事がれは関数プログラミングの関数と同様の性質である。

できる。

この性質により関数プログラミングはバグの少ないシステムを容易に開発できるという利点がある。ユニ

7. 2 学習コストが低い

ケージも同様にバグの少ないシステムを容易に開発

ユニケージシステムは学習コストが低い。既存手法

できる。

は、NYSOL プロジェクトのように知識発見のためのパッケージであったり、あるいは RDBMS や NoSQL

8 おわりに製品と Java のように、複数の製品を組み合わせてシユニケージは他にも様々な工夫にもとづき、生産ステムを開発する必要があった。これに対してユニ性、柔軟性が高く、性能の高いシステムを安価に開発

ケージはユニケージアーキテクチャとシェルスクリプ

できる事を指向している。今後もユニケージと他の手トの知識のみで、業務システム全体を理解し構築する法との定性的、定量的な比較を様々な側面から行いたことが可能である。

い。また、コマンドの開発によるユニケージの適用可能分野の拡大や、さらなる改良に取り組みたい。

7. 3 デプロイ/移植が容易
ユニケージに基づき開発されたシステム、ユニケー
ジシステムはデプロイや移植が容易である。

RDBMS や NoSQL を利用したシステムの多くは、複雑な設定を必要とするためデプロイは必ずしも容易とは言えず、また移植性もまちまちであるが容易でない事がおおい。
一方で、UNIX 哲学は移植性を重視すべしという方針が貫かれており、UNIX 哲学を基礎におくユニ
ケージもまたその方針を受け継いでいる。既に動作しておりデータが蓄積されたユニケージシステムを新しい環境に移植する際には、単純にファイルとコマン
ドをコピーし、コマンドへのパスを通すだけでよい。

参 考 文 献[1] Cheung, S., Nakamoto, M., and Hamuro, Y.:
NYSOL: A User-Centric Framework for Knowledge
Discovery in Big Data, International Journal of
Knowledge Engineering, Vol. 1, No. 3(2015).
[2] Gancarz, M., 桂, and 芳尾: UNIX という考え方:
その設計思想と哲学, オーム社, 2001.
[3] ユニバーサル・シェル・プログラミング研究所: ユニ
ケージ原論, ユニバーサル・シェル・プログラミング研
究所, 2010.
[4] 松田康之: ”川下”からの流通情報戦略 「情報武装」
革命, オフィス 2020, 1987.
[5] 松浦智之, 大野浩之, 當仲寛哲, ほか: ソフトウェアの高い互換性と長い持続性を目差す POSIX 中心主義プロ
グラミング, マルチメディア, 分散協調とモバイルシンポ
ジウム 2016 論文集, Vol. 2016(2016), pp. 1327–1334.