RDB的限制和NoSQL的出现

2 年 ago

新, 韵

3 minutes

こんにちは、Stamp Incの村本です。
NoSQLの過去と未来についてまとめます。
普段はFirebaseの技術コンサルティングをやってます。

RDBの歴史

为了讨论NoSQL的必要性，首先我们要回顾关系型数据库（RDB）的出现情况和历史。RDB的问世可追溯到20世纪70年代。

关系数据库的出现

RDB(リレーショナルデータベース)が登場する以前のデータベース市場では、階層型と呼ばれるモデルに基づいた製品が主流だった。当時はIBMが開発したInformation Management System(IMS)が利用されていた。

IMSが使われた最も有名なシステムが、1961年から始まったNASAのアポロ計画です。最終製品を構成する部品の階層関係を表したリストをBOM（Bill of Materials）と呼び、製造業ではどのような製品を作るかを問わず、このBOMが設計図と並ぶ重要な情報です（BOMは日本語では「部品表」と呼びます）。IMSはロケットの膨大な部品群を管理するという難解な課題に優れた解を与えたデータベースでした。

RDB的发明者是IBM工程师。

40代半ばのエンジニアE.F.コッドが書いた「A Relational Model of Data for Large Shared Data Banks」

关系数据库的发明者E. F. CODD

大型共享数据库的数据关系模型

【论文】https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
【参考】爱德加·科德的《关系数据模型理论》
【参考】https://www.cc.u-tokai.ac.jp/text/2005/Access-intro.pdf

然后，由外部工程师们开发了许多RDB。

年代DB主要な開発元1974年Ingresカリフォルニア大学1979年Oracle DatabaseOracle1983年DB2IBM1987年Sybase SQL ServerSybase1989年MS SQL ServerMicrosoft1989年PostgreSQLカリフォルニア大学1995年MySQLMySQL AB

ACID的概念比RDB更早诞生。

ACID是由安德烈亚斯·罗伊特和特奥·赫尔德尔于1983年提出的，这个概念在20世纪70年代末由吉姆·格雷定义。此外，IMS在1973年开始支持ACID事务。

年代できごと1973年IMSはACID トランザクションをサポート1979年ジム・グレイがACIDの概念を定義1983年アンドレアス・ロイターとテオ・ヘルダーがACIDを提唱

一直以来都重视数据的一致性的历史

RDBがトランザクションを重要視しているのには理由がある。開発当初は世界中の人間がアクセスするインターネットはなく、マシンの性能もムーアの法則の初期で限界を意識してなかったはずだ。
システムがデータベースに求めたのはスケール性能ではなく、厳密な一貫性だったと言える。

年代できごと1961年最初のパケット通信の論文1969年ARPANETで初のパケット送信1980年イーサネットの規格公開1982年TCP/IP標準化1982年Simple Mail Transfer Protocol (SMTP)1983年Domain Name System (DNS)

事実世界のインターネット人口が増えたのは1990年代からだ。

NoSQL的出现。

1990年に入るとインターネットの利用人口が急激に増加することになる。
この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。

多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャーディング) を試み、(サーバーの「クラスター」内で) 分散システムとして実行しました。しかし、リレーショナル・データベースには 1 次書き込みサーバー・ノードと読み取り専用のレプリカとの間のデータの平行性に問題があり、アクセス・スピードに悩まされ、異なるノードに格納されているテーブル間の結合操作を効果的に実行できないことがわかりました。

1998年Carlo StrozziによってSQLのない軽量なDBを推進する運動として”NOSQL”という言葉が使われる。

非仅为SQL

2000年代半ばに2つの企業がデータの保管と検索のための新たなモデルを相次いで発表する。
Googleは2006年「A Distributed Storage System for Structured Data」でカラム指向データベース・システムである「BigTable」の妥当性を示し、Amazonは2007年「Dynamo」で分散キーバリュー・ストレージ・システムを提示した。

