復旧と並行して、原因が「悪意のあるアクティビティ」かどうかも調査したが、そうではなく、人為的なエラーが原因だったとしている。
⇧ まぁ、時間がかかったとしても、しっかり復旧ができて、原因もハッキリしたということで、当事者もモヤモヤ感は無くて良いですよね。
Facebook社の経済損失はえげつないことになってるみたいですけど、日本だとFacebookってあまり積極的に利用されてないようなイメージあるんですが、影響はどの程度あったのか気にはなりますね。
ただ、世の中、そんな幸せなシステムばかりでもないってことは、皆々様、ご存知の通りです。
さらに9月30日午後、システムの不具合により387件の外国為替取引に遅れが出た。今年8度目の障害である。法人顧客の送金が滞り、一部は翌10月1日に持ち越されたようだ。原因は特定できていない。
⇧「原因は特定できていない。」という言葉の重さ...
これ、障害対応してるメンバが直面してるストレスは尋常じゃない気がする...
三菱UFJ銀行や三井住友銀行は合併の際に基幹システムを、合併を主導する銀行に片寄せした。片寄せというのは一本化することだ。ところが、みずほ銀行は前身である第一勧業銀行、富士銀行、日本興業銀行の3行の主導権争いが激しく、それぞれのシステムを存続させる形で経営統合した。その結果、統合初日の2002年4月、大規模なシステム障害が起き、250万件の口座振替などで遅れや誤処理が発生した。
みずほ銀行の勘定系システムは第一勧銀の富士通製、営業店システムの端末には富士銀が使っていた日本IBM製を採用。みずほコーポレート銀行は興銀の日立製をそのまま使った。
⇧ もう、現行稼働してるシステムで利用されてる「富士通」「日本IBM」「日立」の各システムに詳しい有識者を集めて原因究明にあたってもらって、原因特定できなかったら厳しい気もしますな...
冒頭から話が脱線しましたが、今回は、データベースに出てくる「ページ」や「ブロック」ついて調べてみました。
レッツトライ～。
データベースとは？
Wikipediaさんに聞いてみた。
In computing, a database is an organized collection of data stored and accessed electronically from a computer system. Where databases are more complex they are often developed using formal design and modeling techniques.
The database management system (DBMS) is the software that interacts with end users, applications, and the database itself to capture and analyze the data. The DBMS software additionally encompasses the core facilities provided to administer the database. The sum total of the database, the DBMS and the associated applications can be referred to as a "database system". Often the term "database" is also used loosely to refer to any of the DBMS, the database system or an application associated with the database.
Computer scientists may classify database-management systems according to the database models that they support. Relational databases became dominant in the 1980s. These model data as rows and columns in a series of tables, and the vast majority use SQL for writing and querying data. In the 2000s, non-relational databases became popular, referred to as NoSQL because they use different query languages.
⇧ コンピュータ上で、整理された「データ」を扱うことができますと。
それって、「Excel」とかでも「データ」扱えるやん？って思った方、鋭い！
そんな疑問に回答してくださってるのが、
⇧ 上記サイト様になりますと。
データベースの仕組みって？
Wikipediaさんに聞いてみた。
Storage
Database storage is the container of the physical materialization of a database. It comprises the internal (physical) level in the database architecture. It also contains all the information needed (e.g., metadata, "data about the data", and internal data structures) to reconstruct the conceptual level and external level from the internal level when needed.
Putting data into permanent storage is generally the responsibility of the database engine a.k.a. "storage engine".
Though typically accessed by a DBMS through the underlying operating system (and often using the operating systems' file systems as intermediates for storage layout), storage properties and configuration setting are extremely important for the efficient operation of the DBMS, and thus are closely maintained by database administrators.
A DBMS, while in operation, always has its database residing in several types of storage (e.g., memory and external storage). The database data and the additional needed information, possibly in very large amounts, are coded into bits. Data typically reside in the storage in structures that look completely different from the way the data look in the conceptual and external levels, but in ways that attempt to optimize (the best possible) these levels' reconstruction when needed by users and programs, as well as for computing additional types of needed information from the data (e.g., when querying the database).
⇧ 超ザックリ要約すると、『「storage engine（database engine）」でデータを「永続化（permanent）」する』ってことらしい。
何で「永続化」するかというと、
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.
In 1983, Andreas Reuter and Theo Härder coined the acronym ACID, building on earlier work by Jim Gray who named atomicity, consistency, and durability, but not isolation, when characterizing the transaction concept. These four properties are the major guarantees of the transaction paradigm, which has influenced many aspects of development in database systems.
According to Gray and Reuter, the IBM Information Management System supported ACID transactions as early as 1973 (although the acronym was created later).
⇧ 有名な「ACID (atomicity, consistency, isolation, durability) 」の性質が関わってますと。
- Atomicity（原子性）
- an indivisible and irreducible series of database operations such that either all occurs, or nothing occurs.
- Consistency（一貫性）
- The guarantee that any transactions started in the future necessarily see the effects of other transactions committed in the past
- The guarantee that database constraints are not violated, particularly once a transaction commits
- The guarantee that operations in transactions are performed accurately, correctly, and with validity, with respect to application semantics
- Isolation（隔離性）
- Isolation is typically defined at database level as a property that defines how or when the changes made by one operation become visible to others.
- Durability（耐久性）
- In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently.
この「ACID」の性質の「Durability（耐久性）」が「永続化」のことを意味してるらしい。
「storage engine（database engine）」のザックリとした概要なんかについては、
⇧ 上記サイト様がイメージしやすいかと。
「storage engine（database engine）」は、
⇧ データをどういった構造で扱うかによって、大まかに分けられるらしく、
- B-TREE
- LSM TREE
の2つに分類できるみたい。
Wikipediaさんによると、
■B-tree
In computer science, a B-tree is a self-balancing tree data structure that maintains sorted data and allows searches, sequential access, insertions, and deletions in logarithmic time. The B-tree generalizes the binary search tree, allowing for nodes with more than two children.
Unlike other self-balancing binary search trees, the B-tree is well suited for storage systems that read and write relatively large blocks of data, such as disks. It is commonly used in databases and file systems.
■Log-structured merge-tree
In computer science, the log-structured merge-tree (or LSM tree) is a data structure with performance characteristics that make it attractive for providing indexed access to files with high insert volume, such as transactional log data. LSM trees, like other search trees, maintain key-value pairs. LSM trees maintain data in two or more separate structures, each of which is optimized for its respective underlying storage medium; data is synchronized between the two structures efficiently, in batches.
⇧ ってな感じで、アルゴリズムが異なってくるらしい。
⇧ なんか「Log-structured merge-tree」については「Other trees」っていうザックリとした分類のされ方をしとりますな...
「テーブル」についてのデータってどう管理されてる？
で、俄然、気になってくるのが、「データベース」で「テーブル」とかを作成した場合に、どういう感じで「データ」は管理されてるのかってことよね。
ちなみに、
⇧ 2021年10月時点で、ネット上で興味を持たれてるであろう「storage engine（database engine）」のランキングを見る限り、Oracleさんの上位ランクインは不動の模様。
というわけで「MySQL 8.0」の「InnoDB」の例になっちゃうけど、
⇧ ってな感じで、最終的には「ディスク」に格納されるっぽい。
ただ、
オラクルは大規模データ分析を高速に行うためのデータベースサービス「MySQL Database Service with HeatWave」（以下、HeatWave）を昨年12月に発表、提供を開始しています。
⇧ ってな感じで、「MySQL」でも「インメモリ」で管理する仕組みも出てきたらしい。
ちなみに、Oracleさん、「Oracle Database」のほうでは、「Oracle TimesTen In-Memory Database(TimesTen)」っていう「インメモリ」な仕組みが存在してたらしい。
Oracle In-Memory Database Cache(IMDB Cache)は、Oracle Databaseの製品オプションであり、アプリケーション層におけるレスポンス時間を向上させる目的で、パフォーマンス重視のOracle Databaseのサブセットをキャッシュするのに役立ちます。
Oracle TimesTen In-Memory DatabaseおよびOracle In-Memory Database Cache
ディスク・ベースのRDBMSがそのすべてのデータをメイン・メモリー内に保持するように構成されている場合でも、ディスク・ベース・データの常駐という前提がパフォーマンスの足かせになります。これらの前提は、処理ロジック、索引付けスキーム、データ・アクセス・メカニズムなどについてハードコードされているため、簡単に変更できません。
Oracle TimesTen In-Memory DatabaseおよびOracle In-Memory Database Cache
TimesTenは、データがメイン・メモリーに常駐するという認識で設計されているため、データへのより直接的な経路を選択し、コード・パスの長さを短縮してアルゴリズムおよび構造を簡素化できます。
Oracle TimesTen In-Memory DatabaseおよびOracle In-Memory Database Cache
⇧ ってな感じで「ディスク」ベースの「RDBMS」との比較をイメージ図として掲載してくれています。
「HeatWave Turbochanges MySQL Database Service」って資料によると、
⇧「storage engine（database engine）」の違いで「データベース」を区別してる感じなんかな、「ベンダー」に「GCP（Google Cloud Platform）」が無いのは「GCP（Google Cloud Platform）」がオリジナルな「データベース」を扱ってないってことなんかな？
「Spanner」とかは、Googleのオリジナルな「分散データベース」って言えると思うんだけども...
「インメモリ」な「データベース」に限定って話なら、「Memorystore」ってものもあるとは思うけども...
あれかな、
Google LLC v. Oracle America, Inc. was a legal case within the United States related to the nature of computer code and copyright law. The dispute centered on the use of parts of the Java programming language's application programming interfaces (APIs) and about 11,000 lines of source code, which are owned by Oracle (through subsidiary, Oracle America, Inc., originating from Sun Microsystems), within early versions of the Android operating system by Google. Google has since transitioned Android to a copyright-unburdened engine without the source code, and has admitted to using the APIs but claimed this was within fair use.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.
⇧ JavaのAPIにまつわる裁判が禍根となってるのかしら...
「索引（インデックス）」についてのデータはどう管理されてる？
また、「MySQL」の例になってしまうけども、
MySQL プラガブルストレージエンジンアーキテクチャーを採用すると、データベースの専門家は、特定のアプリケーションニーズに特化したストレージエンジンを選択でき、さらにアプリケーションの特定のコーディング要件を管理する必要が完全になくなります。 MySQL サーバーのアーキテクチャーにより、アプリケーションプログラマと DBA はストレージレベルのすべての実装詳細から解放され、一貫した容易なアプリケーションモデルと API が得られます。 したがって、異なるストレージエンジンの機能には違いがありますが、アプリケーションはその違いから解放されます。
https://dev.mysql.com/doc/refman/8.0/ja/pluggable-storage-overview.html
プラガブルストレージエンジンのアーキテクチャーは、すべての基になるストレージエンジンに共通の管理およびサポートサービスの標準セットを提供します。 ストレージエンジン自身は、物理サーバーレベルで保守される基になるデータに対してアクションを実際に実行するデータベースサーバーのコンポーネントです。
https://dev.mysql.com/doc/refman/8.0/ja/pluggable-storage-overview.html
⇧ ってな感じで、物理的な「File System」の中で「Files & Logs」として管理されることになるらしい、「Index」ってのも「Files & Logs」に含まれてるっぽいので。
「Oracle Database 12C」のドキュメントだと、
⇧ ってな感じで、
- Logical Structures
- Physical Structures
- Fast Recovery Area
3つの領域に分けてデータを管理する仕組みになってる模様。
最新のドキュメントでも、
Oracle Databaseでは、データベース内のすべてのデータに対して論理領域が割り当てられます。
データベース領域の論理単位は、データ・ブロック、エクステント、セグメントおよび表領域です。物理レベルでは、データはディスク上のデータ・ファイル内に格納されます。データファイル内のデータは、オペレーティング・システムのブロックに格納されます。
⇧ ってな感じで、「データベース」の「データ」ってのは、最終的には、「OS（Operation System）」の「メモリ」ないしは「ディスク」に割り当てられるってことになるんかね。
というのも、
ファイルシステムは、コンピュータのリソースを操作するための、オペレーティングシステム (OS) が持つ機能の一つ。ファイルとは、主に補助記憶装置に格納されたデータを指すが、デバイスやプロセス、カーネル内の情報といったものもファイルとして提供するファイルシステムもある。
⇧「ファイルシステム」が「OS（Operation System）」の持つ機能の1つらしく、「データベース」が「ファイル」で「データ」を管理してるとなっているので、「Oracle Database」の例だけど。
「データベース」における「ブロック」と「ページ」の関係って？
「ブロック」については、Wikipediaさんによりますと、
コンピューティング、特に記憶装置とデータ転送において、ブロック（英: Block）とは、ある一定の長さ（ブロックサイズ）のバイトまたはビットの並びである。そのようなデータは「ブロック化」されていると言われる。ブロック化は、そのデータを受け取るコンピュータプログラムにとって装置の物理的特性を抽象化し、データストリームを扱いやすくするために行われる。
- オペレーティングシステムあるいはファイルシステムがHDDなどの外部デバイスとのデータ読み書きを行うインターフェースにおけるデータの最小単位
- データベース管理システム(DBMS)が記憶装置とのデータのやり取りを行うインターフェースにおけるデータの最小単位
- フラッシュメモリにおいて、消去操作を行うデータの最小単位
⇧ ってな感じで、「データベース」の世界においては、上記のような説明になってますと。
で、「ページ」はと言うと、「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」の「データベーススペシャリスト」の過去問によると、
⇧ ってな感じで、『RDBMSとストレージ間の入出力単位を「ページ」という。』ってなっていて、それ以上でもそれ以下でもない、異論は認めない的な感じで、曖昧なことこの上ない抽象的な表現ですと...
まぁ、「RDBMS（Relational DataBase Management System）」にもいろいろ種類があって、各々で実装が違ってきてるからして、漠然と「RDBMS」で括られることに違和感を感じてしまうよね...
で、改めて、「Oracle Database」について「ストレージ」とやり取りしてるのは、
⇧「論理記憶域と物理記憶域の説明」を見た感じで、
- Data File
- Oracle data block
のどっちかしかないと。（上図の赤枠は勝手に追加してます）
「OS block」が「ストレージ」側に属するものって前提で考えて話を進めることにさせていただきます。
で、各々の説明を見てみると、
■Data File
データファイルの概要
オペレーティング・システム・レベルで、Oracle Databaseはデータ・ファイルと呼ばれる構造にデータを格納します。CDBまたはPDBのどちらでも、すべてのOracleデータベースには、少なくとも1つのデータ・ファイルが必要です。
Oracle Databaseでは、表領域データがデータファイルに物理的に格納されます。
■Oracle data block
データ・ブロックの概要
Oracle Databaseでは、データベースのデータファイル内の論理記憶域は、データ・ブロックと呼ばれる単位で管理されます(データ・ブロックは、Oracleブロックまたはページとも呼ばれます)。データ・ブロックは、データベースI/Oの最小単位です。
データ・ブロックとオペレーティング・システム・ブロック
物理レベルでは、データベースのデータは、オペレーティング・システム・ブロックによって構成されているディスク・ファイル内に格納されます。
オペレーティング・システム・ブロックは、オペレーティング・システムが読取りまたは書込みできるデータの最小単位です。一方、Oracleブロックは、論理記憶域構造であり、そのサイズや構造はオペレーティング・システムには認識されません。
⇧ ってな感じで、「Oracle data block」の説明に、『データ・ブロックは、Oracleブロックまたはページとも呼ばれます』って記載があったので、「ブロック」と「ページ」は同じものを指すってことになるんじゃないかと。
厳密には、「OS（Operation System）」側の「ブロック」と「データベース」側の「ブロック」で若干、意味合いが違うらしいけど、「データベース」内の閉じた話の中では、
って解釈で良いらしいのではないかと、少なくとも「Oracle Database」の世界では。
で、「テーブル」の「データ」は、
⇧ 上図のような感じで、「ブロック（ページ）」の「Row Data」部分に格納されるらしい。
「テーブル」の構造や、「ブロック（ページ）」のサイズにもよるとは思いますが、「テーブル」に格納された「データ」の行数（「レコード数」）が多いほど、「ブロック（ページ）」の数も多くなってくるってことですかね。
「索引（インデックス）」と「ブロック（ページ）」の関係って？
「Oracle Database」のドキュメントによると、『データ・ブロックは、データベースI/Oの最小単位です。』ってあるので、少なくとも「Oracle Database」で管理してる「データ」を扱う場合は、「ブロック（ページ）」毎になりますと。
で、「索引（インデックス）」との関係は？
索引は、表または表クラスタに関連するオプションの構造であり、索引によってデータ・アクセスを高速化できる場合があります。
索引は、単一行のデータへの高速なアクセス・パスです。それは実行のスピードにのみ影響を与えます。索引の付いたデータ値では、索引はその値を含んでいる行の位置を直接示すポインタとして機能します。
索引が表の1つ以上の列に存在する場合、データベースで、ランダムに分散している行の小さなセットを表から取得できる場合があります。索引は、ディスクI/Oを削減するための様々な手段のうちの1つです。ヒープ構成表に索引がない場合、そのデータベースでは、値の検索に全表スキャンを実行する必要があります。たとえば、索引付けされていないhr.departments表の位置2700の問合せでは、データベースは、すべてのブロックのすべての行を検索する必要があります。データ量が増加すると、この方法では適切に対応できなくなります。
⇧ ってな感じで、「ブロック（ページ）」毎にアクセスする必要があるので、もし、「索引（インデックス）」が無い場合、
⇧ 現実的ではない話で、仮に、 個の「ブロック（ページ）」があったとして、「ブロック（ページ）」のサイズがすべて32KBだとすると、
のデータが格納されると仮定して、「テーブル」の1レコードの「データ」が「2KB（2048バイト）」とした場合、
のデータを検索することになるのだけど、もし「索引（インデックス）」を活用しているのであれば、検索範囲を絞れるかもしれないということらしい。（今回の例だと、
すべてを検索しなくてもよくなる）
で、
索引ブロックの概要
索引ブロックは、領域を表ブロックとは異なる方法で管理する特殊なタイプのデータ・ブロックです。Oracle Databaseでは、索引ブロックを使用して、索引の論理記憶域を管理します。
⇧「索引（インデックス）」も「ブロック（ページ）」として管理されるということらしい。
まぁ、何が言いたいかと言うと、「データベーススペシャリスト」試験の「午後Ⅱ」の過去問で出てくる「ページ」とか「データページ」とか「ブロック」とかって「用語」が全て同じものを意味しているんであれば、「用語」を統一するか全て同じものを意味しているって説明が欲しいんですよね...
また貴重な時間を無駄にしてしまったではないか...
今回はこのへんで。
