リレーショナルデータベースにデータを格納する場合、まずテーブルの定義を行って、その後にテーブル定義に沿ったデータを挿入(insert)していくことになります。
例えば、以下のようなデータをリレーショナルデータベースに格納することを考えてみます：
（主キーとか制約とか）深く考えずにこのデータ格納用テーブルを定義すると、その SQL はこんな感じになると思います：
いわゆる「普通の」リレーショナルデータベースの場合、テーブルは行指向になります。１つのレコードを１行のデータと見なして格納します（直感的に理解しやすいと思います）：
これに対して、列指向と呼ばれるテーブル定義の場合、データは列ごとにまとまった形で持つことになります。そのため１つのレコードを格納する場合も、複数の列のデータに各値を追加することになります（こちらは直感的には理解しにくいと思います）：
なぜこんな直感的にわかりにくいテーブル定義が存在しているのか、というと、この方が便利になるケースがあるからです。例えば「身長の平均値」を取り出そうとすると、SQL では AVG 関数を使って以下のような処理を実行することになります：
SQL ではシンプルに見えますが、行指向データベースでこの時に内部で実行される処理は比較的重いものになります。各レコードを取り出し、各レコードの身長（height）の値を取り出しては合計して平均値を取り出し・・・という処理を行います。レコード数が増えるほど「各レコードを取り出す」回数が増え、全体負荷が大きなものになります。Oracle や SQL Server だと一発で標準偏差を求める STDDEV 関数とかもありますが、これも処理はかなり重いものです。
一方これが列指向データベースの場合、身長列のデータをひとまとめに取り出せるので、そこから平均値を計算するのが比較的楽になります。
では列指向データベースの方がパフォーマンスに優れているのか、というとそうとも限りません。データを１つ（１レコード）挿入する場合の内部処理を考えると、行指向では１つのレコードを追加するだけですが、列指向では各列に値を１つずつ追加することになります。データの追加や更新といった処理におけるパフォーマンスは、一般的には行指向データベースの方が優れていることになります。
要するに利用用途に応じて行指向データベースと列指向データベースを使い分けるのが理想ということになります。ただ「普段は行指向データベースを使って、統計処理を行う時のために列指向データベースに定期的に同期する」といったように、行指向データベースと列指向データベースを連携させる必要が出てきた場合など、データや形式の互換性などをあらかじめ考慮した上で製品やサービスを選ぶ必要がでてきます。
さて、そこで dashDB です。IBM Bluemix 上のサービスの１つとして提供されている DBaaS のデータベースですが、その特徴の１つに「テーブル定義の際に行指向か列指向かを指定できる」ことがあります。
例えば上記のテーブルを dashDB 上に行指向テーブルとして作成する場合は以下のような SQL コマンドを実行します：
一方、同じテーブルを列指向テーブルで作成する場合はこちらの SQL コマンドを実行します（ちなみに dashDB ではこちらがデフォルト）：
つまり dashDB を使えばデータベース間の互換性を意識する必要もなく、１つのデータベースサービスインスタンスの中でテーブル毎に行指向か列指向かを指定して定義することができるのでした。トランザクション用途であれば行指向、分析用途であれば列指向といった具合にテーブルを定義することで、データベースサーバーの使い分けを意識することなく両方の用途で利用できるクラウドの DBaaS であることが最大の特徴だと思っています。
ちなみにこれが IBM Bluemix での dashDB のアイコンです。左が（普通の）dashDB で、右がトランザクションモードの dashDB Transaction 。パッと見て列指向か行指向かがわかるようになっている（らしい）です：
加えて dashDB は Bluemix 上のフルマネージドな RDB クラウドサービスなので、データベースサーバーとしての管理は不要です。しかもデータ量が無料枠である1GB 未満であれば課金されることもないため、データベースとして本格的に利用する前の検証用途として安心して使ってくださいませ。
例えば、以下のようなデータをリレーショナルデータベースに格納することを考えてみます：
（主キーとか制約とか）深く考えずにこのデータ格納用テーブルを定義すると、その SQL はこんな感じになると思います：
create table users( id long, name varchar(100), height float, weight float );
いわゆる「普通の」リレーショナルデータベースの場合、テーブルは行指向になります。１つのレコードを１行のデータと見なして格納します（直感的に理解しやすいと思います）：
これに対して、列指向と呼ばれるテーブル定義の場合、データは列ごとにまとまった形で持つことになります。そのため１つのレコードを格納する場合も、複数の列のデータに各値を追加することになります（こちらは直感的には理解しにくいと思います）：
なぜこんな直感的にわかりにくいテーブル定義が存在しているのか、というと、この方が便利になるケースがあるからです。例えば「身長の平均値」を取り出そうとすると、SQL では AVG 関数を使って以下のような処理を実行することになります：
select avg(height) from users;
SQL ではシンプルに見えますが、行指向データベースでこの時に内部で実行される処理は比較的重いものになります。各レコードを取り出し、各レコードの身長（height）の値を取り出しては合計して平均値を取り出し・・・という処理を行います。レコード数が増えるほど「各レコードを取り出す」回数が増え、全体負荷が大きなものになります。Oracle や SQL Server だと一発で標準偏差を求める STDDEV 関数とかもありますが、これも処理はかなり重いものです。
一方これが列指向データベースの場合、身長列のデータをひとまとめに取り出せるので、そこから平均値を計算するのが比較的楽になります。
では列指向データベースの方がパフォーマンスに優れているのか、というとそうとも限りません。データを１つ（１レコード）挿入する場合の内部処理を考えると、行指向では１つのレコードを追加するだけですが、列指向では各列に値を１つずつ追加することになります。データの追加や更新といった処理におけるパフォーマンスは、一般的には行指向データベースの方が優れていることになります。
要するに利用用途に応じて行指向データベースと列指向データベースを使い分けるのが理想ということになります。ただ「普段は行指向データベースを使って、統計処理を行う時のために列指向データベースに定期的に同期する」といったように、行指向データベースと列指向データベースを連携させる必要が出てきた場合など、データや形式の互換性などをあらかじめ考慮した上で製品やサービスを選ぶ必要がでてきます。
さて、そこで dashDB です。IBM Bluemix 上のサービスの１つとして提供されている DBaaS のデータベースですが、その特徴の１つに「テーブル定義の際に行指向か列指向かを指定できる」ことがあります。
例えば上記のテーブルを dashDB 上に行指向テーブルとして作成する場合は以下のような SQL コマンドを実行します：
create table users( id long, name varchar(100), height float, weight float ) organized by row;
一方、同じテーブルを列指向テーブルで作成する場合はこちらの SQL コマンドを実行します（ちなみに dashDB ではこちらがデフォルト）：
create table users( id long, name varchar(100), height float, weight float ) organized by column;
つまり dashDB を使えばデータベース間の互換性を意識する必要もなく、１つのデータベースサービスインスタンスの中でテーブル毎に行指向か列指向かを指定して定義することができるのでした。トランザクション用途であれば行指向、分析用途であれば列指向といった具合にテーブルを定義することで、データベースサーバーの使い分けを意識することなく両方の用途で利用できるクラウドの DBaaS であることが最大の特徴だと思っています。
ちなみにこれが IBM Bluemix での dashDB のアイコンです。左が（普通の）dashDB で、右がトランザクションモードの dashDB Transaction 。パッと見て列指向か行指向かがわかるようになっている（らしい）です：
加えて dashDB は Bluemix 上のフルマネージドな RDB クラウドサービスなので、データベースサーバーとしての管理は不要です。しかもデータ量が無料枠である1GB 未満であれば課金されることもないため、データベースとして本格的に利用する前の検証用途として安心して使ってくださいませ。
