データベースに出てくる「ページ」と「ブロック」って?

f:id:ts0818:20211006185342j:plain

www.itmedia.co.jp

 米Facebookは10月5日(現地時間)、前日の日中に発生したInstagramやOculusも含むすべてのサービスに影響した障害について、その原因と復旧方法について説明した。

Facebook、約6時間にわたる障害の原因と対策を詳解 - ITmedia NEWS

 復旧と並行して、原因が「悪意のあるアクティビティ」かどうかも調査したが、そうではなく、人為的なエラーが原因だったとしている。

Facebook、約6時間にわたる障害の原因と対策を詳解 - ITmedia NEWS

⇧ まぁ、時間がかかったとしても、しっかり復旧ができて、原因もハッキリしたということで、当事者もモヤモヤ感は無くて良いですよね。

Facebook社の経済損失はえげつないことになってるみたいですけど、日本だとFacebookってあまり積極的に利用されてないようなイメージあるんですが、影響はどの程度あったのか気にはなりますね。

ただ、世の中、そんな幸せなシステムばかりでもないってことは、皆々様、ご存知の通りです。

biz-journal.jp

 さらに9月30日午後、システムの不具合により387件の外国為替取引に遅れが出た。今年8度目の障害である。法人顧客の送金が滞り、一部は翌10月1日に持ち越されたようだ。原因は特定できていない。

みずほ銀行、解体論も浮上…4千億円で刷新したシステム、障害続出で制御不能

⇧「原因は特定できていない。」という言葉の重さ...

これ、障害対応してるメンバが直面してるストレスは尋常じゃない気がする...

 三菱UFJ銀行三井住友銀行は合併の際に基幹システムを、合併を主導する銀行に片寄せした。片寄せというのは一本化することだ。ところが、みずほ銀行は前身である第一勧業銀行、富士銀行、日本興業銀行の3行の主導権争いが激しく、それぞれのシステムを存続させる形で経営統合した。その結果、統合初日の2002年4月、大規模なシステム障害が起き、250万件の口座振替などで遅れや誤処理が発生した。

みずほ銀行、解体論も浮上…4千億円で刷新したシステム、障害続出で制御不能

 みずほ銀行の勘定系システムは第一勧銀の富士通製、営業店システムの端末には富士銀が使っていた日本IBM製を採用。みずほコーポレート銀行は興銀の日立製をそのまま使った。

みずほ銀行、解体論も浮上…4千億円で刷新したシステム、障害続出で制御不能

⇧ もう、現行稼働してるシステムで利用されてる「富士通」「日本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.

https://en.wikipedia.org/wiki/Database

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.

https://en.wikipedia.org/wiki/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.

https://en.wikipedia.org/wiki/Database

⇧ コンピュータ上で、整理された「データ」を扱うことができますと。

それって、「Excel」とかでも「データ」扱えるやん?って思った方、鋭い!

そんな疑問に回答してくださってるのが、

enterprisezine.jp

⇧ 上記サイト様になりますと。

 

データベースの仕組みって?

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.

https://en.wikipedia.org/wiki/Database

Putting data into permanent storage is generally the responsibility of the database engine a.k.a. "storage engine". 

https://en.wikipedia.org/wiki/Database

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.

https://en.wikipedia.org/wiki/Database

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).

https://en.wikipedia.org/wiki/Database

⇧ 超ザックリ要約すると、『「storage engine(database engine)」でデータを「永続化(permanent)」する』ってことらしい。

何で「永続化」するかというと、

In computer scienceACID (atomicityconsistencyisolationdurability) 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.

https://en.wikipedia.org/wiki/ACID

According to Gray and Reuter, the IBM Information Management System supported ACID transactions as early as 1973 (although the acronym was created later).

https://en.wikipedia.org/wiki/ACID

⇧ 有名な「ACID (atomicityconsistencyisolationdurability) 」の性質が関わってますと。

  • 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(耐久性)

