JP7362190B2 - ストレージエンジンにおけるデータインデックス付け方法、データインデックス付け装置、コンピュータ装置、及びコンピュータプログラム - Google Patents

Description

本出願は、コンピュータ技術の分野に関し、特に、ストレージエンジンにおけるデータインデックス付けに関する。

本出願は、２０２０年０１月０８日にて中国専利局に提出された、出願号が２０２０１００１８７４６．０であって、発明の名称が「ストレージエンジンにおけるデータインデックス付け方法及び関連装置」である中国特許出願の優先権を主張し、その全内容を本出願に援用する。

クラウド技術の発展に伴い、人々の生活に登場するアプリケーションがますます増えており、クラウド技術では、データインタラクションを実現するために、データベースを必要とする。データベースは、簡単に言えば、電子ファイルが保存される電子ファイリングキャビネットと見なすことができ、ユーザーは、ファイルにおけるデータに対して追加、クエリ、更新、削除などの操作を行うことができる。

一般に、複数のストレージエンジンをサポートするデータベース管理システムであるＭｙＳＱＬを、様々な適用シナリオに使用することができる。ここで、異なるストレージエンジンの、トランザクションに対するサポート能力が異なってもよい。例えば、ＩｎｎｏＤＢストレージエンジンは、完全なトランザクションサポートを実現し、分散トランザクションのＸＡプロトコルもサポートし、ＭｙＩＳＡＭストレージエンジンは、拡張しやすく、また、ＮＥＷＤＢエンジンは、シングルステートメントのトランザクションをサポートする。これにより、様々なシナリオのデータインデックス付けプロセスを実現する。

これに鑑みて、本出願は、ストレージエンジン適用プロセスの複雑さ及びコードの冗長性を効果的に低減し、データインデックス付けプロセスの効率を向上させることができるデータインデックス付け方法を提供する。

一態様では、本出願の実施例は、端末装置におけるデータインデックス付け機能を含むシステム又はプログラムに適用することができるデータインデックス付け方法を提供し、具体的に、
データインデックス付けプロセスを指示するためのターゲットトランザクションを取得するステップと、
前記ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定するステップであって、前記ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれるステップと、
前記第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定するステップであって、前記第２のインデックステーブルは、前記第１のインデックステーブルに基づいて行識別子を追加することによって得られ、前記行識別子は、前記ターゲットインデックスデータにおける行データを指示するためのものであり、前記行データは、前記ターゲットインデックスデータにおけるインデックス列に対応し、前記インデックス列が前記ターゲットトランザクションに基づいて得られ、前記第２のストレージエンジンが前記ターゲットトランザクションの実行をサポートするステップと、
前記第２のインデックステーブルから、前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定するステップであって、前記インデックスデータは、前記ターゲットインデックスデータに含まれるステップと、を含む。

別の態様では、本出願の実施例は、データインデックス付け装置を提供し、
データインデックス付けプロセスを指示するためのターゲットトランザクションを取得するための取得ユニットと、
前記ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定するための決定ユニットであって、前記ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれる決定ユニットと、
前記第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定するマッピングユニットであって、前記第２のインデックステーブルは、前記第１のインデックステーブルに基づいて行識別子を追加することによって得られ、前記行識別子が、前記ターゲットインデックスデータにおける行データを指示するためのものであり、前記行データが、前記ターゲットインデックスデータにおけるインデックス列に対応し、前記インデックス列が、前記ターゲットトランザクションに基づいて得られ、前記第２のストレージエンジンが前記ターゲットトランザクションの実行をサポートするマッピングユニットと、
前記第２のインデックステーブルから、前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定するためのインデックスユニットであって、前記インデックスデータが前記ターゲットインデックスデータに含まれるインデックスユニットと、を含む。

別の態様では、本出願の実施例は、メモリ、プロセッサー及びバスシステムを含むコンピュータ装置を提供し、前記メモリは、プログラムコードを記憶し、前記プロセッサーは、前記プログラムコードにおける命令に基づき、上記の態様で説明したデータインデックス付け方法を実行する。

さらに別の態様では、本出願の実施例は、記憶媒体を提供し、前記記憶媒体は、コンピュータプログラムを記憶し、前記コンピュータプログラムは、上記の態様で説明したデータインデックス付け方法を実行する。

さらに別の態様では、本出願の実施例は、コンピュータ上で実行されるときに、上記の態様のデータインデックス付け方法を前記コンピュータに実行させるための命令を含むコンピュータプログラム製品を提供する。

以上の技術的解決策から分かるように、本出願の実施例は、以下の利点を有する。

データインデックス付けプロセスを指示するためのターゲットトランザクションを取得し、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定し、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれ、次に、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定し、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、行識別子は、ターゲットインデックスデータにおける行データを指示するために使用され、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートし、さらに、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現し、新しいストレージエンジン導入による開発の複雑さが軽減されるため、複数のストレージエンジンのコード再利用を実現し、データベースのインデックス付け効率が向上し、さらに、第２のストレージエンジンの機能設計により、第１のストレージエンジンは、それ自体には搭載されていない機能を実行することができるようになり、データベースの適用範囲及びインデックス付け効率をさらに向上させる。

データインデックス付けシステムの動作のネットワークアーキテクチャ図である。 本出願の実施例によるデータインデックス付けのフローアーキテクチャ図である。 本出願の実施例によるデータインデックス付け方法のフローチャートである。 本出願の実施例によるインデックステーブルの更新フローの概略図である。 本出願の実施例による別のデータインデックス付け方法のフローチャートである。 本出願の実施例によるデータ挿入操作フローの概略図である。 本出願の実施例によるデータリカバリの方法のフローチャートである。 本出願の実施例によるデータインデックス付け装置の構成概略図である。 本出願の実施例による別のデータインデックス付け装置の構成概略図である。

本出願の実施例は、端末装置におけるデータインデックス付け機能を含むシステム又はプログラムに適用することができるデータインデックス付け方法及び関連装置を提供する。データインデックス付けプロセスを指示するターゲットトランザクションを取得し、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定し、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれる。次に、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定し、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、行識別子は、ターゲットインデックスデータにおける行データを指示するためのものであり、行データは、ターゲットインデックスデータにおけるインデックス列に対応し、インデックス列は、ターゲットトランザクションに基づいて得られ、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートする。さらに、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現し、新しいストレージエンジン導入による開発の複雑さが軽減されるため、複数のストレージエンジンのコード再利用を実現し、データベースのインデックス付け効率を向上させる。さらに、第２のストレージエンジンの機能設計により、第１のストレージエンジンは、それ自体には搭載されない機能を実行することができるようになり、データベースの適用範囲及びインデックス付け効率をさらに向上させる。

まず、本出願の実施例に現れるいくつかの用語について説明する。

ＭｙＳＱＬ：リレーショナルデータベース管理システムであり、プラグウインアーキテクチャを使用し、複数のストレージエンジンを同時にサポートすることができる。

ストレージエンジン：データベース管理システムのデータ記憶及びトランザクション管理などの機能を担当し、データベースシステムのコアモジュールである。ＭｙＳＱＬは、複数の異なるストレージエンジンを同時にサポートして、異なるシナリオに最適化されたデータ記憶及びトランザクション管理機能を提供することができ、よく見られるストレージエンジンには、ＩｎｎｏＤＢ、ＭｙＩＳＡＭなどがある。

トランザクション(ｔｒａｎｓａｃｔｉｏｎ)：様々なデータアイテムにアクセスし操作する１つのデータベース操作シーケンスである。トランザクションは、トランザクションの開始からトランザクションの終了までの間に実行される全てのデータベース操作で構成される。トランザクションには、ＡＣＩＤ特性、即ち、原子性(Ａｔｏｍｉｃｉｔｙ)、一致性(Ｃｏｎｓｉｓｔｅｎｃｙ)、分離性(Ｉｓｏｌａｔｉｏｎ)、耐久性(Ｄｕｒａｂｉｌｉｔｙ)がある。

データベーススキーマ定義言語(Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ、ＤＤＬ)：即ち、データベーススキーマ情報であり、データベースに格納されるライブラリテーブルの構成を記述するための言語である。例えば、ＣＲＥＡＴＥ、ＡＬＴＥＲ、ＤＲＯＰなどがある。

データ操作言語(Ｄａｔａ Ｍａｎｉｐｕｌａｔｉｏｎ Ｌａｎｇｕａｇｅ、ＤＭＬ)：即ち、ユーザーがデータベースに対する基本的な操作を実現するためのデータ操作情報である。例えば、ＩＮＳＥＲＴ、ＤＥＬＥＴＥ、ＵＰＤＡＴＥなどがある。

ＸＡメカニズム：データベース接続トランザクションにおけるＸＡは、Ｘ／Ｏｐｅｎ組織によって提案された分散トランザクション処理の仕様を指す。

