アプリ版:「スタンプのみでお礼する」機能のリリースについて

通常のアプリケーションがディスクI/Oを行う時はOSまかせで、ファイル単位のI/Oしか行わないと考えます。
しかしデータベースとなればファイル単位ではやっていられないはずで、ここら辺はどのような仕組みになっているのでしょうか?
かなり低レベルのディスクI/Oを自前で(エンジンが)やるのでしょうか。

A 回答 (4件)

>かなり低レベルのディスクI/Oを自前で(エンジンが)やるのでしょうか。



なんとなくわかってきました。
fuuten_no_nekoさんの低レベルI/Oといっているところが。
通常は低レベルIOというと、ディスクのセクタ単位のリード、ライトをさします。なので、fuuten_no_nekoさんが思っている低レベルIOは、プログラマーなどから見ればぜんぜん低レベルIOではありません。

本来の意味の低レベルI/Oを直接DBエンジンが行うという例が、Oracleですとrawデバイスになります。


>しかしこれ単位ではDBのI/Oはやっていられないだろう、というのが元質問です。

OSのファイルシステムを介す時点でI/Oはファイル単位です。ファイル単位でオープンしてクローズします。


ただし、

>その中で更新の必要な箇所だけを随時ディスクに書いていく(フラッシュする)ようになっています。

なので、ファイルのどこに書き込むか?というレベルまでをDBエンジンは行っています。通常のファイルアクセスです。

ただし、もちろん効率化は行われてますよ。

たとえば、あるレコードを更新したら、データ量が増えたときなんてのは、そこに無理矢理データを挿入するのではなくDBのファイルの後ろにくっつけます。元のレコードにはくっつけたデータの位置だけを書きこみます。
こうすることで、書き込むデータ量を減らせます。
もし実際にファイルにデータを挿入しるとなると、書き込み位置より後ろのデータをすべてずらすようなIOを行うことになり非常に非効率となります。

同様に、レコードの削除も通常は削除フラグを立てるだけです。
    • good
    • 0
この回答へのお礼

繰り返しお付き合い頂き有り難うございます。

お礼日時:2005/01/19 13:00

>しかしDBはほとんどリアルタイムで書き込みを行います。

複数ユーザーの間でのデータ整合性を保つために。

複数ユーザーの間でというよりは、データベースとしての整合性ですね。整合性が取れないデータベースはDBじゃないですから。
複数のユーザというか複数セッションからの整合性はロックという考え方になります。


>で、このときファイル単位ではやっていられないと。

もしかして、勘違いされているのはデータ1つずつがばらばらのファイルという感覚なんでしょうか?

実際のDBのファイルでは、大きなひとつまたは複数のファイルの中で、どこにどんなデータを書くというのはあらかじめ決められています。その中で更新の必要な箇所だけを随時ディスクに書いていく(フラッシュする)ようになっています。これはOSの機能ですよ。


なので、
>通常のアプリケーション(例えばワード)では終了時または
>ユーザーが指定した時以外(自動バックアップは除く)ディスクI/Oを行いません。

こんなことは行いません。DBではリアルタイムに行われます。
特に、WordやExcelのファイルの保存というのは、新たにファイルを作り直しているようなものです。保存中に一旦一時ファイルが作成されていますよね。
G単位にもなるDBのファイルをこんなやり方で保存してたらやってられません。

この回答への補足

益々噛み合わなくなっているようです。
ファイル
http://yougo.ascii24.com/gh/73/007354.html
「一般的に、記録ディスクに保存されたデータやプログラムの個々のまとまりを「ファイル」という。ファイル名のあとに「.txt」「.exe」「.xls」などといった「拡張子」を付けることでファイルの種類が見分けられる。」
ということで例えばアクセスでいえば xxx.mdb
しかしこれ単位ではDBのI/Oはやっていられないだろう、というのが元質問です。

補足日時:2005/01/19 11:22
    • good
    • 0

>しかしデータベースとなればファイル単位ではやっていられないはずで、ここら辺はどのような仕組みになっているのでしょうか?



通常は巨大なファイル単位ですけど。
なぜやっていられないとお考えなのでしょうか?

ただ、そのファイルの内部でDBエンジンがどのように内部的にファイルを使用しているかはディスクI/Oとは別問題です。

ただし、確かにディスクI/Oまで制御するものも存在します。Oracleはrawデバイスを使用して構築可能です。これはディスクI/Oまで制御して高速化を図っていますが、逆にOSによるファイル保護の恩恵が受けられないため信頼性が落ちます。

この回答への補足

どうも議論が噛み合わないようで(^^;
認識に間違いがあればご指摘下さい。
通常のアプリケーション(例えばワード)では終了時またはユーザーが指定した時以外(自動バックアップは除く)ディスクI/Oを行いません。しかしDBはほとんどリアルタイムで書き込みを行います。複数ユーザーの間でのデータ整合性を保つために。
で、このときファイル単位ではやっていられないと。

補足日時:2005/01/19 05:49
    • good
    • 0

ファイルシステムを介さないものがあったと


記憶しています。

例えば、UNIXのディスクは/dev/rsd?(BSD系)で直接
アクセスできますが、これをファイルシステムとして
マウントせずにデータベースのストレージとして使っ
たりということです。

したがって、自前でやることになりますが、それでも
OSが介在するので、ヘッドをどこに動かすとかでは
なく、ソフト的にはバイト単位でアクセスできる大
きなファイルという感じに近いでしょう。

Windows系は知りません。どなたかフォローを。

この回答への補足

「低レベルのディスクI/O」がヘッドの移動などを意味するとすれば的外れでした(^^;
その辺りは曖昧に考えていました。

補足日時:2005/01/18 07:27
    • good
    • 0
この回答へのお礼

早速のご回答有り難うございます。
想像していたことが的外れではなかったと思っています。
Windows系も基本は同じことかもしれませんが、さらなるレスを期待しています。→皆様へ

お礼日時:2005/01/18 07:21

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す