Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Uploaded byyassun7010
PPTX, PDF19,145 views

2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx

サイバーエージェントAI事業部の新卒研修で利用したスライドを公開します。

Technology◦
Downloaded 167 times
データベースの歴史 2024年度 AI事業本部研修 データアプリケーション基礎編より抜粋
本章の目的：データベースが必要な理由を知る 様々な製品が登場してきた大まかな流れを理解する どのようにデータベースは発展してきているのか？ ざっくりとしたデータベースの分類とその特徴は？ 2 � �
そもそもデータベースっているの？ 3
これではダメなのか？ 4
データベースを使う理由は永続化 これではダメなのか？ ダメ 電源が落ちるとデータが消 える。 5
じゃあ、ファイルで保存すれば良いのでは？ 最も原始的なデータベース （フラットファイルデータベース） 応答性 耐障害性 同時アクセス 色々と要求が出てくる 6
データ管理システム データベース 業務上のトランザクションデータを管理 整合性を維持しながら迅速に処理 データウェアハウス データベースと区別して呼ぶ場合は 大量のデータを保存・分析が主眼 小さなデータの頻繁なアップデート データの大量集計 7
大まかなデータベースの潮流 【階層型】 黎明期 ~1970 【ネットワーク】 RDB 1970〜 みんなが模索中... 数学を基にした強力な理論 SQLというデータ操作言語 これで十分な課題がほとんど NoSQL 2000〜 扱うデータ量が増大 分散処理が重要な時代に データの整合性を妥協 NewSQL 2010〜 分散処理できることを前提に NoSQL で犠牲にされた トランザクションも希求 8
大まかなデータベースの潮流 【階層型】 黎明期 ~1970 【ネットワーク】 RDB 1970〜 みんなが模索中... 数学を基にした強力な理論 SQLというデータ操作言語 これで十分な課題がほとんど NoSQL 2000〜 扱うデータ量が増大 分散処理が重要な時代に データの整合性を妥協 NewSQL 2010〜 分散処理できることを前提に NoSQL で犠牲にされた トランザクションも希求 9
大まかな DB のタイプ分け ・DBをタイプ別にまとめたもの(2011の記事) 10 �
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 11
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 12
リレーショナルモデル（関係モデル） ・1970年にエドガー・F・コッド博士が考案 ・データベースを抽象化し、以下の問題を回避 ・シンプルなデータ表現・データ構造→リレーション ・高水準な言語によるデータ操作→SQL ・データの独立性（一昔前はデータがプログラムと結びついていた） https://book.impress.co.jp/pr/PDF/S_Database_01.pdf ・論文発表以降、関係モデルに準拠するDBMSの開発・商業化が進み、デファクトとなる ・伝統的に、DBMSといえば関係モデル準拠を指す（正確にはRDBMS） ※ あえて DBMS (Database Management System) と呼ぶことがない。あって当たり前の時代... エドガー・F・コッド博士 13
リレーション ● リレーション（テーブル） ○ スキーマ：データの構造や制約の定義 ○ インスタンス：スキーマを満たす実際の集合 ● 属性（列、フィールド） ● タプル（行、レコード） ○ 属性値の集合、何らかの事実 ○ インスタンス ＝ タプルの集合 ＝ ”似たような事実の集まり”
SQL（Structured Query Language） 長年市場を支配しているデータ操作言語 なぜ SQL は強いのか？ ● 数学的な理論背景が強固 （関係モデルと完全な一致はしない） ● 強力な表現力 ● 方言のばらつきが少ない （SQL標準に準拠できている DB ほど好感度が高い） 15
SQL クエリの基本的な流れ クエリの実行 結果の表示 FROM JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY LIMIT 16 ※ 実践編で説明
おまけ）リレーションと表の違い 似ているが異なる  リレーションは順番を持たない（ORDER BY はリレーションモデルにはない）  リレーション同士を関連するキーを用いて結合し、新たなリレーションを作成できる User Company Company User 結合(Join) 制限(Filter) 射影(Projection) 17
おまけ）NULL 撲滅委員会 SQL は NULL 安全な言語ではない 3 値論理や NULL 伝搬の罠があるので NULL の扱いには注意が必要 x Not x T F F T U U AND T F U T T F U F F F U U U U U OR T F U T T T T F T F U U T U U  100 + NULL => NULL  NULL / 0 => NULL  CONCAT('ABC', NULL) => NULL ３値論理 NULL 伝搬 https://mickindex.sakura.ne.jp/database/db_getout_null.html 18 ※ WHERE 句の条件式が NULL の場合 選択されない。エラーにならない点が厄介
データベースの信頼性を担保するための仕組み。 トランザクションの中（BEGIN ~ COMMIT）で信頼性が担保される。 背景となる考え方： ● 複数の書き込みによる競合問題を上手く解決したい ● データの書き込みに失敗したら失敗前の状態に戻って欲しい トランザクション 19 BEGIN; … UPDATE …; … COMMIT; �
ACID ：トランザクションが持つべき性質 データベースの信頼性を担保するための仕組み。 提供される保証は ACID という略語で表現されてきた A(Atomicity): 原子性 中断可能性。処理の開始と終了の中間の状態（中途半端な状態）が存在しないこと C(Consistency): 一貫性 不整合な状態がないこと。実はデータベースだけではなく、アプリ側でも保証 が必要 I(Isolation): 分離性 複数の処理のそれぞれが、互いのデータに影響を与えず実行できること D(Durability): 永続性 データベースのプロセスがクラッシュしても、成功したデータが失われないこと https://qiita.com/immrshc/items/efc8cb31226da297c9b4 20
トランザクションにおける異常の分類 SQL の標準仕様（SQL:1992）に定義されているのは下記の３つ。 実際には問題をさらに細分化でき、同じ保証レベルを謳っていてもデータベースによって保証内容は異なる ダーティリード 他のトランザクションがコミットしていないデータを読み取る現象 反復不能読み取り 同一トランザクション内で同じデータを読み取る際に、 他のトランザクションの更新による影響で結果が変わる現象 ファントムリード 同一トランザクション内で同じデータを読み取る際に、 他のトランザクションの追加による影響で結果が変わる現象 https://docs.pingcap.com/ja/tidb/stable/transaction-isolation-levels#tidb-transaction-isolation-levels 21
トランザクションの分離レベルの制御 データベースが用意している分離レベルの指定を変える事で、 パフォーマンスと整合性のトレードオフを選択する https://www.postgresql.jp/document/15/html/transaction-iso.html 高速 低速 危険 安全 ※ 直列化異常 複数のトランザクションを並列実行した結果が、直列で実行した結果と一致しない現象 22 ※ PostgreSQL のデフォルトはリードコミッティド
リレーショナルモデルとは関係ないパフォーマンスを上げるための実用上の機能 ・ 本でいう索引機能 ・ 高速に保存場所を検索できる仕組み 関連用語 主キー：レコードを一意に特定できるキー サロゲートキー：人工的な値を使った主キー インデックス 23 （年齢順）
RDB のインデックスの主なデータ構造は BTree ※1 ※2 取得・挿入・削除・範囲指定 全ての性能が高い 24 ※1 複数の種類のインデックスを選択できるデータベースも存在する ※2 データベースでは変異種の B+ tree を使うことが多い。 �
RDB のインデックスの主なデータ構造は BTree ※1 ※2 より小さい データが入る より大きい データが入る Data Disk のデータへアクセス 高速化のためメモリでキャッシュ 25 ※1 複数の種類のインデックスを選択できるデータベースも存在する ※2 データベースでは変異種の B+ tree を使うことが多い。
しばらくリレーショナルデータベースのみで良い時代が続いた... 26
問題１：スケールアウトによって性能が向上する時代に CPU のスケールアップの成長が鈍化、大量のサーバを並べるスケールアウトへ進化 さらに、使用量に合わせてサーバ台数が増減する時代に... サーバのリソースを増減 （アップ・ダウンで表現） サーバの台数を増減 （イン・アウトで表現） サーバ性能を向上 サーバ性能を最適化 スケールアウト スケールイン 1 台 目 2 台 目 1 台 目 2 台 目 スケールアップ スケールダウン 1CPU Mem: 1GB 1CPU Mem: 1GB 27
なんらかの前提（リレーション）を置くことで、得意なことと苦手なことが発生する 問題２：リレーショナルモデルが苦手としたデータ形式 半構造化・非構造化データ グラフ https://tkipf.github.io/graph-convolutional-networks/ 28
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 29
分散耐性を獲得するために生まれた NoSQL（Not Only SQL） 【リレーショナル型】 【NoSQL】 データの一貫性・整合性の担保 テーブル間の結合 大規模データになると顕著に低速化 正確なデータよりも大量のデータを 素早く処理することができる データの一貫性・整合性は弱い 30
BTree の問題点 左右の深さが揃っていると パフォーマンスが良い 片方にデータが偏っていると パフォーマンスが悪い 適度に再配置 スケールアップには強いが、スケールアウトには弱い... ※ インデックスとそれが指すデータは同じサーバ上に存在すると仮定 31 � �
BTree の問題点 適度に再配置 サーバ1 サーバ2 サーバ4 サーバ2 サーバ3 サーバ1 スケールアップには強いが、スケールアウトには弱い... データが分散されていると 再配置の移動が激しい ※ インデックスとそれが指すデータは同じサーバ上に存在すると仮定 32 左右の深さが揃っていると パフォーマンスが良い 片方にデータが偏っていると パフォーマンスが悪い � � �
NoSQL (KeyValue)のデータ構造は HashMap どれだけデータ量が増えても コストは変わらない ※ ただし、範囲指定はできない スケールに対して 最強では！？ 33 �
HashMap 巨大な配列。キー値からハッシュ関数を通してインデックスを計算する キー値 大切な仮定： - ハッシュ関数は十分高速 - ハッシュ値の衝突は起きない ハッシュマップの弱点： キーの比較ができない 条件付き検索をするには全データを 見る必要がある Hash テーブル 34
HashMap は分散に強い 0 1 2 3 9 ハッシュ値を適用にサーバ毎に割り振れば、スケールが容易 キー値 Hash テーブル 35
ちょっと待った！データの一貫性・整合性が弱い理由は？ 分散アーキテクチャは現在を保証することが難しい ● クラウドのサーバーは一部が壊れること前提 （数千台以上のサーバがあるので故障確率も上がる） ● ネットワークは遅延・障害が発生することが前提 その手段の一つとしてレプリケーション（複製）。 全ての複製が常に最新の値 かはわからない （最終的には最新の値に落ち着く → 結果整合性） レプリケーション（複製） 36 分散システム：信頼性のない部品から信頼性のあるシステムを構築 �
データベースのスケールアウトの方針 レプリケーション（複製） パーティション（分割） 37
パーティションキー 分散アーキテクチャの方針の一つである パーティションやシャーディングに用いられるもの どのクラスターにデータを保存するかを決めるためのカラム パーティションごとのデータ量の最適化をしないと、 逆に性能が悪化することもあるので注意 ※ パーティションは十分データが溜まった後でやった方が良いことも パーティション（分割） 38
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 39
NoSQL の KeyValue型 と Document型 の違い 値として何を格納するのか（単一型・複合型）の違い 半構造化データ（JSON・xml）への対応 40
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 41
NoSQL（Graph型） SNS などのユーザの関係性を表現するのに向いたデータベース RDB が苦手なグラフ問題に特化している （RDBでは閉包テーブル・経路列挙などがある） 逆に、テーブル表現は苦手 42
データベースの種類 分類 データベースの種類 得意なところ 不得意なところ RDB RDB テーブル同士がさまざまな関係・関連を持つシ ステム 高速な読み込み、書き込みや大規模アクセス、 水平スケールが求められるシステム NoSQL キーバリュー型 大規模な同時アクセス性能が求められるシステ ムや単純なデータへのアクセスで完結するサー ビス RDBMS のようにテーブル同士に複雑な関係・ 関連が必要なシステム ドキュメント型 あらかじめデータ型や定義を決める必要がない JSON や XML で定義されたデータを扱うシス テム グラフ型 ユーザとユーザの繋がりや駅と駅を結ぶ路線情 報などの繋がりを扱うシステム RDBMS のように表形式でのデータ保持を求め られるシステム インメモリ型 セッション情報などの高速なアクセスを必要と するシステム 永続的なデータの保存が求められるシステム 43
インメモリデータベース 大容量ディスク時代の既存データベース データはディスクにある メモリはディスクのキャッシュ シーケンシャルアクセスでパフォーマンスを上げる思想 （ページングにまとめてキャッシュヒット率を上げる） https://www.docswell.com/s/kumagi/KDEEP4-transactions-design-and-evolution#p24 大容量メモリ時代のデータベース データはメモリにある ログから再現したスナップショットをディスク保存 メモリ上のデータとディスク上のデータが 一致するとは限らない 44
あれ？永続化は？ オプションで定期的にディスクIOに書き込む方式が取られている 応答はメモリ内で行い、定期的にデータをまとめ（コンパクト化）、ディスクに書き出す。 つまり、永続化は必須ではない（えぇ...） 45 �
データベースを使う理由は永続化 これではダメなのか？ ダメ。 電源が落ちるとデータが消 える。 アプリケーション間で データ共有ができない これで良かったのではないか？ 46
揮発性インメモリデータベースとハッシュマップの違い キャッシュ用途として使われるが、インメモリデータベースのメリットはいくつかある。 ● 豊富なデータ構造（クライアント言語に依存せず使える） ● アプリケーション間を横断するデータのやり取りが可能 ● スケールアウト可能なインメモリデータベースも存在 ロードバランサ インメモリ データベース API サーバ コピー1 API サーバ コピー2 API サーバ コピー3 47
大まかなデータベースの潮流 【階層型】 黎明期 ~1970 【ネットワーク】 RDB 1970〜 みんなが模索中... 数学を基にした強力な理論 SQLというデータ操作言語 これで十分な課題がほとんど NoSQL 2000〜 扱うデータ量が増大 分散処理が重要な時代に データの整合性を妥協 NewSQL 2010〜 分散処理できることを前提に NoSQL で犠牲にされた トランザクションも希求 CAP定理の CA を重視 限定されたスケーラビリティの範囲内で 可用性と妥当な整合性 CAP定理の AP を重視 整合性を妥協、可用性と ネットワーク分断耐性を重視 CAP定理の CP を重視 妥協された可用性。 整合性と分断体制を重視 48
NewSQL 柔軟なスケーリング、強力な整合性・一貫性を持つRDBMS 【特徴】 ・従来のDBMSの ACID特性 を持つ ・NoSQLのように 分散処理 が可能 ・負荷分散のためのシャーディングなどが不要（自動シャーディング） ・DBへの書き込みが多いサービスに有効 Cloud Spanner https://services.google.com/fh/files/misc/develop_global_multiplayer_games_using_cloud_spanner.pdf?hl=ja https://static.googleusercontent.com/media/research.google.com/ja//archive/spanner-osdi2012.pdf https://www.xenonstack.com/blog/sql-vs-nosql-vs-newsql 49 �
一体どうやって獲得した？ 分散トランザクションという技術分野が発達 ● 2相コミット（全員が合意・次にコミット） ● 書き込みリーダの自動選定 複雑な仕組みと難しいメンテナンスコストが発生する。 Google Cloud Spanner はフルマネージドなサービスとして それらの複雑さを意識しなくて良いサービスを提供している 50
データウェアハウス BigQuery Snowflake DWH製品 このあたり ・大量のデータを取り込んだり、保管する機能を持つ ・データを加工したり、分析することが目的 51
この章の最後に... 52
あれ？ RDB も進化してない？ https://www.fujitsu.com/jp/products/software/resources/feature-stories/postgres/engineer-blog30/ 半構造型のサポート ○ Array ○ JSON（標準SQLにも準拠！） スケールアウトへの対応 ○ パーティション ○ レプリケーション ベンダー側も市場のニーズに 無頓着なわけではない！ 大まかな分類の解釈を読むだけでなく 最新の状況は追わなければならない 53
潮流を支える技術変化 スケールアップの限界 CPU単体の性能が頭打ち 性能の向上は高速化ではなく、 並列化で達成するように → 分散システムの技術が発達 ストレージ技術の変化 ハードディスクからメモリを前提 とした方法へ → 使用するアルゴリズムが変化 ネットワークの高速化 IOバウンドの問題が 昔ほど深刻ではなくなってきた → 調停などの複雑な会話も 現実的な応答速度に ソフトウェアの進化がハードウェアの進化に寄り添っていることがわかる 54