行識別子(ｒｏｗｎｏ)：テーブルにおける現在の列セグメントデータの現在の行数を返すための関数識別子であり、即ち、行データのセット識別子である。

行データ：インデックステーブルにおける同じキー値に対応するインデックス値のセットである。

インデックステーブル：論理レコードと物理レコードの対応関係を示すテーブルであり、データベースにおけるデータを識別するためのものである。

なお、本出願によって提供されるデータインデックス付け方法は、データベースを含むか、又は、データの読み書きを必要とするシステム又はプログラム、例えば、ＭｙＳＱＬデータベース又はＭｙＳＱＬに基づいて実行される関連プログラムなどに適用することができ、具体的に、データインデックス付けシステムは、図１に示すシステムアーキテクチャで実行でき、図１に示すように、データインデックス付けシステムの動作のシステムアーキテクチャ図であり、以下に、ＭｙＳＱＬを例として説明する。ＭｙＳＱＬは、アクセス層、サービス層、ストレージエンジン層及びシステムファイル層を含み、アクセス層は、主に接続処理、認可認証、セキュリティなどの事項を担当し、サービス層は、主に、クエリ解析、分析、最適化、キャッシュ及び全ての組み込み関数を担当し、ストレージプロセス、トリガー、ビュー、ｂｉｎｌｏｇ、テーブルログなどのストレージエンジンを跨ぐ全ての機能は、この層で実現される。ストレージエンジン層は、主に、ＭｙＳＱＬにおけるデータのストレージ及び抽出を担当し、サービス層は、ＡＰＩを介してストレージエンジンと通信し、ストレージエンジンは、数十個のロウワー関数ＡＰＩを含み、各エンジンは、一連の特定の実現を提供し、システムファイル層は主に、ロウワーファイルシステムの読み書きを担当する。本出願によって提供されるデータインデックス付け方法は、ストレージエンジン層のプラグインタイプに設置された複数のストレージエンジンのインタラクションプロセスに適用でき、第１のストレージエンジンのトランザクションを第２のストレージエンジンを介して再利用することで、ロウワー関数の統合適用を実現する。なお、図面は、１つの第１のストレージエンジン及び１つの第２のストレージエンジンを示しているが、実際のシナリオでは、より多くの第１のストレージエンジン又はより多くの第２のストレージエンジンであってもよく、具体的な数は、実際のシナリオによって決定され、ここでは制限しない。具体的に、ストレージエンジンのタイプは、ＩｎｎｏＤＢ、ＭｙＩＳＡＭ又はＮＥＷＤＢなどであってもよい。

なお、上記のデータインデックス付けシステムは、サーバー上で実行でき、例えば、クラウドデータストレージのアプリケーションとして、端末装置上で実行することができ、サードパーティー装置で実行して、データインデックスを提供して、データインデックス付け後のノード分散結果を取得することもでき、具体的に、データインデックス付けシステムは、プログラムの形態で上記の装置上で実行でき、上記の装置におけるシステム構成要素として実行することもでき、クラウドサービスプログラムの１つとして使用してもよく、具体的実行モードは、実際のシナリオに応じて決定され、ここでは、制限しない。

本出願の実施例は、クラウド技術(Ｃｌｏｕｄ ｔｅｃｈｎｏｌｏｇｙ)の適用であってもよく、クラウド技術とは、ワイドエリアネットワーク又はローカルネットワークにおいてハードウェア、ソフトウェア、ネットワークなどの一連のリソースを統合して、データの計算、記憶、処理及び共有を実現するホスティング技術である。

具体的に、クラウド技術は、クラウドコンピューティングビジネスモードに適用されるネットワーク技術、情報技術、統合技術、管理プラットフォーム技術、アプリケーション技術などの総称であり、リソースプールを形成でき、オンデマンドで柔軟かつ便利に使用できる。クラウドコンピューティング技術は、重要なサポートになる。ビデオウェブサイト、写真ウェブサイト及びその他のポータルウェブサイトなどの技術ネットワークシステムのバックグラウンドは、大量の計算、記憶リソースを必要とする。インターネット業界の高度な発展及び適用により、将来、各製品に独自の認識マークが作成られる可能性があり、バックグラウンドシステムに送信して論理処理する必要があり、異なるレベルのデータは個別に処理され、各種の業界データは、強力なシステムバッキングサポートを必要とし、クラウドコンピューティングによって実現するしかない。

クラウド技術では、データベースの参加が必要である。データベースは、簡単に言えば、電子ファイルが保存される電子ファイリングキャビネットと見なすことができ、ユーザーは、ファイルにおけるデータに対して追加、クエリ、更新、削除などの操作を行うことができる。

「データベース」とは、特定の方式で一緒に記憶され、複数のユーザーと共有でき、可能な限り小さい冗長性を有し、アプリケーションプログラムと互いに独立しているデータセットである。

データベース管理システム(Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、ＤＢＭＳ)は、データベースを管理するために設計されたコンピュータソフトウェアシステムであり、一般的に、ストレージ、インターセプト、セキュリティ、バックアップなどの基本的な機能を有する。データベース管理システムは、そのサポートするデータベースモデルに基づき、例えばリレーショナル、ＸＭＬなどに分類でき、又は、そのサポートするコンピュータのタイプに基づき、例えばサーバークラスター、携帯電話などに分類でき、又は、使用するクエリ言語に基づき、例えばＳＱＬ、ＸＱｕｅｒｙなどに分類でき、又は、パフォーマンスインパルスの焦点、例えば最大規模、最大実行速度などに基づき分類でき、他の分類方式もある。使用する分類方式に関係なく、一部のＤＢＭＳは、例えば、複数のクエリ言語を同時にサポートするなど、カテゴリを跨ることができる。

クラウド技術の発展に伴い、人々の生活に登場するアプリケーションはますます増えており、クラウド技術では、データのインタラクションを実現するために、データベースの参加を必要とする。

一般的に、複数のストレージエンジンをサポートするデータベース管理システムであるＭｙＳＱＬを異なる適用シナリオに使用することができる。異なるストレージエンジンは、トランザクションのサポート能力が異なる。例えば、ＩｎｎｏＤＢストレージエンジンは、完全なトランザクションのサポートを実現し、分散トランザクションのＸＡプロトコルもサポートし、ＭｙＩＳＡＭストレージエンジンは、簡単に拡張でき、また、ＮＥＷＤＢエンジンは、シングルステートメントのトランザクションをサポートし、これにより、様々なシナリオのデータインデックス付けプロセスを実現する。

しかしながら、ＭｙＳＱＬのプラグインアーキテクチャでは、各ストレージエンジンのコードは独立しており、１つの新しいストレージエンジンを開発するたびに、完全なデータ記憶及びトランザクションメカニズムを個別に開発する必要があり、この開発プロセスの複雑さは高く、コードの冗長性を引き起こしやすく、データベースのインデックス付け効率に影響を与える。

上記の課題を解決するために、本出願は、データインデックス付け方法を提案し、当該方法は、図２に示すデータインデックス付けプロセスのフレームワークに適用され、図２に示すように、本出願の実施例によって提供されるデータインデックス付けのフローアーキテクチャ図であり、第１のストレージエンジンを介してターゲットトランザクションにアクセスし、ターゲットトランザクションに基づいて、第２のストレージエンジンにおいてインデックステーブルのマッピングを実行し、これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現する。一般的に、第２のストレージエンジンは、例えば、ＩｎｎｏＤＢなどの、完全なトランザクション機能を備えたストレージエンジンを使用するため、第１のストレージエンジンは、ストレージエンジン層におけるロウワー関数を簡単に再利用して、データインデックス付けプロセスを実行することができる。

なお、本出願によって提供される方法は、ハードウェアシステムにおける処理論理として、プログラムの記述であってもよく、集積又は外作成の方式で上記の処理論理を実現するためのデータインデックス付け装置としてもよい。１つの実現方式として、当該データインデックス付け装置は、データインデックス付けプロセスを指示するターゲットトランザクションを取得し、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定し、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれる。次に、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定し、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、行識別子は、ターゲットインデックスデータにおける行データを指示するためのものであり、行データは、ターゲットインデックスデータにおけるインデックス列に対応し、インデックス列は、ターゲットトランザクションに基づいて得られ、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートし、さらに、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現し、新しいストレージエンジン導入による開発の複雑さが軽減されるため、複数のストレージエンジンのコード再利用を実現し、データベースのインデックス付け効率が向上し、さらに、第２のストレージエンジンの機能設計により、第１のストレージエンジンは、それ自体に搭載されていない機能を実行することができるようになり、データベースの適用範囲及びインデックス付け効率をさらに向上させる。