この「ACID」の性質の「Durability(耐久性)」が「永続化」のことを意味してるらしい。

「storage engine(database engine)」のザックリとした概要なんかについては、

blog.yugabyte.com

⇧ 上記サイト様がイメージしやすいかと。

「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.

https://en.wikipedia.org/wiki/B-tree

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.

https://en.wikipedia.org/wiki/B-tree

■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.

https://en.wikipedia.org/wiki/Log-structured_merge-tree

⇧ ってな感じで、アルゴリズムが異なってくるらしい。

⇧ なんか「Log-structured merge-tree」については「Other trees」っていうザックリとした分類のされ方をしとりますな...

 

「テーブル」についてのデータってどう管理されてる?

で、俄然、気になってくるのが、「データベース」で「テーブル」とかを作成した場合に、どういう感じで「データ」は管理されてるのかってことよね。

ちなみに、

db-engines.com

⇧ 2021年10月時点で、ネット上で興味を持たれてるであろう「storage engine(database engine)」のランキングを見る限り、Oracleさんの上位ランクインは不動の模様。

というわけで「MySQL 8.0」の「InnoDB」の例になっちゃうけど、

dev.mysql.com

⇧ ってな感じで、最終的には「ディスク」に格納されるっぽい。

ただ、

www.publickey1.jp

HeatWaveは、オラクルが開発したカラム型の分散インメモリデータベースエンジンを搭載し、超高速な大規模データの分析を可能にするフルマネージドなクラウドサービスです。

MySQLの新製品「HeatWave」はInnoDBの最大400倍高速、テラバイト級を超える大規模データを分析可能なインメモリデータベース。スクエニやSCSKがその性能を検証[PR] - Publickey

⇧ ってな感じで、「MySQL」でも「インメモリ」で管理する仕組みも出てきたらしい。

ちなみに、Oracleさん、「Oracle Database」のほうでは、「Oracle TimesTen In-Memory Database(TimesTen)」っていう「インメモリ」な仕組みが存在してたらしい。

docs.oracle.com

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)」の違いで「データベース」を区別してる感じなんかな、「ベンダー」に「GCPGoogle Cloud Platform)」が無いのは「GCPGoogle 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.

JavaAPIにまつわる裁判が禍根となってるのかしら... 

 

「索引(インデックス)」についてのデータはどう管理されてる?

また、「MySQL」の例になってしまうけども、

dev.mysql.com

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」のドキュメントだと、

docs.oracle.com

⇧ ってな感じで、

  • Logical Structures
  • Physical Structures
  • Fast Recovery Area

3つの領域に分けてデータを管理する仕組みになってる模様。

最新のドキュメントでも、

docs.oracle.com

Oracle Databaseでは、データベース内のすべてのデータに対して論理領域が割り当てられます。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-52FE1A8C-74EA-4B81-B1AC-69FD34252659

データベース領域の論理単位は、データ・ブロック、エクステント、セグメントおよび表領域です。物理レベルでは、データはディスク上のデータ・ファイル内に格納されます。データファイル内のデータは、オペレーティング・システムのブロックに格納されます。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-52FE1A8C-74EA-4B81-B1AC-69FD34252659

⇧ ってな感じで、「データベース」の「データ」ってのは、最終的には、「OS(Operation System)」の「メモリ」ないしは「ディスク」に割り当てられるってことになるんかね。

というのも、

ファイルシステムは、コンピュータリソースを操作するための、オペレーティングシステム (OS) が持つ機能の一つ。ファイルとは、主に補助記憶装置に格納されたデータを指すが、デバイスプロセスカーネル内の情報といったものもファイルとして提供するファイルシステムもある。

ファイルシステム - Wikipedia

⇧「ファイルシステム」が「OS(Operation System)」の持つ機能の1つらしく、「データベース」が「ファイル」で「データ」を管理してるとなっているので、「Oracle Database」の例だけど。

 

