# HG changeset patch # User Kazuma Takeda # Date 1482465468 -32400 # Node ID 4309d8dfb06c429f7f6f25a283f3a32b579df245 # Parent bb4bb252e1012ba10576c8037dc16600f7e3e3c2 fix indent diff -r bb4bb252e101 -r 4309d8dfb06c Slide/prosym.md --- a/Slide/prosym.md Fri Dec 23 12:42:59 2016 +0900 +++ b/Slide/prosym.md Fri Dec 23 12:57:48 2016 +0900 @@ -8,6 +8,7 @@ # データベースの歴史 コンピュータでは常に簡略化が行われてきた。 +[](入りをどうするかまだ) # 階層型データベース @@ -22,6 +23,7 @@ # ネットワーク型データベース CODASYLデータモデルともいう。 + 参照関係で表現が可能になった。そのため、複数参照されているものを一箇所にまとめることで 階層型のボトルネックであったデータ冗長化を排除することができる。 @@ -34,7 +36,8 @@ # CODASYLデータモデル -COBOLで多く用いられたデータベース。 +COBOLで多く用いられたデータベースの仕様。 + 現在のネットワーク型のほとんどがこれを準拠に作られている。 この特徴としてはデータ操作言語とデータ記述言語を分離している。 @@ -51,9 +54,9 @@ 抵抗の異なる素材の間に電磁波を流すと、境界面で反射が起こり、効率よく伝達できないことを意味する。 つまり、データベースの世界ではオブジェクト指向プログラミングで使用するデータ構造とリレーショナルデータベースに格納されているデータの間にあるギャップのことをいう。 -この問題に対応するためにO/Rマッパーと呼ばれるフレームワークを使う。 +この問題に対応するためにO/R Mapperと呼ばれるフレームワークを使う。 -# O/R マッピング +# O/R Mapper オブジェクトに対する操作を行うとORMapperがSQLを発行し、処理を行ってくれる。 SQLを直接扱う場面は減るがSQLを理解しなくてもいいというわけではない。 @@ -64,17 +67,22 @@ # 近年 NoSQLと呼ばれるデータベースが開発、利用されている。 + CPUやメモリに比べて低速なストレージ性能を分散させ、 -ネットワークのボトルネックを極力排すること目的とされている。 +ネットワーク型のボトルネックを極力排すること目的とされている。 # Key-Value Store + データをKeyとValueのHash形式でもつ。 + 完全一致検索しかできないが高速で動作する。 # カラム指向 RDBと同様に表を持つ。 + カラム単位でデータを保持する。 + 大量のデータを読み書きするのに最適とされている。 例: @@ -84,7 +92,9 @@ # ドキュメント指向データベース + スキーマが必要ななく使用できる。 + 複雑な検索条件でデータを取得できる。 例: @@ -100,7 +110,9 @@ ドキュメント指向型のデータベースである。 + NoSQLのパフォーマンス、スケーラビリティに優れている。 + なお、パフォーマンスを向上させるため、トランザクション、リレーショナルの機能は実装されていない。 Key-Value Storeでは完全一致検索しかできないが、 @@ -109,14 +121,17 @@ # 現在の課題 コンピュータのCPU性能は格段によくなった。しかし、これ以上CPUの性能が大幅に向上するとは思えない。 + 一方、データは膨大化している。 + CPUを物理的に増やすことで、解決はできるが、有限な物であるため一時的な解決方法にしかならない。 そこで並列処理という手法が考えられる。 + トランザクションの機能を排除した、MongoDBでは並列で動くアプリケーションには向いていない。 -トランザクションを備えたRDBはもちろん並列アプリケーションに向いている。 -先ほど述べた、オブジェクト指向プログラミングとリレーショナルデータベースの間ではインピーダンス・ミスマッチが起こってしまう。 +RDBではトランザクションが実装されているのでもちろん並列アプリケーションに向いていると言える。 +しかし、先ほど述べた、オブジェクト指向プログラミングとリレーショナルデータベースの間ではインピーダンス・ミスマッチが起こってしまう。 # 提案