上記のプロセスアーキテクチャを結合し、図３を参照して、本出願におけるデータインデックスの方法を以下に説明する。図３は、本出願の実施例によるデータインデックス付け方法のフローチャートであり、コンピュータ装置に適用され、本出願の実施例は、少なくとも以下のステップを含む。

ステップ３０１、コンピュータ装置は、ターゲットトランザクションを取得する。

本実施例では、ターゲットトランザクションは、データインデックス付けプロセスを指示し、ターゲットトランザクションは、現在のデータベースが常に実行しているトランザクションであってもよく、新たに発行されるトランザクションであってもよい。第１のストレージエンジンについて、ロウワー関数の設計を実行せず、第２のストレージエンジンのロウワー関数によって、データインデックス付け機能を実現することができる。

ステップ３０２、コンピュータ装置は、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定する。

本実施例では、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれ、第１のインデックステーブルは、異なるバージョンの第１のストレージエンジンにおけるターゲットインデックスデータを記録し、可能なシナリオでは、第１のストレージエンジンはＮＥＷＤＢであり、当該データベースストレージエンジンは、シングルステートメントのトランザクションのみをサポートし、当該エンジンが新しく追加された場合、インターフェースによってデータインタラクションを実行するように、当該シングルステートメントのトランザクションに対してロウワー関数を設計する必要がある。

ステップ３０３、コンピュータ装置は、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定する。

本実施例では、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、行識別子は、ターゲットインデックスデータにおける行データを指示するために使用され、行データは、ターゲットインデックスデータにおけるインデックス列に対応し、インデックス列は、ターゲットトランザクションに基づいて得られ、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートする。挿入又は削除される各レコードは、独立した行識別子(ｒｏｗｎｏ)を有するため、ｒｏｗｎｏによって、ある行データを直接取得して、バッチ操作を実行することができる。

なお、異なるストレージエンジン機能の対応性により、本実施例では、第１のストレージエンジンは、マルチステートメント同時トランザクションをサポートせず、第２のストレージエンジンは、マルチステートメント同時トランザクションをサポートすることを例として説明し、完全な機能を備えたストレージエンジンを使用して単一機能のストレージエンジンを再利用する、ストレージエンジン再利用プロセスにおける機能特徴を示す。以下、第１のストレージエンジンがＮＥＷＤＢであり、第２のストレージエンジンがＩｎｎｏＤＢであることを例として説明し、ここでは制限しない。

任意選択で、データベースの使用で、データのインタラクションに係るため、例えば、ＤＤＬ及びＤＭＬステートメントの実現などの、データに変更がある可能性があり、この場合、関連データを更新する必要があり、本出願におけるデータインデックス付け方法に基づいて、以下の操作を実行してデータ更新を実現することができる。

一、ＤＤＬステートメントの場合。
本実施例では、まず、ターゲットトランザクションにおけるデータベーススキーマ情報、即ち、ＤＤＬステートメントを決定し、次に、ＤＤＬステートメントに基づき、第２のインデックステーブルを更新する。ＤＤＬステートメントは、ＣＲＥＡＴＥ、ＡＬＴＥＲ、ＤＲＯＰなどを含む。具体的に、図４に示すように、本出願の実施例によるインデックステーブルの更新フローの概略図であり、まず、第１のストレージエンジンにおいて、トランザクションにアクセスして、ＤＤＬステートメントを決定し、次に、対応する第１のインデックステーブルを決定し、第１のインデックステーブルに基づいて、第２のストレージエンジンにマッピングされた第２のインデックステーブルを検索して、インデックステーブルの作成プロセスを実行する。

ＣＲＥＡＴＥステートメントについて、インデックス付きＮＥＷＤＢテーブルを作成しているかどうかを判断し、そうである場合、１つの対応するインデックステーブルを追加して作成する。当該インデックステーブルは、ＮＥＷＤＢテーブルと同様に定義されたインデックス列、及び１つの追加の列ｒｏｗｎｏを含み、そのデータタイプは、ＢＩＧＩＮＴであり、ＮＥＷＤＢエンジンに記録された行番号を表し、即ち、インデックス付けモードに基づいて第２のインデックステーブルを分類して、第２のインデックステーブルを更新し、インデックス付けモードは、主キーインデックス、ユニークインデックス又は通常のインデックスを含む。

可能なシナリオでは、第２のインデックステーブルｔに複数の列ｃ１、ｃ２、ｃ３、ｃ４、ｃ５があり、主キーインデックス列は、ｃ１、ｃ２であり、ユニークインデックス列はｃ３、ｃ４であり、通常のインデックス列はｃ５であると仮定する。ＩｎｎｏＤＢにおいて、インデックスに対応する３つのインデックステーブル、即ち、ｔ_ｐｋ(ｃ１，ｃ２，ｏｗｎｏ)、ｔ_ｕｎｉｑｕｅ１(ｃ３，ｃ４，ｒｏｗｎｏ)、ｔ_ｉｎｄｅｘ１(ｃ５，ｒｏｗｎｏ)を作成する。

具体的に、以下のステートメントによって上記のプロセスを実行することができる。
主キーインデックスについて
ＣＲＥＡＴＥ ＴＡＢＬＥ_ＮＤＢ_ＩＮＤＥＸ．ｔ_ｐｋ(ｃ１＜Ｔｙｐｅ＞／／主キーインデックス命令を決定する；
，ｃ２＜Ｔｙｐｅ＞／／インデックス条件を入力する；
，ｒｏｗｎｏ ＢＩＧＩＮＴ／／行識別子を入力する；
，ＰＲＩＭＡＲＹ ＫＥＹ(ｃ１，ｃ２))／／主キーインデックス列を決定する；
ＥＮＧＩＮＥ＝ＩｎｎｏＤＢ；／／ストレージエンジンを指示する
ユニークインデックスについて
ＣＲＥＡＴＥ ＴＡＢＬＥ_ＮＤＢ_ＩＮＤＥＸ．ｔ_ｕｎｉｑ１(ｃ３＜Ｔｙｐｅ＞／／ユニークインデックス命令を決定する；
，ｃ４＜Ｔｙｐｅ＞／／インデックス条件を入力する；
，ｒｏｗｎｏ ＢＩＧＩＮＴ／／行識別子を入力する；
，ＵＮＩＱＵＥ ＩＮＤＥＸ(ｃ３，ｃ４))／／ユニークインデックス列を決定する
ＥＮＧＩＮＥ＝ＩｎｎｏＤＢ；／／ストレージエンジンを指示する
通常のインデックスについて
ＣＲＥＡＴＥ ＴＡＢＬＥ_ＮＤＢ_ＩＮＤＥＸ．ｔ_ｉｎｄｅｘ１(ｃ５＜Ｔｙｐｅ＞／／通常のインデックス命令を決定する；
，ｒｏｗｎｏ ＢＩＧＩＮＴ／／行識別子を入力する；
，ＩＮＤＥＸ(ｃ５))／／通常のインデックス列を決定する；
ＥＮＧＩＮＥ＝ＩｎｎｏＤＢ；／／ストレージエンジンを指示する。

ＣＲＥＡＴＥステートメントによって第２のインデックステーブルを更新するプロセスは、上記の実現方式で実現することができる。

また、ＮＥＷＤＢエンジンに対してＤＲＯＰ ＴＡＢＬＥステートメントを実行する場合、テーブルにインデックスがあれば、_ＮＤＢ_ＩＮＤＥＸデータベースにおける対応するインデックステーブルを削除して、ＤＤＬステートメントにおける行データに対する処理情報を取得し、処理情報に基づいて、対応するインデックス列の変更データを抽出し、インデックス列の変更データに基づき、第２のインデックステーブルを更新する。

ＡＬＴＥＲＥ ＴＡＢＬＥステートメントを実行する場合、ＡＤＤ ＣＯＬＵＭＮであれば、第２のインデックステーブルに新しい列を追加し、既存のインデックステーブルを処理する必要がない。ＤＲＯＰ ＣＯＬＵＭＮであれば、第２のインデックステーブルにおける対応する列を削除する必要がある。ＡＤＤ ＩＮＤＥＸ、ＤＲＯＰ ＩＮＤＥＸなどであれば、対応するインデックステーブルを追加又は削除する必要がある。

なお、上記のステートメントを例として説明したが、他のＤＤＬステートメントの実行は、上記のＣＲＥＡＴＥ、ＡＬＴＥＲ又はＤＲＯＰステートメントの実行プロセスを参照してもよい。ここでは、制限しない。

二、ＤＭＬステートメントの場合。
本実施例では、ＤＭＬステートメントは、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥを含み、これらのステートメントを実行するときに、対応するインデックステーブルを同時に維持する必要がある。具体的に、ターゲットトランザクションにおけるＤＭＬステートメントを決定し、ＤＭＬステートメントは、データの挿入、更新又は削除を指示するためのものであり、次に、ＤＭＬステートメントに基づき、第２のインデックステーブルを更新する。

