NOSQLは「知る時代」から「使う時代」へ

2. okuyamaとは

ここまで、NOSQLの背景と特徴、およびNOSQL内での種別について、駆け足で説明してきました。

次回以降はokuyamaについて詳しく解説しますが、まずはokuyamaについて、今まで説明した各項目のどこに当てはまるのかを事前に整理しておきます。

okuyamaは、複数のサーバーを利用して分散環境で稼働することを前提に実装された、分散Key-Value型のNOSQL（分散Key-Value Storeと呼ばれることが多いです）です。

CAP定理で言うと、AP（可用性と分割耐性）を満たすように設計されています。しかし、Key-Value型の特徴にはない、複数のデータをタグで管理する概念があります。加えて、CAP定理における一貫性（C）を重視する設定も可能です。

（1）okuyamaを開発した経緯

筆者がokuyamaを開発し始めたのは、2009年の12月頃です。当時、HBaseなどが話題となっており、筆者に技術検証を行っていました。

ストレージ分野が好きだったこともあり、JavaのHSQLDBなどのソース・コードを読み、自身でもRDBMSを開発したりしていました。自作のRDBMSの開発が一通り終わったころ、HBaseの検証をしていたこともあり、勉強も兼ねてokuyamaの開発を始めました。ファースト・リリースは2010年の1月に行いました。

okuyamaを開発する際、特に力を入れた部分が3つあります。

1. サーバー障害時のフェール・オーバーと復旧時の自動リカバリ

動的にサーバーを追加する機能と、追加中にデータを自動的に最適化する機能と、追加中にアクセスを許容する機能です。この部分は、CAP定理のAPを満たすためのアプローチです。

2. 単一サーバーあたりの処理能力向上

分散Key-Value Storeは、その特性上、サーバー台数を増やすことによって処理能力を向上させることができます。しかし、1台あたりの性能が高ければ、サーバー増設数を少なく済ませられます。サーバー台数が増えれば故障率も上がるので、少ない台数で効率よく処理できるのであれば、それに越したことはありません。ですので、この部分にも力をいれました。

3. ストレージ機能

最後は、データを保存するストレージ部分の機能です。いくつかの保存方式を用意し、ユース・ケース単位で最適な選択ができるようにしました。

次回は、okuyamaの全体概要に加え、上記3点を中心にokuyamaの機能を解説します。