「データベース」における「ブロック」と「ページ」の関係って?

「ブロック」については、Wikipediaさんによりますと、

コンピューティング、特に記憶装置データ転送において、ブロック: Block)とは、ある一定の長さ(ブロックサイズ)のバイトまたはビットの並びである。そのようなデータは「ブロック化」されていると言われる。ブロック化は、そのデータを受け取るコンピュータプログラムにとって装置の物理的特性を抽象化し、データストリームを扱いやすくするために行われる。

ブロック (データ) - Wikipedia

たとえば、 

といったものがある。 

ブロック (データ) - Wikipedia

⇧ ってな感じで、「データベース」の世界においては、上記のような説明になってますと。

で、「ページ」はと言うと、「独立行政法人情報処理推進機構IPA:Information-technology Promotion Agency, Japan)」の「データベーススペシャリスト」の過去問によると、

www.jitec.ipa.go.jp

⇧ ってな感じで、『RDBMSとストレージ間の入出力単位を「ページ」という。』ってなっていて、それ以上でもそれ以下でもない、異論は認めない的な感じで、曖昧なことこの上ない抽象的な表現ですと...

まぁ、「RDBMS(Relational DataBase Management System)」にもいろいろ種類があって、各々で実装が違ってきてるからして、漠然と「RDBMS」で括られることに違和感を感じてしまうよね...

で、改めて、「Oracle Database」について「ストレージ」とやり取りしてるのは、

⇧「論理記憶域と物理記憶域の説明」を見た感じで、

のどっちかしかないと。(上図の赤枠は勝手に追加してます)

「OS block」が「ストレージ」側に属するものって前提で考えて話を進めることにさせていただきます。

で、各々の説明を見てみると、

Data File

データファイルの概要

オペレーティング・システム・レベルで、Oracle Databaseはデータ・ファイルと呼ばれる構造にデータを格納します。CDBまたはPDBのどちらでも、すべてのOracleデータベースには、少なくとも1つのデータ・ファイルが必要です。

https://docs.oracle.com/cd/F39414_01/cncpt/physical-storage-structures.html#GUID-A878011D-2E59-45F6-A529-F60383AAE945

Oracle Databaseでは、表領域データがデータファイルに物理的に格納されます。

https://docs.oracle.com/cd/F39414_01/cncpt/physical-storage-structures.html#GUID-A878011D-2E59-45F6-A529-F60383AAE945

Oracle data block

データ・ブロックの概要

Oracle Databaseでは、データベースのデータファイル内の論理記憶域は、データ・ブロックと呼ばれる単位で管理されます(データ・ブロックは、Oracleブロックまたはページとも呼ばれます)。データ・ブロックは、データベースI/Oの最小単位です。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-1AED5140-E820-436C-BEB7-2A985524911E

データ・ブロックとオペレーティング・システム・ブロック

物理レベルでは、データベースのデータは、オペレーティング・システム・ブロックによって構成されているディスク・ファイル内に格納されます。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-1AED5140-E820-436C-BEB7-2A985524911E

オペレーティング・システム・ブロックは、オペレーティング・システムが読取りまたは書込みできるデータの最小単位です。一方、Oracleブロックは、論理記憶域構造であり、そのサイズや構造はオペレーティング・システムには認識されません。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-1AED5140-E820-436C-BEB7-2A985524911E

⇧ ってな感じで、「Oracle data block」の説明に、『データ・ブロックは、Oracleブロックまたはページとも呼ばれます』って記載があったので、「ブロック」と「ページ」は同じものを指すってことになるんじゃないかと。

厳密には、「OS(Operation System)」側の「ブロック」と「データベース」側の「ブロック」で若干、意味合いが違うらしいけど、「データベース」内の閉じた話の中では、

 ブロック = ページ

って解釈で良いらしいのではないかと、少なくとも「Oracle Database」の世界では。

で、「テーブル」の「データ」は、