ＩＮＳＥＲＴステートメントについて、まず、テーブルにおける各主キーインデックス及びユニークインデックスの場合、インデックステーブルにおいて、挿入対象のレコードが既に存在するかどうかをチェックし、レコードが既に存在する場合、トランザクションを終了して、ＩＮＳＥＲＴ失敗を返し、さもなければ、ＮＥＷＤＢエンジンにレコードを挿入し、全てのレコードのインデックス列及びｒｏｗｎｏの比較表を返し、次に、１つ前のステップで返された比較表に基づき、インデックステーブルにおいて一括挿入する。

ＤＥＬＥＴＥステートメントについて、まず、ＤＥＬＥＴＥステートメントにおけるＷＨＥＲＥ条件に従って、ＮＥＷＤＢエンジンにおいて条件を満たすレコードを検索し、次に、ＮＥＷＤＢエンジンにおいて、条件を満たすレコードを削除し、そのｒｏｗｎｏを記録し、次に、ｒｏｗｎｏに従って、インデックステーブルにおいて削除操作を順次に実行する。

任意選択で、ＤＥＬＥＴＥステートメントのＷＨＥＲＥ条件にインデックス列が含まれ、即ち、データインデックス条件にインデックス列が含まれる場合、まず、インデックステーブルにおいて、ＷＨＥＲＥ条件におけるインデックス列条件に従って、マッチングするレコードのｒｏｗｎｏを検索することができる。次に、クエリ条件におけるインデックス列条件を検索されたｒｏｗｎｏに切り替えて、削除操作を実行する。データインデックス条件に基づき、対応する行識別子を決定して、削除操作を実行し、これにより、データ処理の量が低減され、プロセスの効率を向上させる。

ＤＥＬＥＴＥステートメントについて、まず、ＵＰＤＡＴＥステートメントにおけるＷＨＥＲＥ条件に従ってＮＥＷＤＢエンジンにおいて条件を満たすレコードを検索し、次に、ＮＥＷＤＢエンジンにおいて条件を満たすレコードを削除し、そのｒｏｗｎｏを記録し、次に、ＮＥＷＤＢエンジンにおいてＵＰＤＡＴＥステートメントに基づき、新しい値を算出してレコードを挿入し、新しいレコードのｒｏｗｎｏを記録し、記録された新しいｒｏｗｎｏと古いｒｏｗｎｏに従って、インデックステーブルにおいて更新動作を順次に実行する。

任意選択で、ＵＰＤＡＴＥステートメントのＷＨＥＲＥ条件にインデックス列が含まれる場合、データインデックス条件に基づき対応する行識別子を決定して、更新操作を実行し、これにより、データ処理の量が低減され、プロセスの効率を向上させる。

なお、行識別子を指定するクエリ及び修正を提供することによって、操作の実行効率を大幅に向上させることができ、いくつかの業務シナリオでは、より効果的であり、例えば、業務が複数行のデータをバッチで処理する必要がある場合、行番号を指定したクエリにより、処理中にデータが繰り返されたり間違ったりしないようにすることができる。

３０４、コンピュータ装置は、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。

本実施例では、インデックスデータは、ターゲットインデックスデータに含まれる。インデックス付けのプロセスは、行識別子に基づいて実行することができ、具体的に、まず、第１のストレージエンジンにおけるターゲットトランザクションのデータインデックス条件を取得して、データインデックス条件によって指示される行識別子を決定し、次に、データインデックス条件によって指示される行識別子に基づき、第２のインデックステーブルにおける対応する行識別子を決定して、行データを取得し、行データに基づき、対応するインデックスデータを決定する。行識別子は、複数の行データに対応し、ＮＥＷＤＢエンジンにおいて行識別子の位置に対応するレコードを直接検索して結果を返し、全てのデータを読み取って順番に検索する必要がないため、クエリ速度を大幅に向上させる。

任意選択で、データインデックス条件がインデックス値を指示する場合、ターゲットインデックス値に基づき、前記少なくとも１つの第２のインデックステーブルから、対応する第２のインデックステーブルを決定し、次に、これらのインデックステーブルから、ターゲットインデックス値に対応する行データを選別して、対応するインデックスデータを取得することができる。例えば、ＷＨＥＲＥ条件でインデックス値が指定されている場合、まずインデックステーブルでクエリし、条件を満たす全てのインデックステーブルにおけるレコードをクエリしてから、インデックステーブルに記録されているｒｏｗｎｏ値に基づき、実際のレコード値を素早く検索する。

可能なシナリオでは、次のステートメントによって上記のデータクエリのプロセスを実現することができる。
ＳＥＬＥＣＴ_ｒｏｗｎｏ ＦＲＯＭ ｔ；／／行識別子を選択する；
ＳＥＬＥＣＴ_ｒｏｗｎｏ ＦＲＯＭ ｔ ＷＨＥＲＥ ａ＝１２；／／データインデックス条件における行識別子を決定する；
ＳＥＬＥＣＴ*ＦＲＯＭ ｔ ＷＨＥＲＥ_ｒｏｗｎｏ＝１２；／／対応する行識別子をクエリする
ＤＥＬＥＴＥ ＦＲＯＭ ｔ ＷＨＥＲＥ_ｒｏｗｎｏ＝１２；／／クエリ結果を抽出する

上記のクエリ加速プロセスによって、第２のインデックステーブルから第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する効率を向上させることができる。

上記の実施例から分かるように、データインデックス付けプロセスを指示するターゲットトランザクションを取得し、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定し、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれ、次に、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定し、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、インデックス列は、ターゲットトランザクションに基づいて得られ、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートし、さらに、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現し、新しいストレージエンジン導入による開発の複雑さが軽減されるため、複数のストレージエンジンのコード再利用を実現し、データベースのインデックス付け効率が向上し、さらに、第２のストレージエンジンの機能設計により、第１のストレージエンジンは、それ自体に搭載されていない機能を実行することができるようになり、データベースの適用範囲及びインデックス付け効率をさらに向上させる。

上記の実施例は、データインデックスのプロセスを説明し、可能なシナリオでは、データの一致性を保証するために、データ更新プロセスを検出してもよい。本出願の実施例による別のデータインデックス付け方法のフローチャートである図５を参照し、本出願の実施例は、少なくとも以下のステップを含む。

ステップ５０１、コンピュータ装置は、ターゲットトランザクションを取得する。

ステップ５０２、コンピュータ装置は、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを取得する。

ステップ５０３、コンピュータ装置は、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定する。

本実施例では、ステップ５０１―５０３は、図３に示した前述の実施例のステップ３０１―３０３と類似しており、関連する特徴の説明を参照することができ、ここで、説明を繰り返さない。

ステップ５０４、コンピュータ装置は、ターゲットトランザクションにおけるデータ操作情報を実行する。

本実施例では、図３に示した前述の実施例のステップ３０３におけるＤＭＬステートメントの実行に対する関連する説明を参照することができ、ここでは、説明を繰り返さない。

ステップ５０５、コンピュータ装置は、実行プロセスで少なくとも１つの故障検出点を設置する。

本実施例では、実行プロセスで、データを記憶するために複数のバージョンを使用し、各インデックステーブルは、バージョン番号によってデータの変更を表し、バージョン番号は、逓増する整数であり、即ち、トランザクションがコミットされるとバージョンを切り替え、さもなければ、古いバージョンを使用する。具体的に、まず、変更情報に基づき、第１のストレージエンジンに対応するバージョン番号を決定して、第２のストレージエンジンにおいてログテーブルを生成し、次に、変更情報に対応する処理フローを決定し、処理フローに少なくとも１つの故障検出点を設置し、故障検出点は、第１のストレージエンジン及び第２のストレージエンジンのインタラクションプロセスに基づいて決定され、さらに、故障検出点に基づいて、隣接する第１のストレージエンジンのバージョン番号のデータ対応状況を決定する。

任意選択で、ログテーブルは、次の構成を使用できる。
ＣＲＥＡＴＥ ＴＡＢＬＥ_ｎｅｗｄｂ．ｗａｌ(ｄｂｉｄ ＢＩＧＩＮＴ／／ログテーブルを確立する
，ｔａｂｌｅｉｄ ＢＩＧＩＮＴ／／インデックステーブルを記録する
，ｖｅｒｓｉｏｎ ＢＩＧＩＮＴ／／バージョン番号を記録する
，ＰＲＩＭＡＲＹ ＫＥＹ(ｄｂｉｄ．ｔａｂｌｅｉｄ))／／関連関係を記録する
ＥＮＧＩＮＥ＝ＩｎｎｏＤＢ；／／データベースタイプ