そして、2009年にサンフランシスコで開かれたミートアップで「NoSQL」がハッシュタグとして使われ、次々生まれることになるRDBでないデータベースは「NoSQL」と呼ばれることになる。

Bigtable: A Distributed Storage System for Structured Data
Dynamo: Amazon’s Highly Available Key-value Store

NoSQLを次のレベルに引き上げたCassandra（カサンドラ）

Facebookによって開発されたNoSQLのデータベースCassandra。
Facebookは2008年7月にCassandraをオープンソースソフトウェアとして公開し、2009年3月からApache Incubatorプロジェクトとなる。DynamoDBのような高い可用性とスケーラビリティを保持している。

Facebookのデータチームを率いるJeff HammerbacherはCassandraをAmazon DynamoDBのようなインフラストラクチャ上で動作するBigTableデータモデルであると表現している。

調節可能な整合性レベルと結果整合性

CassandraはDynamoと同じく、基本的には結果整合性を前提としているが整合性レベルの調節が可能だ。これにより開発者はスケーラビリティとのトレードオフを実現できるようになっている。

优化书写性能

亚马逊的Dynamo采用了B树，而Cassandra则采用了LSM树，与谷歌的BigTable的模型HBase相同。

Cassandraが採用したCAP定理はAP

HBaseはCAP定理のCPを採用し、CassandraはAPを採用している。
一貫性を強く意識して作られてきたデータベースの歴史の中で一貫性を捨てたことには大きな意味がある。正確には捨てた訳でなくEventual Consistency（結果整合性）の概念を取り入れている。

一致性图解大全，涵盖了直至最终一致性为止的程度。

Paxos是一种分散一致性协议。

インターネット人口の増加に伴い世界的にデータベースを分散化させるニーズが出始める。そこで重要になったのが地理的に分散化したデータベースでも一貫性を保つ手法だ。Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年。

[参考] https://ja.wikipedia.org/wiki/Paxos%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0

NoSQL的引入进展不顺利

推特考虑引入Cassandra，但最终决定放弃。

考虑引入Cassandra

TwitterはMySQL+memcachedで運用を行っていたが、運用コストの増加によりほかのデータベースを検討を始める。
2010年のmyNoSQLには次のようなインタビューがある。

Twitter上的卡桑德拉：采访瑞安·金

We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.
私たちはShardingされたMySQL + memcachedをベースとしたシステムを運用しています。しかしそれは急速に受け入れがたいほど運用コストが（おもに人的コストが）かかるようになってしまいました。もっと高可用で自動化された方法で成長可能なシステムが必要です。

GoogleでMySQLエンジニアリングチームを率いたのち、現在はFacebookに在籍しているMark Callaghan氏が2010年にポストしたブログは次のように始まる。

善于与他人合作

A few years ago MySQL+memcached and PostgreSQL+memcached were the only choices for high-scale applications. That has changed with the arrival of NoSQL.
数年前まで、MySQL+memcachedやPostgreSQL+memcachedの組み合わせは、スケーラブルなアプリケーションのための唯一の選択肢だった。しかしその状況はNoSQLの登場で変わった。

Facebook员工Mark Callaghan在YouTube上发布的视频，评估了MySQL与其他数据库的比较。

戦略的理由で導入を断念

NoSQLデータベースであるCassandraへ移行しようとしたが作業を中止し、引き続きMySQLでの運用を継続すると、2010年7月9日のTwitter Engineering Blogで公表する。

Cassandra at Twitter Today

For now, we’re not working on using Cassandra as a store for Tweets. This is a change in strategy. Instead we’re going to continue to maintain our existing Mysql-based storage.
We believe that this isn’t the time to make large scale migration to a new technology.
ツイートの保存先としてCassandraを使うための作業を中止した。これは戦略の変更だ。私たちは既存のMySQLベースのストレージを利用し続けることにする。
いまは新しい技術への大規模な移行をする時期ではないと確信している。

Twitter在2010年10月时利用Cassandra在位置信息数据存储、实时分析热门推文等多项用途，包括数据挖掘处理。只是放弃了Cassandra作为推文存储的选择，希望不要误解。

