ビッグデータに至るまでの歴史

「データ処理技術の歴史とビッグデータの現在」という記事が面白かったのでメモ。

【元ネタ】
佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（1/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（2/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（3/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（4/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（5/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（6/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」（7/7）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

インメモリデータベース（ＩＭＤＢ）と列指向データベース（ＣＯＤＢ）の歴史＜データベースの歴史＜歴史＜木暮仁

19世紀後半、アメリカの国勢調査で収集したデータを集計するのに数年もかかっていた。
その問題に対し、パンチカードを導入して、集計作業を短縮化し、IBMの基礎を作った。
ビッグデータがコンピュータを生んだ。

トランザクションの原理ACIDがRDBの根本思想を貫いている。
原子性（atomicity）、一貫性（consistency）、独立性（isolation）、永続性（durability）。
それらの性質を満たすように、RDBMSは実装されている。

RDBは2種類ある。
IBMのSystemRの流れを汲むOralce、DB2。
UCBのIngressの流れを汲むPostgres、Sybase、そしてSQLServer。
Ingressの後継者という意味で、Post＋Gress。

IBMは自社製のIMSを持っていたので、RDBの開発に乗り遅れた。
イノベーションのジレンマ。
IBMのコッド博士の継承者はOracleなのか？

DBの今後の動向。
列指向DBは、HadoopのHBaseに関連している。

インメモリDBが普及すれば、RDBMSのアーキテクチャが根本的に変わる。
RDBのボトルネックは、HDDへ書き込んで永続化(Durability)する箇所にある。
PostgresやMySQLのソースの大半は、メモリ上のデータをトランザクション処理を考えながら、いかに効率よくHDDに書き込むか、という工夫に費やされている。
メモリにデータを書き込んだ時点で永続化できれば、ソースが短縮化されて、すごく簡単になる。

NoSQLの今後。
大量データの収集と集計処理に強い。
但し、特定のアプリやサービスに特化しているため、そのままでは使えない。
分散システムを前提としているので、アーキテクチャに合わせた使い方が重要。

Hadoopのジレンマ。
RDBに比べて完成度が低く、RDBよりも未熟。
Hadoopの強みは、集計処理(Reduce)とデータの前処理(Map)だけ。
使いこなすには相当のノウハウが必要。

CAPの定理。
一貫性、可用性、ネットワークの耐性のうち、2つしか満たすことができないという経験則。
しかし、実際の現場では、3つの条件を全て満たせなくても、3つの条件は最低限クリアするように、ネットワークを冗長化したり、システムを冗長化したりして使っている。

今後面白いのは、90年代にRDB競争が激しかった頃のDB関連の特許が切れ始めるので、特許切れの内容をOSS製品が取り込んで実装されること。
今後、イノベーションが起きる可能性がある。