具体的に、特定のＤＭＬステートメントの実行プロセスに対応する。ＩＮＳＥＲＴステートメントについて、図６に示すプロセスを参照することができ、図６は、本出願の実施例によるデータ挿入操作フローの概略図である。当該プロセスは、以下のステップを含む。

ステップ６０１、コンピュータ装置は、挿入を開始する。

ステップ６０２、コンピュータ装置は、レコードが存在するかどうかを判断する。

本実施例では、第２のインデックステーブルにおける各主キーインデックス及びユニークインデックスについて、インデックステーブルにおいて挿入対象のレコードが既に存在するかどうかをチェックし、レコードが既に存在する場合、トランザクションを終了し、ＩＮＳＥＲＴ失敗を返す。

ステップ６０３、コンピュータ装置は、エラーで終了する。

ステップ６０４、コンピュータ装置は、ログテーブルレコードを挿入する。

本実施例では、ステップ６０２における第２のインデックステーブルのバージョンを記録し、次に、インデックステーブル_ｎｅｗｄｂ．ｗａｌに、レコード(ｄｂｉｄ，ｔａｂｌｅｉｄ，ｖｅｒｓｉｏｎ)、即ち、ストレージエンジンＩＤ、インデックステーブルＩＤ及びバージョン番号を挿入する。

ステップ６０５、コンピュータ装置は、第２のストレージエンジントランザクションをコミットする。

ステップ６０６、コンピュータ装置は、第１のストレージエンジンログテーブルを挿入する。

本実施例では、ログテーブルを比較する方法によってデータ一致性を判断し、この場合、第１のストレージエンジンにおいてログテーブルの挿入プロセスを実行し、即ち、ＮＥＷＤＢテーブルレコードデータを挿入し、ＮＥＷＤＢのトランザクションのコミットを実行し、コミット後のＮＥＷＤＢテーブルのバージョンをバージョンｖｅｒｓｉｏｎ＋１に切り替える。

ステップ６０７、コンピュータ装置は、第１のストレージエンジントランザクションをコミットする。

ステップ６０８、コンピュータ装置は、インデックステーブルレコードを挿入する。

本実施例では、ＮＥＷＤＢテーブル插入した後に返されたレコードインデックス列及びｒｏｗｎｏを対応するインデックステーブルに挿入する。

ステップ６０９、コンピュータ装置は、ログテーブルレコードを削除する。

本実施例では、テーブル_ｎｅｗｄｂ．ｗａｌにおけるステップ６０４で挿入されたレコードを削除する。

ステップ６１０、コンピュータ装置は、第２のストレージエンジントランザクションをコミットする。

ステップ６１１、コンピュータ装置は挿入に成功し、プロセスを終了する。

上記の挿入プロセスでは、４つの故障点を設置することができ、ステップ６０１－ステップ６０５は、故障点１の検出プロセスであり、ステップ６０６－ステップ６０７は、故障点２の検出プロセスであり、ステップ６０８－ステップ６１０は、故障点３の検出プロセスであり、ステップ６１１は、故障点４の検出プロセスである。

具体的に、故障点１の場合、可能な故障の理由は、_ｎｅｗｄｂ．ｗａｌテーブルにレコードが挿入されていないこと、又はレコードが挿入されたがコミットされていないことである。この場合、_ｎｅｗｄｂ．ｗａｌテーブルは、完全なトランザクションをサポートするストレージエンジンを使用するため、リカバリ後に、トランザクション原子性の保証のため、挿入されたがコミットされていないレコードは、ロールバックされる。そのため、当該故障点は、追加の故障リカバリプロセスを実行せずに、ＮＥＷＤＢのデータ及びインデックスが一致していることを保証することができる。

故障点２の場合、この時点で、_ｎｅｗｄｂ．ｗａｌテーブルに、新しいデータが既に記録されているが、ＮＥＷＤＢテーブルのトランザクションはコミットされていない。データ及びインデックスに矛盾がないが、_ｎｅｗｄｂ．ｗａｌテーブルのレコードが正しくない可能性があるため、リカバリする必要がある。リカバリ中に、ｄｂｉｄ及びｔａｂｌｅｉｄフィールドに基づき、例えば１などの_ｎｅｗｄｂ．ｗａｌにおけるレコードのバージョンを検索し、次に、ＮＥＷＤＢテーブルの現在のバージョンを判断し、１の場合、_ｎｅｗｄｂ．ｗａｌテーブルにおけるレコードをロールバックする必要があることを示す。ロールバック操作は、_ｎｅｗｄｂ．ｗａｌテーブルにおける対応するレコードを直接削除することであってもよい。

故障点３の場合、この時点で、_ｎｅｗｄｂ．ｗａｌテーブルに、新しいデータが既に記録され、ＮＥＷＤＢテーブルのトランザクションも既にコミットされたが、インデックステーブルのデータは更新されておらず、_ｎｅｗｄｂ．ｗａｌテーブルの記録も削除されていない。データとインデックスが一致しないので、リカバリする必要がある。リカバリ中に、ｄｂｉｄ及びｔａｂｌｅｉｄフィールドに基づき、例えば１などの_ｎｅｗｄｂ．ｗａｌテーブルに記録されたバージョンを検索し、次に、ＮＥＷＤＢテーブルの現在のバージョンを判断し、２の場合、このような状況であることを説明し、リカバリプロセスをやり直す必要がある。_ｎｅｗｄｂ．ｗａｌテーブル及びインデックステーブルは、同じストレージエンジンであり、且つ、当該エンジンが完全なトランザクションをサポートするため、これら２つのテーブルは、３番目のステップでの操作が一致する。ＮＥＷＤＢテーブルにおいて、バージョン１及び２の間のレコード変更をクエリして比較し、これらの変更されたレコードｒｏｗｎｏをインデックステーブルに書き込んでから、_ｎｅｗｄｂ．ｗａｌテーブルのレコードを削除して、トランザクションをコミットする。

故障点４の場合、全てのステップのトランザクションが既にコミットされたため、データは、一致の状態にあり、データリカバリを実行しなくてもよい。

また、ＤＥＬＥＴＥステートメントについて、まず、ＮＥＷＤＢにおいてインデックステーブルの削除操作の前に、ＮＥＷＤＢテーブルのバージョンを記録し、_ｎｅｗｄｂ．ｗａｌにレコード(ｄｂｉｄ、ｔａｂｌｅｉｄ、ｖｅｒｓｉｏｎ)を挿入し、トランザクションをコミットし、次に、ＤＥＬＥＴＥステートメントにおけるＷＨＥＲＥ条件に従って、ＮＥＷＤＢエンジンにおいて、条件を満たすレコードを検索する。ＷＨＥＲＥステートメントでｒｏｗｎｏが指定されている場合、ｒｏｗｎｏによって、削除する必要のあるＮＥＷＤＢテーブルのレコードを直接検索する。ＷＨＥＲＥステートメントでインデックス列が指定されている場合、インデックステーブを介して、削除する必要のあるＮＥＷＤＢテーブルのレコードｒｏｗｎｏを検索し、次に、ｒｏｗｎｏによって、削除する必要のあるＮＥＷＤＢテーブルのレコードを検索し、ＷＨＥＲＥステートメントでｒｏｗｎｏ及びインデックス列が指定されていない場合、ＮＥＷＤＢテーブルを順番に検索して、削除する必要のあるレコードを検索する。検索されたＮＥＷＤＢレコードを削除して、コミットし、コミット後のＮＥＷＤＢテーブルのバージョンがｖｅｒｓｉｏｎ＋１に変更される。次に、ＮＥＷＤＢテーブルの削除された行のｒｏｗｎｏに基づき、インデックステーブルにおいて対応するレコードを削除し、_ｎｅｗｄｂ．ｗａｌの１番目のステップで挿入されたレコードを削除する。トランザクションをコミットする。