日付ブログ2010年2月23日Cassandra @ Twitter: An Interview with Ryan King2010年3月2日Plays well with others2010年7月10日Cassandra at Twitter Today

NoSQL解决了关系数据库的特性。

RDB的瓶颈有两个。

SQLが強力で柔軟なため複雑な処理を実行できてしまうこと

RDBの柔軟なQueryはNoSQLと比べて大きなアドバンテージである一方、障害点になり得ることを忘れてはならない。事実現在RDBに高負荷を与えているのは高度に組み上げられたSubQueryだ。NoSQLではQueryに頼らない設計をせざるを得ない。NoSQLではClient Side Joinを推奨しておりJOINをClient側で行う。これによりデータベースの負荷を分散している。
ただし、これはRDBでも同じ設計・開発方針を行うことは可能だ。ここで述べたいのはQueryだけに頼った設計では限界があることを開発者は意識すべきだと言うことだ。アプリケーションエンジニアとインフラエンジニアが別れてる開発現場においてはアプリケーションエンジニアの設計によってインフラエンジニアが悲しい思いをすることになる。

数据模型的限制

RDBは構造化データを表現しにくい

RDBは静的なテーブルの構造で、システムを運用する中で動的に変更することは想定していないことが一般的。テーブル定義やテーブル間のリレーションを変更することは大規模なマイグレーションが必要になる。

現在はMySQLはJSONに対応したことで、ドキュメントDBのように柔軟な設計を作ることも可能になった。

随着技术的发展，NoSQL和RDB之间的界限变得不清晰。

谷歌不断地推出NoSQL数据库。

2011年スケーラビリティと一貫性を両立した分散データストアMegastoreを発表。
Google Cloud Platform（GCP）では、Cloud Datastoreというデータストアを利用することができ、Cloud Datastoreは、内部的にMegastoreを用いて実装されている。

Megastore: Providing Scalable, Highly Available Storage for Interactive Services

2012年に設計が論文として公開されたSpanner。2017年からはGoogle Cloud Platform上で提供されている。
トランザクションに対する最も厳格な同時実行制御（外部整合）をクライアントに保証している。

扳手：谷歌的全球分布式数据库
[参考] Spanner：TrueTime和CAP定理

分散データベースであるCloud SpannerはNoSQLと似た特徴を持っていながらGoogleではRDBとして位置付けられている。

在数据库中，一致性的定义。

用語定義整合性データベースシステムにおける整合性は、あらゆるデータベーストランザクションが、影響されるデータを、許可された方法でのみ変更しなければならないという要件を指します。データベースに書き込まれるデータは、定義されたすべてのルールに従って有効でなければなりません。直列化可能性直列化可能性は、異なるトランザクションの一部が並列に複数のオブジェクトを読み書きする可能性がある、トランザクション分離プロパティです。トランザクションの挙動が、トランザクションが順次実行された場合と同じになることを保証します。ただし、その順序は、トランザクションが実際に実行された順序と違っても問題ないとされます。線形化可能性線形化可能性は、レジスタ（個々のオブジェクト）の読み書きの順序を保証します。オペレーションをトランザクションとしてグループ化しないので、競合のマテリアライズのような対策を講じなければ、書き込みスキューのような問題を防げません。強整合性すべてのアクセスがすべての並列プロセス（またはノード、プロセッサなど）によって、同じ順序で（順次実行されるように）見えます。レプリケートされたオブジェクトが線形化可能である場合、レプリケーションプロトコルは強整合性を示すという定義もあります。結果整合性結果整合性は、データベースへの書き込みを停止してしばらく待つと、最終的に、すべての読み取り要求に対して同じ値が返されることを意味します。外部整合性トランザクションの commit が認識される順序は順次実行順序と整合します。外部整合性は、線形化可能性と直列化可能性のどちらよりも強いプロパティです。

为什么你应该尽可能选择强一致性

请看参考资料。

TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由