Not Only SQL(RDBMSじゃないSQL)
データベース側に隠蔽されていた操作をアプリケーションの設計側に押し出した システムアーキテクトの立場で考えると、これらのシステムの仕組みをより深く知っておく必要がある
RDBMSが役に立つ場面(SQLと関係モデル)
SQLを使えば、データのディスク上での配置や使うインデックスそしてデータを処理するアルゴリズムを知らなくても必要な情報をよしなに取り出すことができる
クエリオプティマイザ
論理的に等価であるいろいろな問い合わせプランの中から最も効率的な問い合わせができるものを見つける
クエリ (データに対する問い合わせ) を実行する最も効率的な方法を決定
RDBMSの問題点
- 複雑さは予測不可能性につながる。SQLは表現力がありすぎる
- 問題をモデル化する方法は一つではない
- データの量が増加して一つのサーバーでは保持しきれなくなると、データベース内のテーブルをパーティションに区切って複数のコンピューターで管理する必要がある
これだけ問題点はあるが、やっぱり枯れきった技術であるので、使うことを検討する必要はあると思う。
NoSQLの始まり
NoSQLが選択肢にあがるのは、何か特有の問題がある場合だ。たとえば大量のデータを扱う必要があったり作業量が膨大になったり、SQLとリレーショナルデータベースではうまく最適化できないようなデータモデリングを採用した場合などである
NoSQLムーブメントの起源をたどれば、その大半は研究コミュニティの論文に行き着く
Google BigTable 複数列からなる履歴データを分類して格納 Amazon Dynamo キー指向の分散型データストア
特徴と検討事項
大掛かりなSQL標準規格と決別して、ストレージの設計に関してシンプルながらも段階的なソリューションを提供 データベースがデータを操作する方法を単純化すればするほど、アーキテクトは問い合わせのパフォーマンスを予測しやすくなる
NoSQLではRDBMSの大前提であるACID特性をゆるくした
NoSQLの検討点
- データモデルとクエリモデル
- 永続性
- スケーラビリティ
- パーティショニング
- 整合性
- トランザクションの特性
- 単一サーバーでのパフォーマンス
- 作業量の分析