ＵＰＤＡＴＥステートメントについて、まず、ＮＥＷＤＢにおけるインデックステーブルの更新操作の前に、ＮＥＷＤＢテーブルのバージョンを記録し、_ｎｅｗｄｂ．ｗａｌにレコード(ｄｂｉｄ、ｔａｂｌｅｉｄ、ｖｅｒｓｉｏｎ)を挿入し、トランザクションをコミットする。次に、ＵＰＤＡＴＥステートメントにおけるＷＨＥＲＥ条件に従って、ＮＥＷＤＢエンジンにおいて条件を満たすレコードを検索し、ＷＨＥＲＥステートメントでｒｏｗｎｏが指定されている場合、ｒｏｗｎｏによって、削除する必要のあるＮＥＷＤＢテーブルのレコードを直接検索し、ＷＨＥＲＥステートメントでインデックスが指定されている場合、インデックステーブルを介して、削除する必要のあるＮＥＷＤＢテーブルのレコードのｒｏｗｎｏを検索し、削除する必要のあるＮＥＷＤＢテーブルのレコードを検索し、ＷＨＥＲＥステートメントでｒｏｗｎｏ及びインデックスが指定されていない場合、ＮＥＷＤＢテーブルを順番に検索して、削除する必要のあるレコードを検索する必要がある。次に、ＵＰＤＡＴＥステートメントに基づき、新しい値を算出してレコードを挿入し、新しいレコードのｒｏｗｎｏを記録してコミットし、コミット後のＮＥＷＤＢテーブルのバージョンは、ｖｅｒｓｉｏｎ＋１に変更される。さらに、ＮＥＷＤＢテーブルの新しい行及び古い行のｒｏｗｎｏに基づき、インデックステーブルにおいて対応するレコードを更新し、_ｎｅｗｄｂ．ｗａｌの１番目のステップで挿入されたレコードを削除する。トランザクションをコミットする。

任意選択で、上記の故障検出プロセスにおけるログテーブルは、変更された全てのレコードの行番号が記録されたログテーブルを使用して、リカバリフェーズでは、ログテーブルにおけるデータに基づき、ＲＥＤＯ又はＵＮＤＯ操作を実行し、即ち、行識別子に基づいて、リカバリユニットに対して検出してリカバリする。

ステップ５０６、コンピュータ装置は、故障しているかどうかを判断する。

本実施例では、ステップ５０５で説明した異なる故障点の判断プロセスによって、判断の結果を得ることができ、故障していると判断した場合、データの一致性を保証するために、データリカバリを実行する必要があり、正常であると判断した場合、ステップ５０７のインデックス付けプロセスを実行する。

５０７、コンピュータ装置は、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。

本実施例では、ステップ５０７は、図３に示した前述の実施例のステップ３０４と類似しており、関連する特徴の説明を参照することができ、ここでは、説明を繰り返さない。

上記の実施例から分かるように、完全なトランザクション機能を備えたストレージエンジンを再利用して、新しいエンジンのインデックスを実現することにより、新しいエンジンインデックスの実現の難しさ及び問題のリストが軽減される。さらに、完全なトランザクション機能を備えたストレージエンジンを使用して新しいエンジンのインデックスを実現することにより、既存の成熟したモジュールを再利用できるため、開発の作業負荷が軽減され、これにより、新しいエンジンは、Ｂ＋ツリーを再実現する必要がなく、その完全なトランザクションのサポートを実現する必要もない。

上記の実施例は、データインデックスにおける故障検出プロセスを説明し、以下に、図７を参照して、故障が検出された後のデータリカバリプロセスを説明し、図７は、本出願の実施例によるデータリカバリの方法のフローチャートであり、本出願の実施例は、少なくとも以下のステップを含む。

ステップ７０１、コンピュータ装置は、リカバリを開始する。

ステップ７０２、コンピュータ装置は、ログテーブルをチェックする。

本実施例では、ログテーブルは、第２のストレージエンジンのログテーブルであり、ＤＭＬステートメントに基づき第２のストレージエンジンにおけるインデックステーブルによって実行される関連データ操作レコードが記録されている。

ステップ７０３、コンピュータ装置は、レコードが存在するかどうかを判断する。

本実施例では、操作レコードが存在する場合、ステップ７０４に進み、存在しない場合、ステップ７１１に進む。

ステップ７０４、コンピュータ装置は、ログテーブルの何れかのレコードを取得する。

本実施例では、ログテーブルにおけるレコードを取得するプロセスは、レコードのランダムな選択であってもよいし、特定の規則の順序に基づくレコードの選択であってもよく、例えば、好ましくはデータ挿入のレコードを取得する。

ステップ７０５、コンピュータ装置は、ログテーブルのバージョンを取得する。

ステップ７０６、コンピュータ装置は、ログテーブルの実際のバージョンを取得する。

本実施例では、ログテーブルの実際のバージョンは、当該ログテーブルに対応するトランザクションが実行された後のストレージエンジンのデータ状態である。

ステップ７０７、コンピュータ装置は、差異を判断する。

本実施例では、ログテーブルのバージョンに対応するデータとログテーブルの実際のバージョンのデータを比較して、データの差異を決定する。

ステップ７０８、コンピュータ装置は、バージョンの差異を取得する。

ステップ７０９、コンピュータ装置は、インデックステーブルを更新する。

本実施例では、バージョンの差異に基づき、対応する差異データを決定し、差異データに対してインデックステーブルにおいて対応する修正を実行して、インデックステーブルを更新し、具体的に、インデックステーブルを、ログテーブルの実際のバージョンに対応するデータに更新することができる。

ステップ７１０、コンピュータ装置は、ログテーブルの対応するレコードを削除する。

ステップ７１１、コンピュータ装置は、リカバリを終了する。

上記の実施例から分かるように、第２のストレージエンジンにおけるログテーブルに記録されたバージョン番号を決定し、変更情報に基づき、第１のストレージエンジンのバージョン番号を決定し、ログテーブルに記録されたバージョン番号と第１のストレージエンジンのバージョン番号を比較して、差異レコードを生成し、さらに、差異レコードに基づき、第１のインデックステーブル及び第２のインデックステーブルを更新する。これにより、データ故障のリカバリプロセスを実現し、データの一致性を保証し、ストレージエンジンのデータ処理の正確性を向上させる。

本出願の実施例による上記の解決策をよく実施するために、以下、上記の解決策を実施するための関連装置をさらに提供する。本出願の実施例によるデータインデックス付け装置の構成概略図である図８を参照し、データインデックス付け装置８００は、
データインデックス付けプロセスを指示するためのターゲットトランザクションを取得するための取得ユニット８０１と、
前記ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定するための決定ユニット８０２であって、前記ターゲットインデックスデータが、少なくとも１つの第１のインデックステーブルに含まれる決定ユニット８０２と、
前記第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定するためのマッピングユニット８０３であって、前記第２のインデックステーブルは、前記第１のインデックステーブルに基づいて行識別子を追加することによって得られ、前記行識別子は、前記ターゲットインデックスデータにおける行データを指示するためのものであり、前記第２のストレージエンジンは前記ターゲットトランザクションの実行をサポートするマッピングユニット８０３と、
前記第２のインデックステーブルから、前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定するためのインデックスユニット８０４であって、前記インデックスデータは、前記ターゲットインデックスデータに含まれるインデックスユニット８０４と、を含む。

任意選択で、本出願のいくつかの可能な実現方式では、前記インデックスユニット８０４は、具体的に、前記第１のストレージエンジンにおける前記ターゲットトランザクションのデータインデックス条件を取得して、前記データインデックス条件によって指示される行識別子を決定し、
前記インデックスユニット８０４は、具体的に、前記データインデックス条件によって指示される行識別子に基づき、前記第２のインデックステーブルにおける行識別子に対応する行データを決定し、
前記インデックスユニット８０４は、具体的に、前記第２のインデックステーブルにおける行識別子に対応する行データに基づき、対応するインデックスデータを決定する。

任意選択で、本出願のいくつかの可能な実現方式では、前記データインデックス条件は、ターゲットインデックス値を含み、前記インデックスユニット８０４は、具体的に、前記ターゲットインデックス値に基づき、前記少なくとも１つの第２のインデックステーブルから、対応する第２のインデックステーブルを決定し、
前記インデックスユニット８０４は、具体的に、前記対応する第２のインデックステーブルにおける前記ターゲットインデックス値に対応する行データを決定して、対応するインデックスデータを取得する。

任意選択で、本出願のいくつかの可能な実現方式では、前記マッピングユニット８０３はさらに、前記ターゲットトランザクションにおけるデータ操作情報を決定し、前記データ操作情報は、データの挿入、更新又は削除を指示するためのものであり、
前記マッピングユニット８０３はさらに、前記データ操作情報に基づき前記第２のインデックステーブルを更新する。

任意選択で、本出願のいくつかの可能な実現方式では、前記マッピングユニット８０３は、具体的に、前記データ操作情報に基づき、前記第１のインデックステーブルにおける変更情報を決定し、
前記マッピングユニット８０３は、具体的に、前記変更情報に基づき、前記第２のインデックステーブルにおける対応する行識別子を決定し、
前記マッピングユニット８０３は、具体的に、前記第２のインデックステーブルにおける対応する行識別子に基づき、前記第２のインデックステーブルにおける前記変更情報の対応するアイテムを決定して、前記第２のインデックステーブルを更新する。