⇧ 上図のような感じで、「ブロック(ページ)」の「Row Data」部分に格納されるらしい。

「テーブル」の構造や、「ブロック(ページ)」のサイズにもよるとは思いますが、「テーブル」に格納された「データ」の行数(「レコード数」)が多いほど、「ブロック(ページ)」の数も多くなってくるってことですかね。

 

「索引(インデックス)」と「ブロック(ページ)」の関係って?

Oracle Database」のドキュメントによると、『データ・ブロックは、データベースI/Oの最小単位です。』ってあるので、少なくとも「Oracle Database」で管理してる「データ」を扱う場合は、「ブロック(ページ)」毎になりますと。

で、「索引(インデックス)」との関係は?

docs.oracle.com

索引は、表またはクラスタに関連するオプションの構造であり、索引によってデータ・アクセスを高速化できる場合があります。

https://docs.oracle.com/cd/F39414_01/cncpt/indexes-and-index-organized-tables.html#GUID-DE7A95BC-6E4A-47EA-9FC5-B85B54F8CF41

索引は、単一行のデータへの高速なアクセス・パスです。それは実行のスピードにのみ影響を与えます。索引の付いたデータ値では、索引はその値を含んでいる行の位置を直接示すポインタとして機能します。

https://docs.oracle.com/cd/F39414_01/cncpt/indexes-and-index-organized-tables.html#GUID-DE7A95BC-6E4A-47EA-9FC5-B85B54F8CF41

索引が表の1つ以上の列に存在する場合、データベースで、ランダムに分散している行の小さなセットを表から取得できる場合があります。索引は、ディスクI/Oを削減するための様々な手段のうちの1つです。ヒープ構成表に索引がない場合、そのデータベースでは、値の検索に全表スキャンを実行する必要があります。たとえば、索引付けされていないhr.departments表の位置2700問合せでは、データベースは、すべてのブロックのすべての行を検索する必要があります。データ量が増加すると、この方法では適切に対応できなくなります。

https://docs.oracle.com/cd/F39414_01/cncpt/indexes-and-index-organized-tables.html#GUID-DE7A95BC-6E4A-47EA-9FC5-B85B54F8CF41

⇧ ってな感じで、「ブロック(ページ)」毎にアクセスする必要があるので、もし、「索引(インデックス)」が無い場合、

docs.oracle.com

⇧ 現実的ではない話で、仮に、 2^{22} -1 = 4194304 -1 = 4194303 個の「ブロック(ページ)」があったとして、「ブロック(ページ)」のサイズがすべて32KBだとすると、 4194303 \times 32 \times 1024(バイト)= 137,438,920,704バイト のデータが格納されると仮定して、「テーブル」の1レコードの「データ」が「2KB(2048バイト)」とした場合、 137,438,920,704 \div 2048 = 67,108,848 行 のデータを検索することになるのだけど、もし「索引(インデックス)」を活用しているのであれば、検索範囲を絞れるかもしれないということらしい。(今回の例だと、 67,108,848 行 すべてを検索しなくてもよくなる)

で、

索引ブロックの概要

索引ブロックは、領域を表ブロックとは異なる方法で管理する特殊なタイプのデータ・ブロックです。Oracle Databaseでは、索引ブロックを使用して、索引の論理記憶域を管理します。

https://docs.oracle.com/cd/F39414_01/cncpt/logical-storage-structures.html#GUID-82531CDF-407E-4D70-AFD0-8E8929B72783

⇧「索引(インデックス)」も「ブロック(ページ)」として管理されるということらしい。

まぁ、何が言いたいかと言うと、「データベーススペシャリスト」試験の「午後Ⅱ」の過去問で出てくる「ページ」とか「データページ」とか「ブロック」とかって「用語」が全て同じものを意味しているんであれば、「用語」を統一するか全て同じものを意味しているって説明が欲しいんですよね...

また貴重な時間を無駄にしてしまったではないか...

今回はこのへんで。