過去に回帰するデータベース

クラウド･コンピュータの普及でスケーラビリティーの問題が顕在化してきた。それに伴いスケーラビリティーに限界のある本来のリレーショナル・データベースからスケール可能なキー･バリュー型のデータベースへの転換が進んでいる。海外ではgoogleのBig Table、日本においてもミクシィのTokyo Cabinetや楽天のROMAやグリーのFlareなどデータベースの新顔が登場してきている。こうした動きは全く新しいものと思えるが実際はちょっとした過去への回帰でしかない。以前からデータ・ストアに関してはリレーショナル･データベースばかりでなく多種のアプローチの仕方が存在した。ところが1980年代に入るとリレーショナル･データベースが主要な位置を占めるようになり、リレーショナル･データベース開発をとりまくさまざまなツールやテクニックが開発されていった。人々の意識の中でデータベースといえばリレーショナル･データベースという観念が出来上がってしまったことは逆に問題でもあった。リレーショナル･データベースは多くのシチューエーションにおいて有効ではあったが、「すべて」のシチュエーションに有効かといえばそうではなかったからだ。リレーショナル･データベースの占有化はすなわち、非リレーショナルな問題にリレーショナルなモデルで無理に対応しようとして大量の時間と資金が浪費されることを意味した。データ･ストアに関する固定観念からの脱却は大きな可能性を秘めており、現在はそのルネッサンスのただなかにあるといえる。

We at google created something called Big Table that underlies the datastore in App Engine. The design for Big Table focused on scalability across a distributed system so it may operate a bit differently than databases you've worked with before, such as not supporting joins. This isn't an accident -- when you build a system that can scale to the size that Big Table can there's no way to do a general purpose join on data sets that size and still have them be performant.

http://googleappengine.blogspot.com/2009/02/back-to-future-for-data-storage.html

cloud platform without a scalable data store is not much of a platform at all. So, to provide customers with a scalable place to store application data, vendors had only one real option. They had to implement a new type of database system that focuses on scalability, at the expense of the other benefits that come with relational databases.

http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php