パリ協定以降、多くの国が自国から排出される温室効果ガスを削減する試みを続けており、その一環として、化石燃料を使った既存の発電方法から太陽光や風力など二酸化炭素を排出しない発電方法への転換が進められているところもあります。
こうした施策により電力のほとんどを太陽光発電で賄えるようになる地域も現れ始めたのですが、一方で過剰な発電による別の課題に直面しているとして、ローカルニュースサイトのSFGATEがカリフォルニア州の事例を挙げて問題点を解説しています。
このように、発電能力だけが進歩し、蓄電や給電能力が追いついていないという状況はカリフォルニア州以外でも見られており、このままだと電気を消費すればするほどお金がもらえる時代が訪れるかもしれないと分析する専門家もいるほどです。
北米電力信頼度協議会(NERC)が、2024年12月に提出した報告書の中で、今後5年から10年の間にアメリカ大陸の半分以上がエネルギー不足に陥るリスクが高まっていると報告しました。発電所の廃止が進む一方で、新設されるデータセンターが膨大な電力を消費することが原因の一つとされています。
⇧ 何というか、
- 電力余剰
- 電力不足
のバランスが取れないものなのかね？
蓄電や給電能力が整備されないのは、
- 技術的に不可能
- 金銭で解決できる
のどちらかなのかが気になりますな。
金銭で何とかなるのであれば、政府による公共事業とかで社会インフラ整備を進めれば解決できる気はしますが...
Linuxのraw deviceとは？
Wikipediaによりますと、
In computing, specifically in Unix and Unix-like operating systems, a raw device is a special kind of logical device associated with a character device file that allows a storage device such as a hard disk drive to be accessed directly, bypassing the operating system's caches and buffers (although the hardware caches might still be used).
Applications like a database management system can use raw devices directly, enabling them to manage how data is cached, rather than deferring this task to the operating system.
In Linux, opening a block device with the O_DIRECT flag replaces raw device usage. Raw devices were removed entirely from the Linux kernel in the 5.14 release.
⇧ とあり、「Unix」由来の「OS（Operation System）」における話であり、
『a raw device is a special kind of logical device associated with a character device file that allows a storage device such as a hard disk drive to be accessed directly, bypassing the operating system's caches and buffers (although the hardware caches might still be used).』
という説明から、「論理デバイス」の1種らしい。
「データベース」などで「raw device」をマウントすると、「データ」の「キャッシュ」を「OS（Operation System）」に管理させるのではなく「データベース」自身ができるということらしい。
Linuxのdeviceとraw deviceの関係は？
そもそも、「Linux」において「device」とは？
A kernel is a computer program at the core of a computer's operating system that always has complete control over everything in the system. The kernel is also responsible for preventing and mitigating conflicts between different processes.
It is the portion of the operating system code that is always resident in memory and facilitates interactions between hardware and software components.
A full kernel controls all hardware resources (e.g. I/O, memory, cryptography) via device drivers, arbitrates conflicts between processes concerning such resources, and optimizes the utilization of common resources e.g. CPU & cache usage, file systems, and network sockets.
⇧ うむ、全く分らん。
oreillyの資料によると、
⇧ 入出力に関わるハードウェアが「device」ということなのだろうか？
Linuxでデータベースをraw deviceにマウントする効果は
で、ふと「データベース」において「file descriptor」の扱いってどうなるんだろう？と気になって、職場の方に聞いてみたところ、「データベース」の使い方に依りけりということで、
- raw deviceにmountする
- raw deviceにmountしない
によって変わってくるらしい。
ネットの情報を漁ってみたところ、
⇧ 有識者の方の情報によると、昔は、「raw device」を利用するのが一般的な時代があったということなので、今はあまり利用されない方法なのかもしれない。
で、ChatGPTに質問してみたところ、
■1. RAWデバイスを使用する場合のファイルディスクリプタの扱い
- ファイルシステムの管理がない: RAWデバイスを使用する場合、データベースやアプリケーションはファイルシステムを介さずに直接ディスクにアクセスします。そのため、RAWデバイスに対するファイルディスクリプタは、通常のファイルシステムのファイルに対するものとは異なります。
- データベースが直接操作: ファイルディスクリプタは、データベースやアプリケーションが直接ディスクのブロックを操作するためのインターフェースとなります。データベースは低レベルでディスクアクセスを管理し、通常のファイルシステムによるメタデータやインデックス管理を回避します。
- 高性能のための最適化: RAWデバイスは、ファイルシステムによる余分な管理を避けるため、データベースがファイルディスクリプタを使って効率的にディスクI/Oを実行することが可能になります。例えば、データベースが直接物理的なブロックを読み書きし、データの整合性や管理をアプリケーション側で担うため、ファイルディスクリプタの利用もシンプルで、オーバーヘッドが少なくなります。
■2. 通常のファイルシステムを使用する場合のファイルディスクリプタの扱い
- ファイルシステムによる管理: 通常のファイルシステムを使用する場合、ファイルディスクリプタは、ファイルシステム内で管理されるファイルを操作するためのものです。アプリケーションがファイルを開くと、ファイルシステムがそのファイルに関連するメタデータやインデックスを管理します。
- ファイルシステムのオーバーヘッド: ファイルシステムがファイルやディレクトリの整合性を維持するため、ファイルディスクリプタを介して行われる操作には、追加の処理（例えば、メタデータの更新やデータのインデックス管理）が伴います。これにより、RAWデバイスに比べて、I/Oパフォーマンスが若干低下する場合があります。
- ファイルシステム操作の利便性: 通常のファイルシステムを使用すると、データのアクセス管理（アクセス権、ユーザー管理など）やデータ整合性のチェック（クラッシュ時の修復やバックアップなど）がファイルシステムによって自動的に処理されるため、ファイルディスクリプタを使用する際の管理が簡便になります。
■具体的な差異
- ファイルディスクリプタの解放: ファイルシステムを使っている場合、ファイルディスクリプタは、ファイル操作後にファイルシステムに関連するリソースを解放します。一方、RAWデバイスの場合、ファイルシステムが存在しないため、データベースやアプリケーションが直接リソースを管理し、開放する必要があります。
- リソースの管理: 通常のファイルシステムでは、ファイルディスクリプタを使ったアクセスが抽象化されており、システムがファイルの整合性やストレージの状態を管理します。RAWデバイスではそのような管理がなく、アプリケーション側で直接ディスクの読み書きやエラーハンドリングを行うため、より直接的で低レベルな操作が行われます。
というような回答が得られました。
「file descriptor」以外にも以下のような違いが出てくるらしい。
| No | 項目 | RAWデバイスを使用する場合 |
|---|---|---|
| 通常のファイルシステムを使用する場合 | ||
| 1 | パフォーマンス | ファイルシステムのオーバーヘッドがないため、高パフォーマンスが得られることがある。データベースが直接ディスクにアクセスするため、トランザクション処理や大量のデータを扱う場合に有利。 |
| ファイルシステムのオーバーヘッドが発生するため、RAWデバイスに比べてやや低いパフォーマンスになることがある。ファイルシステムによる管理が影響することがある。 | ||
| 2 | 管理の容易さ | ファイルシステムが無いため、管理が手動で行われる部分が多い。ディスクのスペースやデータの配置をデータベースが直接管理する必要がある。 |
| ファイルシステムによる自動管理があるため、管理が簡単。データ整合性やアクセス管理がファイルシステムに任される。 | ||
| 3 | ストレージ管理の柔軟性 | ストレージ管理の自由度が高い。データベースがディスクのブロックを直接管理。パフォーマンス最適化のために細かな設定が可能。 |
| ファイルシステムの制限に従う必要がある。ストレージの最適化に限界がある場合がある。 | ||
| 4 | データ整合性と信頼性 | データ整合性の管理はアプリケーション側で行う必要があり、ファイルシステムによる保護がない。障害回復や整合性チェックが難しくなる場合がある。 |
| ファイルシステムが自動的に整合性を管理。ファイルシステムによるエラーチェックや修復機能があるため、信頼性が高い。 | ||
| 5 | 可用性と耐障害性 | 障害時の回復が難しくなる場合がある。ファイルシステムの冗長性（RAIDなど）を直接使用する必要がある。 |
| ファイルシステムの冗長性機能（RAIDやジャーナリングなど）を利用できるため、耐障害性が高い。 | ||
| 6 | バックアップと復元 | バックアップや復元は手動で行う必要があり、データベースの構成に依存。バックアップツールはファイルシステムに依存しない方法を選ぶ必要がある。 |
| ファイルシステムに依存したバックアップや復元が可能。より簡単で効率的にバックアップを行うことができる。 | ||
| 7 | トランザクション管理 | トランザクションログやデータの管理がアプリケーション側で行われる。高いパフォーマンスが求められる場合に最適だが、管理が難しい。 |
| ファイルシステムがトランザクションやログ管理を提供することがある。安定性が高いが、パフォーマンスに影響を与えることがある。 | ||
| 8 | 運用コスト | 運用が複雑で、特に大規模システムの場合、技術的なハンドリングが必要。運用スタッフのスキルが重要。 |
| 運用が比較的簡単で、ファイルシステムの管理に依存する部分が多いため、運用コストが低くなることが多い。 | ||
| 9 | エラーハンドリングとリカバリ | エラーハンドリングがアプリケーション側で行われる必要があり、リカバリ作業が複雑になりやすい。 |
| ファイルシステムによるエラーハンドリングと自動修復が可能。システム障害時のリカバリが容易で、リスクが低い。 |
とりあえず、管理の手間のわりに得られるメリットが少ないということで、「raw device」をmountする利用方法は使われなくなったということなんですかね？
PostgreSQLの開発者向けのFAQでも、
なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか?
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。
⇧ とあり、劇的な改善に繋がらないという見解らしい。
まぁ、回答で「raw device」について触れてくれていないので、何とも言えませんが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