任意選択で、本出願のいくつかの可能な実現方式では、前記マッピングユニット８０３は、具体的に、前記変更情報に基づき前記第１のストレージエンジンに対応するバージョン番号を決定して、前記第２のストレージエンジンにおいてログテーブルを生成し、
前記マッピングユニット８０３は、具体的に、前記ログテーブルにおける隣接する前記第１のストレージエンジンのバージョン番号のデータ対応状況を決定して、データリカバリを実行する。

任意選択で、本出願のいくつかの可能な実現方式では、前記マッピングユニット８０３は、具体的に、前記変更情報に対応する処理フローを決定し、
前記マッピングユニット８０３は、具体的に、前記処理フローに少なくとも１つの故障検出点を設置し、前記故障検出点は、前記第１のストレージエンジン及び前記第２のストレージエンジンのインタラクションプロセスに基づいて決定され、
前記マッピングユニット８０３は、具体的に、前記故障検出点に基づいて、隣接する前記第１のストレージエンジンのバージョン番号のデータ対応状況を決定して、データリカバリを実行する。

任意選択で、本出願のいくつかの可能な実現方式では、前記インデックスユニット８０４は、具体的に、前記第２のストレージエンジンにおける前記ログテーブルに記録されたバージョン番号を決定し、
前記インデックスユニット８０４は、具体的に、前記変更情報に基づき、前記第１のストレージエンジンのバージョン番号を決定し、
前記インデックスユニット８０４は、具体的に、前記ログテーブルに記録されたバージョン番号と前記第１のストレージエンジンのバージョン番号を比較して、差異レコードを生成し、
前記インデックスユニット８０４は、具体的に、前記差異レコードに基づき、前記第１のインデックステーブル及び前記第２のインデックステーブルを更新する。

任意選択で、本出願のいくつかの可能な実現方式では、前記マッピングユニット８０３はさらに、前記ターゲットトランザクションにおけるデータベーススキーマ情報を決定し、
前記マッピングユニット８０３はさらに、前記データベーススキーマ情報に基づき、前記第２のインデックステーブルを更新する。

任意選択で、本出願のいくつかの可能な実現方式では、前記データベーススキーマ情報は、少なくとも１つのインデックスモードを含み、前記マッピングユニット８０３は、具体的に、前記インデックスモードに基づいて、前記第２のインデックステーブルを分類して、前記第２のインデックステーブルを更新し、前記インデックスモードは、主キーインデックス、ユニークインデックス又は通常のインデックスを含む。

任意選択で、本出願のいくつかの可能な実現方式では、前記第２のインデックステーブルの行識別子によって指示される行データは、前記ターゲットインデックスデータにおけるインデックス列に対応し、前記インデックス列は、前記ターゲットトランザクションに基づいて得られ、前記マッピングユニット８０３は、具体的に、前記データベーススキーマ情報における前記行データに対する処理情報を取得し、
前記マッピングユニット８０３は、具体的に、前記処理情報に基づいて、対応するインデックス列の変更データを抽出し、
前記マッピングユニット８０３は、具体的に、前記インデックス列の変更データに基づき、前記第２のインデックステーブルを更新する。

データインデックス付けプロセスを指示するためのターゲットトランザクションを取得し、ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定し、ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれ、次に、第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定し、第２のインデックステーブルは、第１のインデックステーブルに基づいて行識別子を追加することによって得られ、行識別子は、ターゲットインデックスデータにおける行データを指示するためのものであり、第２のストレージエンジンは、ターゲットトランザクションの実行をサポートし、さらに、第２のインデックステーブルから、第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する。これにより、ストレージエンジンを跨ぐデータインデックス付けプロセスを実現し、新しいストレージエンジン導入による開発の複雑さが軽減されるため、複数のストレージエンジンのコード再利用を実現し、データベースのインデックス付け効率が向上し、さらに、第２のストレージエンジンの機能設計により、第１のストレージエンジンは、それ自体に搭載されていない機能を実行することができるようになり、データベースの適用範囲及びインデックス付け効率をさらに向上させる。

本出願の実施例はまた、別のデータインデックス付け装置を提供し、本出願の実施例による別のデータインデックス付け装置の構成概略図である図９を参照し、当該データインデックス付け装置９００は、異なる配置又は性能により大きく異なってもよく、１つ以上の中央処理装置(ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ、ＣＰＵ)９２２(例えば、１つ以上のプロセッサー)及びメモリ９３２、アプリケーションプログラム９４２やデータ９４４が記憶される１つ以上の記憶媒体９３０(例えば、１つ以上の大容量記憶装置)を含んでもよい。メモリ９３２及び記憶媒体９３０は、短期記憶又は永続記憶であってもよい。記憶媒体９３０に記憶されたプログラムは、１つ以上のモジュール(図示せず)を含んでもよく、各モジュールは、データインデックス付け装置に対する一連の命令操作を含んでもよい。さらに、中央処理装置９２２は、記憶媒体９３０と通信して、データインデックス付け装置９００上で記憶媒体９３０における一連の命令操作を実行するように構成されてもよい。

データインデックス付け装置９００は、１つ以上の電源９２６、１つ以上の有線又は無線ネットワークインターフェース９５０、１つ以上の入出力インターフェース９５８、及び／又は、例えばＷｉｎｄｏｗｓ Ｓｅｒｖｅｒ(登録商標)、Ｍａｃ ＯＳ Ｘ(登録商標)、Ｕｎｉｘ(登録商標)、Ｌｉｎｕｘ(登録商標)、ＦｒｅｅＢＳＤ(登録商標)などの１つ以上のオペレーティングシステム９４１を含んでもよい。

上記の実施例におけるデータインデックス付け装置が実行するステップは、当該図９に示したデータインデックス付け装置の構造に基づいてもよい。

本出願の実施例は、コンピュータ可読記憶媒体をさらに提供し、前記記憶媒体は、コンピュータプログラムを記憶し、前記コンピュータプログラムは、図２から図７に示される前述の実施例で説明された方法におけるデータインデックス付け装置が実行するステップを実行する。

本出願の実施例はさらに、データインデックス命令を含むコンピュータプログラム製品を提供し、コンピュータ上で実行されるときに、図２から図７に示される前述の実施例で説明された方法におけるデータインデックス付け装置が実行するステップをコンピュータに実行させる。

本出願の実施例はさらに、データインデックス付けシステムを提供し、前記データインデックス付けシステムは、図８で説明された実施例におけるデータインデックス付け装置、又は図８で説明されたデータインデックス付け装置を含んでもよい。

説明の便宜及び簡潔さのために、上記のシステム、装置及びユニットの具体的な作業プロセスは、前述の方法の実施例における対応プロセスを参照でき、ここでは、説明を繰り返さない。

なお、本出願で提供されるいくつかの実施例では、開示されたシステム、装置及び方法は、他の形態により実施されてもよい。例えば、上述した装置の実施例は、単に例示的であり、例えば、上記ユニットの区分は、論理機能の区分にすぎず、実際に実現される場合には、複数のユニット又はコンポーネントが組み合わせられるか、他のシステムに集積されてもよく、又はいくつかの特徴が省略されてもよく、又は実行されなくてもよいなどの別の区分方法が存在してもよい。また、説明又は検討されている相互の結合又は直接結合又は通信接続は、いくつかのインターフェース、装置又はユニットを介した間接結合又は通信接続であってもよいし、電気的、機械的又は他の形態であってもよい。

上記の個別の構成要素として説明されたユニットは、物理的に分離されてもよいし、そうではなくてもよい。ユニットとして表示される構成要素は、物理的な構成要素であってもよいし、物理的な構成要素でなくてもよい。つまり、１つの場所に配置されてもよいし、複数のネットワーク構成要素に分散されてもよい。これらのユニットの一部又は全部は、実際の必要に応じて、本実施例の解決策の目的を達成するために選択されてもよい。

また、本出願の各実施例における各機能ユニットは、１つの処理ユニットに集積されてもよいし、各ユニットが物理的に個別に存在してもよいし、２つ以上のユニットが１つのユニットに集積されてもよい。上記の集積されたユニットは、ハードウェアの形で実現してもよいし、ソフトウェア機能ユニットの形で実現してもよい。

上記の集積されたユニットは、ソフトウェア機能ユニットの形で実現され、独立した製品として販売又は使用される場合には、１つのコンピュータ可読メモリに記憶されてもよい。このような理解に基づいて、本出願の技術的解決策が本質的に、又は従来技術に貢献する部分、又は当該技術的解決策の全部若しくは一部がソフトウェア製品の形で具現化されてもよい。当該コンピュータソフトウェア製品は、１つのメモリに記憶され、１台のコンピュータ装置（パーソナルコンピュータ、データインデックス付け装置やネットワーク装置など）に、本出願の各実施例に記載の方法の全部又は一部のステップを実行させるためのいくつかの命令を含む。前述のメモリは、Ｕディスク、リムーバブルハードディスク、読み取り専用メモリ（ｒｅａｄ-ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク又は光ディスクなどの、プログラムコードを記憶できる様々な媒体を含む。

上記のように、上記の実施例は、本出願の技術的解決策を説明し、それを限定するものではない。前述の実施例を参照して本出願について詳細に説明したが、前述の各実施例で記載された技術的解決策を修正すること、又は、一部の技術的特徴に対して同等の置換を実行することは依然として可能であり、これらの修正又は置換は、対応する技術的解決策の本質を、本出願の各実施例の技術的解決策の精神及び範囲から逸脱させるものではない。

８００ データインデックス付け装置
８０１ 取得ユニット
８０２ 決定ユニット
８０３ マッピングユニット
８０４ インデックスユニット
９００ データインデックス付け装置
９２２ 中央処理装置
９３０ 記憶媒体
９３２ メモリ
９４１ オペレーティングシステム
９４２ アプリケーションプログラム
９４４ データ
９５０ 有線又は無線ネットワークインターフェース
９５８ 入出力インターフェース

Claims (15)

1. コンピュータ装置が実行するストレージエンジンにおけるデータインデックス付け方法であって、
   データインデックス付けプロセスを指示するためのターゲットトランザクションを取得するステップと、
   前記ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定するステップであって、前記ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれる、ステップと、
   前記第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定するステップであって、前記第２のインデックステーブルは、前記第１のインデックステーブルに基づいて行識別子を追加することによって得られ、前記行識別子は、前記ターゲットインデックスデータにおける行データを指示するためのものであり、前記第２のストレージエンジンは、前記ターゲットトランザクションの実行をサポートする、ステップと、
   前記第２のインデックステーブルから、前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定するステップであって、前記インデックスデータは前記ターゲットインデックスデータに含まれる、ステップと、
   を含む方法。
2. 前記第２のインデックステーブルから前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する前記ステップは、
   前記第１のストレージエンジンにおける前記ターゲットトランザクションの前記データインデックス条件を取得して、前記データインデックス条件によって指示される行識別子を決定するステップと、
   前記データインデックス条件によって指示される行識別子に基づき、前記第２のインデックステーブルにおける行識別子に対応する行データを決定するステップと、
   前記第２のインデックステーブルにおける行識別子に対応する行データに基づき、対応するインデックスデータを決定するステップと、
   を含む請求項１に記載の方法。
3. 前記データインデックス条件は、ターゲットインデックス値を含み、
   前記第２のインデックステーブルから前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定する前記ステップは、
   前記ターゲットインデックス値に基づき、前記少なくとも１つの第２のインデックステーブルから、対応する第２のインデックステーブルを決定するステップと、
   前記対応する第２のインデックステーブルにおける前記ターゲットインデックス値に対応する行データを決定して、対応するインデックスデータを取得するステップと、
   を含む請求項１に記載の方法。
4. 前記ターゲットトランザクションにおけるデータ操作情報を決定するステップであって、前記データ操作情報は、データの挿入、更新又は削除を指示するためのものである、ステップと、
   前記データ操作情報に基づき、前記第２のインデックステーブルを更新するステップと、
   をさらに含む請求項１～３の何れか一項に記載の方法。
5. 前記データ操作情報に基づき前記第２のインデックステーブルを更新する前記ステップは、
   前記データ操作情報に基づき、前記第１のインデックステーブルにおける変更情報を決定するステップと、
   前記変更情報に基づき、前記第２のインデックステーブルにおける対応する行識別子を決定するステップと、
   前記第２のインデックステーブルにおける対応する行識別子に基づいて、前記第２のインデックステーブルにおける前記変更情報の対応するアイテムを決定して、前記第２のインデックステーブルを更新するステップと、
   を含む請求項４に記載の方法。
6. 前記第２のインデックステーブルにおける対応する行識別子に基づいて、前記第２のインデックステーブルにおける前記変更情報の対応するアイテムを決定して、前記第２のインデックステーブルを更新した後、さらに、
   前記変更情報に基づき、前記第１のストレージエンジンに対応するバージョン番号を決定して、前記第２のストレージエンジンにおいてログテーブルを生成するステップと、
   前記ログテーブルにおける隣接する前記第１のストレージエンジンのバージョン番号のデータ対応状況を決定して、データリカバリを実行するステップと、
   を含む請求項５に記載の方法。
7. 前記ログテーブルにおける隣接する前記第１のストレージエンジンのバージョン番号のデータ対応状況を決定して、データリカバリを実行する前記ステップは、
   前記変更情報に対応する処理フローを決定するステップと、
   前記処理フローに少なくとも１つの故障検出点を設置するステップであって、前記故障検出点は、前記第１のストレージエンジンと前記第２のストレージエンジンのインタラクションプロセスに基づいて決定される、ステップと、
   前記故障検出点に基づいて、隣接する前記第１のストレージエンジンのバージョン番号のデータ対応状況を決定して、データリカバリを実行するステップと、
   を含む、請求項６に記載の方法。
8. データリカバリを実行する前記ステップは、
   前記第２のストレージエンジンにおける前記ログテーブルに記録されているバージョン番号を決定するステップと、
   前記変更情報に基づき、前記第１のストレージエンジンのバージョン番号を決定するステップと、
   前記ログテーブルに記録されているバージョン番号と前記第１のストレージエンジンのバージョン番号を比較して、差異レコードを生成するステップと、
   前記差異レコードに基づき、前記第１のインデックステーブル及び前記第２のインデックステーブルを更新するステップと、
   を含む請求項６に記載の方法。
9. 前記ターゲットトランザクションにおけるデータベーススキーマ情報を決定するステップと、
   前記データベーススキーマ情報に基づき、前記第２のインデックステーブルを更新するステップと、
   をさらに含む請求項１から８のいずれか１項に記載の方法。
10. 前記データベーススキーマ情報は、少なくとも１つのインデックスモードを含み、
    前記データベーススキーマ情報に基づき前記第２のインデックステーブルを更新する前記ステップは、前記インデックスモードに基づいて、前記第２のインデックステーブルを分類して、前記第２のインデックステーブルを更新するステップを含み、
    前記インデックスモードは、主キーインデックス、ユニークインデックス又は通常のインデックスを含む、
    請求項９に記載の方法。
11. 前記第２のインデックステーブルの行識別子によって指示される行データは、前記ターゲットインデックスデータにおけるインデックス列に対応し、前記インデックス列は、前記ターゲットトランザクションに基づいて得られ、前記データベーススキーマ情報に基づき前記第２のインデックステーブルを更新するステップは、
    前記データベーススキーマ情報における前記行データに対する処理情報を取得するステップと、
    前記処理情報に基づいて、対応するインデックス列の変更データを抽出するステップと、
    前記インデックス列の変更データに基づき、前記第２のインデックステーブルを更新するステップと、
    を含む請求項９に記載の方法。
12. 前記第１のストレージエンジンは、マルチステートメント同時トランザクションをサポートせず、前記第２のストレージエンジンは、前記マルチステートメント同時トランザクションをサポートする請求項１～１１の何れか一項に記載の方法。
13. データインデックス付け装置であって、
    データインデックス付けプロセスを指示するためのターゲットトランザクションを取得するための取得ユニットと、
    前記ターゲットトランザクションに基づき、第１のストレージエンジンにおけるターゲットインデックスデータを決定するための決定ユニットであって、前記ターゲットインデックスデータは、少なくとも１つの第１のインデックステーブルに含まれる、決定ユニットと、
    前記第１のインデックステーブルに基づき、第２のストレージエンジンに配置される少なくとも１つの第２のインデックステーブルを決定するためのマッピングユニットであって、前記第２のインデックステーブルは、前記第１のインデックステーブルに基づいて行識別子を追加することによって得られ、前記行識別子は、前記ターゲットインデックスデータにおける行データを指示するためのものであり、前記第２のストレージエンジンは、前記ターゲットトランザクションの実行をサポートする、マッピングユニットと、
    前記第２のインデックステーブルから、前記第１のストレージエンジンにおけるデータインデックス条件に対応するインデックスデータを決定するためのインデックスユニットであって、前記インデックスデータは、前記ターゲットインデックスデータに含まれる、インデックスユニットと、
    を含む装置。
14. プロセッサー及びメモリを含むコンピュータ装置であって、
    前記メモリは、プログラムコードを記憶し、前記プロセッサーは、前記プログラムコードにおける命令に基づき、請求項１から１２のいずれか１項に記載のデータインデックス付け方法を実行するコンピュータ装置。
15. コンピュータ上で実行されるときに、前記コンピュータに請求項１から１２のいずれか１項に記載のデータインデックス付け方法を実行させる命令を含むコンピュータプログラム。

Images