(57)【要約】  本願は、ダークローンチ実現方法、装置、計算ノード及びシステムを開示し、当該方法は、受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であることを決定することと、予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定することと、第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行することとを含む。本願に係る技術的解決手段により、データベース層において試用ユーザーと正式ユーザーを区別することができ、ダークローンチの目的が簡単かつ効果的に達成されるとともに、サービス変更量が低減される。
2021513694.tif 000002
【特許請求の範囲】
【請求項１】
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であることを決定することと、
予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定することと、
第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行することとを含む、ダークローンチ実現方法。
【請求項２】
予め設定された前記パーティション設定情報に基づいて、分散データベースのデータパーティショニング機能を利用して、データベース層において前記試用ユーザーのデータと前記正式ユーザーのデータを区別することをさらに含み、
同一のユーザーが同じパーティション設定情報を使用する、請求項１に記載の方法。
【請求項３】
前記予め設定されたパーティション設定情報に基づいて、試用要求を解析した後、前記実行を行う前に、
予め設定された試用修正設定情報に基づいて、前記第１の試用要求又は前記第２の試用要求における、試用ユーザーのデータを要求する部分を書き換えることをさらに含む、請求項１に記載の方法。
【請求項４】
前記試用ユーザーと前記正式ユーザーの使用するデータテーブル構造が異なりながら、使用する名称が同じであるように、前記試用修正設定情報に基づいて、試用ユーザーデータベースのテーブル構造を書き換えることをさらに含む、請求項３に記載の方法。
【請求項５】
前記受信されたアプリケーション要求が正式データを要求する正式要求であると決定すれば、
正式要求を、正式要求に対応する正式ユーザーが位置する正式データノードに転送して実行することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
予め設定されたＩＰホワイトリストにより、前記受信されたアプリケーション要求をフィルタリングすることにより、前記受信されたアプリケーション要求が試用データを要求する試用要求であるか又は正式データを要求する正式要求であるかを区別する、請求項１に記載の方法。
【請求項７】
前記ＩＰホワイトリストは、正式要求ＩＰホワイトリスト及び試用要求ＩＰホワイトリストを含み、
前記ＩＰホワイトリストにより、受信されたアプリケーション要求をフィルタリングすることは、
正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントからのアプリケーション要求が正式要求であると決定することと、
試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントからのアプリケーション要求が前記試用要求であると決定することと、
非ホワイトリストＩＰからのアプリケーション要求を破棄することとを含む、請求項６に記載の方法。
【請求項８】
前記ロードされたパーティション設定情報に基づいて試用要求を解析することは、
前記試用要求に基づいてクエリが必要とするテーブルを決定することと、
前記パーティション設定情報に基づいて当該テーブルのパーティショニングルールをクエリし、かつパーティショニングルールに応じて当該試用要求に対応するデータノードを決定することとを含む、請求項１〜４のいずれか１項に記載の方法。
【請求項９】
前記第２の試用要求のデータの実行が完了した後、
前記試用ユーザーが位置する試用データノードへ送信した一部の実行結果と、前記正式ユーザーが位置する正式データノードへ送信した一部の実行結果とをまとめることをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１０】
データを再分散し、一部のホットスポットデータを追加パーティションに移動するか又は一部のホットスポットデータを負荷の大きいデータノードから負荷の小さいデータノードに遷移することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１１】
前記試用ユーザーのアプリケーション特性に応じて、対応する試用テーブルのテーブル構造を修正することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１２】
試用アプリケーションが正式に発行されたと判断した場合、全ての正式データベースのデータ構造を、前記試用アプリケーションに対応する試用データベースのデータ構造に修正することと、
試用アプリケーションが適用されないと判断した場合、前記試用アプリケーションに対応する試用データベースのデータ構造を正式データベースのデータ構造にロールバックすることとをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１３】
プロセッサによって実行されると、前記請求項１〜請求項１２のいずれか１項に記載のダークローンチ実現方法のステップを実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体。
【請求項１４】
プロセッサと、前記プロセッサによって実行されると、請求項１〜請求項１２のいずれか１項に記載のダークローンチ実現方法を実現する命令が記憶されているコンピュータ可読記憶媒体とを含む、ダークローンチ実現装置。
【請求項１５】
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定するように構成されるフィルタリングモジュールと、
ロードされたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定するように構成される解析モジュールと、
第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行し、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行するように構成される転送モジュールとを含む、ダークローンチ実現装置。
【請求項１６】
前記試用修正設定情報に基づいて、前記第１の試用要求又は前記第２の試用要求における、試用ユーザーのデータを要求する部分を書き換えて、書き換えた第１の試用要求又は第２の試用要求を前記転送モジュールに出力するように構成される処理モジュールをさらに含む、請求項１５に記載の装置。
【請求項１７】
前記フィルタリングモジュールは、さらに、前記受信されたアプリケーション要求が正式データを要求する正式要求であると決定すれば、正式要求を、正式要求に対応する正式ユーザーが位置する正式データノードに転送して実行するように構成される、請求項１５に記載の装置。
【請求項１８】
前記フィルタリングモジュールは、ＩＰホワイトリストにより、前記受信されたアプリケーション要求をフィルタリングすることにより、前記受信されたアプリケーション要求が試用データを要求する試用要求であるか又は正式データを要求する正式要求であるかを区別する、請求項１５、１６又は１７に記載の装置。
【請求項１９】
前記ＩＰホワイトリストは、正式要求ＩＰホワイトリスト及び試用要求ＩＰホワイトリストを含み、
前記受信されたアプリケーション要求が試用データを要求する試用要求であるか又は正式データを要求する正式要求であるかを区別することは、
正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントからのアプリケーション要求が正式要求であると決定することと、試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントからのアプリケーション要求が試用要求であると決定することと、非ホワイトリストＩＰからのアプリケーション要求を破棄することとを含む、請求項１５、１６又は１７に記載の装置。
【請求項２０】
前記解析モジュールは、前記試用要求に基づいてクエリが必要とするテーブルを決定し、前記パーティション設定情報に基づいて当該テーブルのパーティショニングルールをクエリし、かつパーティショニングルールに応じて当該試用要求に対応するデータノードを決定するように構成される、請求項１５に記載の装置。
【請求項２１】
前記解析モジュールは、さらに、予め設定された前記パーティション設定情報に基づいて、分散データベースのデータパーティショニング機能を利用して、データベース層において試用ユーザーのデータと正式ユーザーのデータを区別するように構成され、同一のユーザーが同じパーティション設定情報を使用する、請求項２０に記載の装置。
【請求項２２】
前記処理モジュールは、さらに、前記試用ユーザーと前記正式ユーザーが使用するデータテーブル構造が異なるように、前記試用修正設定情報に基づいて、試用ユーザーデータベースのテーブル構造を書き換えるように構成される、請求項１５に記載の装置。
【請求項２３】
前記処理モジュールは、さらに、前記試用ユーザーのアプリケーション特性に応じて、対応する試用テーブルのテーブル構造を修正するように構成される、請求項１５に記載の装置。
【請求項２４】
前記処理モジュールは、さらに、前記第２の試用要求のデータの実行が完了した後、前記試用ユーザーが位置する試用データノードへ送信した一部の実行結果と、正式ユーザーが位置する正式データノードへ送信した一部の実行結果とをまとめるように構成される、請求項１５に記載の装置。
【請求項２５】
前記処理モジュールは、さらに、データを再分散し、一部のホットスポットデータを追加パーティションに移動するか又は一部のホットスポットデータを負荷の大きいデータノードから負荷の小さいデータノードに遷移するように構成される、請求項１５に記載の装置。
【請求項２６】
前記処理モジュールは、さらに、
試用アプリケーションが正式に発行されたと判断した場合、全ての正式データベースのデータ構造を、前記試用アプリケーションに対応する試用データベースのデータ構造に修正し、
試用アプリケーションが適用されないと判断した場合、前記試用アプリケーションに対応する試用データベースのデータ構造を正式データベースのデータ構造にロールバックするように構成される、請求項１５に記載の装置。
【請求項２７】
請求項１５〜２６のいずれか１項に記載のダークローンチ実現装置を含む、計算ノード。
【請求項２８】
２つ以上のデータノードを含み、ユーザーデータをキャリアするように構成される分散データベースにおけるデータノードクラスターと、
２つ以上の計算ノードを含み、サービスを外部に提供するように構成される分散データベースにおける計算ノードクラスターとを含み、データがパーティション設定情報によって複数のデータノードに分散され、前記計算ノードが請求項１５〜２６のいずれか１項に記載のダークローンチ実現装置を含むダークローンチ実現システム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、出願番号が２０１７１１４９９１９２．５で、出願日が２０１７年１２月２９日の中国特許出願に基づいて提出され、かつ当該中国特許出願の優先権を主張し、当該中国特許出願の全ての内容は、参照として本願に組み込まれる。
【０００２】
本願は、分散データ処理技術に関し、特に分散データベースに基づくダークローンチ実現方法、装置、計算ノード及びシステムに関するものであるが、これに限定されない。
【背景技術】
【０００３】
システムのアップデートがユーザーの使用に与える影響を低減し、ひいては回避するために、アップデートにダークローンチのポリシーを採用するアプリケーションがますます増えている。ダークローンチ（カナリアリリースともいう）とは、黒と白との間において滑らかに遷移可能なリリース方法である。ダークローンチにはＡ／Ｂテスト（Ａ／Ｂ  ｔｅｓｔｉｎｇ）を行うことができ、すなわち、一部のユーザーが続けて製品機能Ａを使い、他の一部のユーザーが製品機能Ｂを使用し始めるようにし、もしユーザーが製品機能Ｂに対し異議がなければ、範囲を徐々に拡大し、全てのユーザーを製品機能Ｂに遷移する。ダークローンチは、システム全体の安定性を保証することができ、初期に問題を発見して調整することで、その影響を制御することができる。
【０００４】
関連技術では、一般的に使用されるダークローンチポリシーは、アプリケーションが正式ユーザーと試用ユーザーのリストに応じて、対応するトラフィックを元のサービスシステムと新しいサービスシステムにそれぞれ導入することを含む。このような方式は、新しいサービスシステムを追加すると同時に、設定センターなどの一連の機能モジュールを対応して追加する。このように、アプリケーションは、新旧両方のデータ構造及びそのデータ内容を保留するために、元のサービスシステムと新しいサービスシステムに対応する新旧両方のサービスコードを維持する必要がある。
【０００５】
現在、システムは、主にアプリケーション側とサーバー側によりダークローンチを実現し、データベースに関与することはほとんどなく、データベースに関与しても、試用ユーザーと正式ユーザーは、同一のデータベースを使用しながら、冗長フィールドを追加することにより、サービス修正に適応する。例えば、１つのテーブルにおいて、正式ユーザーは、フィールドＡ、フィールドＢ、及びフィールドＣの３つのフィールドを使用する必要があり、試用ユーザーは、フィールドＡ、フィールドＤ及びフィールドＥの３つのフィールドを使用する必要があり、同一のデータベースで正式ユーザーと試用ユーザーをキャリアすると、このテーブルには、フィールドＡ、フィールドＢ、フィールドＣ、フィールドＤ、及びフィールドＥの５つのフィールドが含まれなければならず、明らかに、正式ユーザーのデータにとってフィールドＤとフィールドＥが冗長であり、試用ユーザーのデータにとってフィールドＢとフィールドＣが冗長である。このように、正式アプリケーションがアクセスするとき、それが正式データしかアクセスできないように制限するとともに、フィールドＤとフィールドＥをマスクする必要があり、また、試用アプリケーションがアクセスするとき、それが試用データしかアクセスできないように制限するとともに、フィールドＢとフィールドＣをマスクする必要があり、このような処理によりサービスが制限され、また、試用サービスの修正が複雑になり、後期メンテナンスに不利となり、バージョンのロールバックにも不利となる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記技術的課題を解決するために、本願は、ダークローンチの目的を簡単かつ効果的に達成するとともに、サービス変更量を低減できるダークローンチ実現方法、装置、計算ノード及びシステムを提供する。
【課題を解決するための手段】
【０００７】
本願は、
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であることを決定することと、
予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定することと、
第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行することとを含む、ダークローンチ実現方法を提供する。
【０００８】
本願は、プロセッサによって実行されると、本願の実施例におけるいずれか１つのダークローンチ実現方法のステップを実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体をさらに提供する。
【０００９】
本願は、プロセッサと、前記プロセッサによって実行されると、本願の実施例におけるいずれか１つのダークローンチ実現方法を実現する命令が記憶されているコンピュータ可読記憶媒体とを含む、ダークローンチ実現装置をさらに提供する。
【００１０】
本願は、
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定するように構成されるフィルタリングモジュールと、
ロードされたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定するように構成される解析モジュールと、
第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行し、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行するように構成される転送モジュールとを含む、ダークローンチ実現装置をさらに提供する。
【００１１】
本願は、本願の実施例のいずれか１つに記載のダークローンチ実現装置を含む計算ノードをさらに提供する。
【００１２】
本願は、
２つ以上のデータノードを含み、ユーザーデータをキャリアするように構成される分散データベースにおけるデータノードクラスターと、
２つ以上の計算ノードを含み、サービスを外部に提供するように構成される分散データベースにおける計算ノードクラスターとを含み、データがパーティション設定情報によって複数のデータノードに分散され、前記計算ノードが本願の実施例のいずれか１つに記載のダークローンチ実現装置を含む、ダークローンチ実現システムをさらに提供する。
【００１３】
本願の技術的解決手段は、受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定することと、ロードされたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定することと、予め設定された試用修正設定情報に基づいて、第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を書き換えることと、書き換えた第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行することとを含む。本願に係る技術的解決手段により、データベース層において試用ユーザーと正式ユーザーを区別し、ダークローンチの目的が簡単かつ効果的に達成されるとともに、サービス変更量が低減される。
【００１４】
本発明の他の特徴及び利点は、後述の明細書で説明によって自明になるか又は本発明の実施によって了解される。本発明の目的及び他の利点は、明細書、特許請求の範囲及び図面において特に指摘された構造によって実現し取得することができる。
【図面の簡単な説明】
【００１５】
図面は、本願の技術的解決手段のさらなる理解を提供するためのものであり、明細書の一部を構成し、本願の実施例とともに本願の技術的解決手段を解釈するが、本願の技術的解決手段を限定するものではない
【図１】本願に係るダークローンチ実現方法のフローチャートである。
【図２】本願に係るデータパーティション及び同名異種テーブルを実現する実施例の概略図である。
【図３】本願に係るダークローンチをサポートするユーザーデータパーティションの実施例の概略図である。
【図４】本願に係る分散データベースのデータ再分散の実施例の概略図である。
【図５】本願に係る試用要求レポートの統計処理の実施例の概略図である。
【図６】本願に係る清算処理の実施例のフローチャートである。
【図７】本願に係るダークローンチ実現装置の構成概略図である。
【図８】本願に係る計算ノードの構成実施例の概略図である。
【図９】本願に係る分散データベースに基づいてダークローンチを実現する全体的なアーキテクチャの概略図である。
【図１０】本願に係るダークローンチ実現装置の構成概略図である。
【図１１】本願に係るダークローンチを実現する第１の実施例の概略図である。
【図１２】本願に係るダークローンチを実現する第２の実施例の概略図である。
【図１３】本願に係るダークローンチを実現する第３の実施例の概略図である。
【図１４】本願に係るダークローンチを実現する第４の実施例の概略図である。
【発明を実施するための形態】
【００１６】
本願の目的、技術的解決手段及び利点をより明確にするために、以下、図面を参照しながら本願の実施例を詳細に説明する。なお、衝突しない場合には、本願の実施例と実施例の特徴は、互いに任意に組み合わせることができる。
【００１７】
図１は、本願に係るダークローンチ実現方法のフローチャートであり、図１に示すように、以下を含む。
【００１８】
ステップ１００：計算ノードは、受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定する。
【００１９】
１つの実施形態では、受信されたアプリケーション要求が試用要求であると決定すれば、本願の方法は、
正式要求を、正式要求に対応する正式ユーザーが位置する正式データノードに転送して実行することをさらに含む。
【００２０】
１つの実施形態では、本ステップにおいて、計算ノードは、ＩＰホワイトリストにより、受信されたアプリケーション要求をフィルタリングすることにより、受信されたアプリケーション要求が試用要求であるか又は正式データを要求する正式要求であるかを区別する。
【００２１】
１つの実施形態では、ＩＰホワイトリストは、正式要求ＩＰホワイトリスト及び試用要求ＩＰホワイトリストを含み、ＩＰホワイトリストにより、受信されたアプリケーション要求をフィルタリングすることは、
正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントからのアプリケーション要求が正式要求であると決定することと、
試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントからのアプリケーション要求が試用要求であると決定することと、
非ホワイトリストＩＰからの、すなわち正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントにも属せず、試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントにも属しないアプリケーション要求を破棄することとを含む。
【００２２】
本願は、ＩＰホワイトリストによって不正なアプリケーション要求をフィルタリングする。
【００２３】
本ステップにおいて分散データベースのＩＰホワイトリストによってデータベースクライアントの要求に対してＩＰフィルタリングを行うことを保証するために、本ステップの前に、
アプリケーションと協働して、トラフィックガイダンスをし、例えば、要求に身分情報等を含んで識別して、試用ユーザーと正式ユーザーの要求をそれぞれ異なるＩＰのデータベースクライアント（ユーザーのクライアントではなく、通常はアプリケーションサーバーに配備される）にガイドすることをさらに含む。具体的な実装形態は多く、本願の保護範囲を限定するものではなく、ここでは説明を省略する。
【００２４】
ステップ１０１：予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定する。
【００２５】
１つの実施形態では、パーティション設定情報は、Ｌｉｓｔパーティション、ＥＲパーティション、Ｈａｓｈパーティション、Ｒａｎｇｅパーティションなどの任意の組み合わせを含むが、これらに限定されず、本願では、複数の分散方式によって試用ユーザーと正式ユーザーを組み合わせて区別する。
【００２６】
１つの実施形態では、本願の前に、
予め設定されたパーティション設定情報に基づいて、分散データベースのデータパーティショニング機能を利用して、データベース層において試用ユーザーのデータと正式ユーザーのデータを区別し、すなわち、試用ユーザーと正式ユーザーを区別することをさらに含む。また、本願は、同じパーティション設定情報を使用することにより、同一のユーザーの全ての関連データが同じ分散ルールを有し、すなわち、同一のユーザーのデータ分散には同一のパーティション設定情報を採用することを保証する。同一のユーザーは多くのテーブルに関与する可能性があるが、これらの関連するテーブルには同じパーティション設定情報が採用される。
【００２７】
１つの実施形態では、ステップ１０１において予め設定されたパーティション設定情報に基づいて試用要求を解析することは、具体的に、試用要求に基づいてクエリが必要とするテーブルを決定することと、パーティション設定情報に基づいて当該テーブルのパーティショニングルールをクエリし、かつパーティショニングルールに応じて当該試用要求に対応するデータノードを決定することとを含む。
【００２８】
一例を挙げると、試用要求の構文がｓｅｌｅｃｔ＊ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ＝３であると仮定し、予め設定されたパーティション設定情報に基づいて、テーブルＴがｉｄによりｒａｎｇｅパーティションされ、かつｉｄ１〜ｉｄ１０がデータノード１に分散され、ｉｄ１１〜ｉｄ２０がデータノード２に分散されていることが分かっていると仮定すると、当該試用要求のデータがデータノード１に分散され、すなわち、当該試用要求をデータノード１に送信して実行することが解析によって分かる。
【００２９】
ステップ１０３：第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行し、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行する。
【００３０】
１つの実施形態では、試用ユーザーと正式ユーザーに同時に関与する第２の試用要求、例えば、統計レポートなどに対して、データの実行が完了した後に、要求をまとめることにより、試用ユーザーが位置する試用データノードへ送信さした一部の実行結果と、正式ユーザーが位置する正式データノードへ送信した一部の実行結果とをまとめることをさらに含む。
【００３１】
１つの実施形態では、ステップ１０１の後、ステップ１０３の前に、本願に係るダークローンチ実現方法は、
ステップ１０２：予め設定された試用修正設定情報に基づいて、第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を書き換えることをさらに含む。
【００３２】
分散データベースは、名称が同じであるがデータ構造が異なるテーブルである同名異種テーブルをサポートし、試用サービスのデータ構造及びサービスロジックへの要求を満たすために、１つの実施形態では、本願の前に、
試用ユーザーと正式ユーザーが使用するデータテーブル構造が異なるように、試用修正設定情報に基づいて、試用ユーザーデータベースのテーブル構造を書き換えることをさらに含む。試用ユーザーのテーブルのテーブル構造と正式ユーザーのテーブルのテーブル構造は異なるが、両者は依然として同じ名称のテーブルを使用する。
【００３３】
一例を挙げると、要求に２つの構文があり、１番目の構文がｓｅｌｅｃｔ  Ａ，Ｂ，Ｃ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ＝３であり、２番目の構文がｓｅｌｅｃｔ  Ａ，Ｂ，Ｃ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ＝１３であると仮定し、予め設定されたパーティション設定情報に基づいて、テーブルＴがｉｄによりｒａｎｇｅパーティションされ、かつｉｄ１〜ｉｄ１０がデータノード１に分散され、ｉｄ１１〜ｉｄ２０がデータノード２に分散されていることが分かっていると仮定すると、
１番目の構文に対して、試用修正設定情報が追加されていないとすれば、ＳＱＬを書き換える必要がなく、１番目の構文をそのままパーティションデータノード１に送信し、２番目の構文に対して、Ｄ＝Ａ＋Ｂ、Ｅ＝１０＊Ｃという試用修正設定情報が追加されたと仮定すれば、元の構文におけるＢがＤ−Ａに置き換えられ、元の構文におけるＣがＥ／１０に置き換えられ、最終的にパーティションデータノード２に送信される構文はｓｅｌｅｃｔ  Ａ，Ｄ−Ａ，Ｅ／１０  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ＝１３に書き換えられる。
【００３４】
すなわち、試用修正設定情報がどのテーブルに関与するか、どのフィールドに関与するかによって書き換えが必要であるか否かを判断し、修正に関与されないフィールドであれば、ＳＱＬを書き換える必要がない。
【００３５】
このように、サービスの同じ構文を用いた異種データベースへのアクセスサポートが実現され、次元が一致しない場合が生じない。例えば、元のテーブル内のフィールドはフィールドＡ、フィールドＢ及びフィールドＣであり、試用ユーザーのフィールドはフィールドＡ、フィールドＤ及びフィールドＥである。Ｄ＝Ａ＋Ｂ、Ｅ＝１０＊Ｃであれば、本願の書き換え方式に従って、試用ユーザーのテーブルは実際にはフィールドＡ、フィールド（Ａ＋Ｂ）及びフィールド（１０＊Ｃ）であり、この次元は以前と一致し、容易にロールバックできることを保証でき、情報を失うことがない。
【００３６】
図２は、本願に係るデータパーティション及び同名異種テーブルを実現する実施例の概略図であり、分散データベースを使用しない場合、同一のテーブルの全てのデータが１つのデータノードにセットされ、テーブル内に全てのデータ行が記憶され、図２の左側に示すように、シングルノード上のテーブルＴには９行のデータがセットされている。分散データベースを使用する場合、データが３つのデータノードに分散され、かつデータノード１に１行目〜４行目がセットされ、データノード２に５行目〜８行目がセットされ、データノード３に９行目がセットされると仮定すれば、図２におけるデータ分散方式は、様々なポリシーによって実現することができる。
【００３７】
例えば、Ｌｉｓｔパーティションを採用すれば、枚挙の方式、例えばｓｅｔ１｛１、２、３、４｝、ｓｅｔ２｛５、６、７、８｝、ｓｅｔ３｛９｝によってデータを異なるデータノードに分散することができ、
また、例えば、Ｒａｎｇｅパーティションを採用すれば、画定範囲、例えばｓｅｔ１｛１〜４｝、ｓｅｔ２｛５〜８｝、ｓｅｔ３｛９〜∞｝によってデータを異なるデータノードに分散することができ、
さらに、例えば、他のパーティション方式、例えばＨａｓｈパーティション、関係パーティションなどを採用する。
【００３８】
１つの実施形態では、異なるデータノード上のテーブルＴの構造が異なることを期待する場合、テーブル構造を修正することができる。図２におけるデータノード２及びデータノード３上のテーブルＴについて、ａｌｔｅｒによってテーブル構造を操作し、例えばａｌｔｅｒ  ｔａｂｌｅ  ｓｅｔ  Ｃ＝Ｂ−Ｃにすることで、データノード２上のテーブル構造をＴ（Ａ、Ｂ、Ｂ−Ｃ）に修正し、例えばａｌｔｅｒ  ｔａｂｌｅ  ｓｅｔ  Ｃ＝Ｂ＋Ｃにすることで、データノード３上のテーブル構造をＴ（Ａ、Ｂ、Ｂ＋Ｃ）に修正することができる。
【００３９】
なお、テーブル構造の修正は、計算ノードのテーブルの作成後に行われ、データノード全体が計算ノードに示すのは、依然として元のテーブル構造Ｔ（Ａ、Ｂ、Ｃ）である。すなわち、分散データベースの場合、計算ノードによって外部にテーブル構造を示し、正式データベースと試用データベースにおけるテーブルＴは全体であり、どのような試用修正が行われても、外部に示されるテーブル面構造がＴ（Ａ、Ｂ、Ｃ）のままである。
【００４０】
図３は、本願に係るダークローンチをサポートするユーザーデータパーティションの実施例の概略図であり、図３に示すように、試用ユーザーの選択ポリシーを設定する必要があり、すなわち、分散データベースのパーティションポリシーを予め設定する必要があり、例えば、範囲に従ってＩＤが１〜１００のユーザーを試用ユーザーとして設定することができ、これはＲａｎｇｅ分散に属し、データは正式データと試用データに分けられる。同一のユーザーの全てのデータが同一のデータベースに分散され、正式ユーザーに関連するテーブルＴ１、テーブルＴ２、テーブルＴ３及びテーブルＴ４がいずれも正式データノードに分散され、試用ユーザーに関連するテーブルＴ１、テーブルＴ２、テーブルＴ３及びテーブルＴ４がいずれも試用データノードに分散されることを保証するために、関連するテーブルに対して同じ分散ルールを設定する。
【００４１】
試用ユーザーの関連するテーブルについて、試用サービスの需要に応じて、対応するテーブルの構造を修正し、図４の試用ライブラリに示すように、テーブル名は正式データノードにおけるテーブル名と一致するが、テーブル構造は異なる。テーブル構造の修正について、例えば正式ライブラリのテーブルＴ（Ａ、Ｂ、Ｃ）の試用ライブラリのテーブルＴ（Ａ、Ｂ、Ｂ−Ｃ）に変更するには、対応テーブルのＳＱＬ書き換え設定（例えばＣ＝Ｂ−Ｃ）を追加すればいい。
【００４２】
なお、正式ユーザーのクエリは、正式ライブラリ（左側の破線枠内のデータ）のみに関与し、試用ユーザーのクエリは、試用ライブラリ及び正式ライブラリ（右側の破線枠内のデータ）に関与する。
【００４３】
試用ユーザーは、グレーリストの群衆に関与しないＳＱＬ要求に対して、グレーリストを静的ルーティングしてスクリーニングした後、ＳＱＬ構文をそのまま正式ライブラリに送信し、図４の基本情報テーブル２に示すとおりである。試用ユーザーは、グレーリストの群衆に関与するＳＱＬ要求に対して、対応するＳＱＬを書き換えた後、試用ノードに送信して実行し、例えば、書き換え設定に従って、元のｓｅｌｅｃｔ  Ｃ  ｆｒｏｍ  Ｔをｓｅｌｅｃｔ  Ｂ＋Ｃ  ｆｒｏｍ  Ｔに書き換えた後に試用ノードに送信する。
【００４４】
分散データベースにとって、データパーティショニング技術が使用されるため、データが細かいシャーディング（ｓｈａｒｄｉｎｇ）に分割され、データノードクラスターに分散され、実行中にサービスのホットスポットデータが現れることは不可避であり、サービス負荷があるパーティションに集中して、シングルデータノードのストレスが過大になることを引き起こす恐れがあり、装置をより上手く利用することを保証するために、１つの実施形態では、本願は、
データを再分散して負荷を均等化することをさらに含み、データを再分散して負荷を均等化することは、一部のホットスポットデータを追加パーティションに移動するか又は負荷の大きいデータノードから負荷の小さいデータノードに遷移することを含む。
【００４５】
ユーザーのパーティションについて、分散データベースのデータ再分散機能によって再パーティショニングを実現することができる。データ再分散機能を利用することにより、サービスが停止しない場合に既定のパーティション設定情報に基づいてデータを遷移することが実現される。図４に示すように、元のデータが４つのデータノードに分散されるが、データノード４のストレスが大きいため、データノード４のデータを再分散し、例えば、一部のデータを追加のデータノード５に遷移することができる。
【００４６】
１つの実施形態では、本願の方法は、試用ユーザーのアプリケーション特性に応じて、対応する試用テーブルのテーブル構造を修正することをさらに含む。例えば、元のデータベースにおいて、あるフィールドＭは「元」を単位とするが、サービスロジックがユーザーに示すのは「万元」を単位とすることである。その場合に、試用修正によって、データベースにおける当該フィールドをＭ／１００００に修正する。
【００４７】
テーブルＴを例にして、対応する正式データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＣを含み、対応する試用データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＤを含むと仮定し、設定ルールがＤ＝Ｃ＋Ｂであると仮定すれば、アプリケーション要求、例えば汎用のＳＱＬ要求における、フィールドＣを含む構文にとって、書き換えルールである試用修正設定情報は、Ｃ＝Ｄ−Ｂである。具体な例は表１に示すとおりである。
【００４８】
【表１】
2021513694.tif 000003
【００４９】
このように、計算ノードが汎用のＳＱＬ要求を受信すると、まず、予め設定されたパーティション設定情報に基づいて、関与するデータパーティションを判断し、正式データベースと試用データベースのユーザーに同時に関与すれば、ＳＱＬ書き換えルールに従って書き換えが必要であるか否かを判断し、最後に、書き換えた構文を対応するデータベース（ＤＢ）であるデータノードに送信する。
【００５０】
１つの実施形態では、本願の方法は、
ユーザーは試用アプリケーションが正式に発行可能であると判断した場合、全ての元の正式データベースのデータ構造を試用データベースのデータ構造に修正し、すなわち元の正式データベースのデータ構造をアップデート処理し、
ユーザーは試用アプリケーションが適用されないと判断した場合、試用データベースのデータ構造を正式データベースのデータ構造にロールバックし、すなわち試用データベースのデータ構造をロールバック処理する。
【００５１】
上記アップデート又はロールバックシーンに対して、ＳＱＬ設定ルールに対して自動化スクリプトを生成することによりアップデートを実行してもよく、データを導入してユーザーを遷移することにより実現してもよい。
【００５２】
テーブルＴを例にして、対応する正式データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＣを含み、対応する試用データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＤを含むと仮定し、かつ設定ルールがＤ＝Ｃ＋Ｂであると仮定すれば、アップデート及びロールバックスクリプトは表２に示すとおりである。
【００５３】
【表２】
2021513694.tif 000004
【００５４】
テーブルＴ１を例にして、対応する正式データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＣを含み、対応する試用データベースにおけるフィールドがフィールドＡ、フィールドＢ及びフィールドＤを含むと仮定し、テーブルＴ２の対応する正式データベースにおけるフィールドがフィールドＥ、フィールドＦ及びフィールドＧを含むと仮定し、かつ設定ルールがＴ１．Ｄ＝Ｔ１．Ａ＋Ｔ１．Ｂ＋Ｔ２．Ｇであると仮定すれば、アップデート及びロールバックスクリプトは表３に示すとおりである。
【００５５】
【表３】
2021513694.tif 000005
【００５６】
試用ユーザー及び正式ユーザーに同時に関与する要求は、一般的に統計レポートの処理であり、図５は、本願に係る試用要求レポートの統計処理の実施例の概略図であり、図５に示すように、試用ユーザー及び正式ユーザーに同時に関与する要求は、一般的に統計レポートの処理であり、正式データベースと試用データベースは、同一のレポート生成プログラムを共用し、例えば、同一の記憶プログラムにより生成されるレポートは、割り当てレポートのように構造が同じであり、計算ノードは、正式データベースと試用データベースのレポート生成プログラムを呼び出すことを担当し、ＳＱＬ書き換えルールをロードすることによりレポート生成プログラムに異なるパラメータを導入し、各データベースにおける同名異種テーブルのテーブル構造をマッチングし、計算ノードは、各データベースの生成したレポートである割り当てレポートをまとめることを担当する。
【００５７】
図５に示すように、記憶過程を例にして、正式データベース及び試用データベースには、いずれも上記同一の記憶過程が存在し、計算ノードがレポート生成命令を発行すると、レポートに関与するテーブルに基づいて異なる書き換えルールをトリガし、異なるパラメータを導入し、例えば、テーブルＴに対して、正式データベースの記憶過程においてフィールドＣにバッチ処理を行い、試用データベースの記憶過程においてフィールドＥ／１０の結果を処理する。
【００５８】
図５に示すように、統計記憶過程を例にして、当該記憶過程は、テーブル内に１００よりも大きいあるフィールドの個数を統計する。正式データベースでは、フィールドＣに直接導入するが、試用データベースでは、正確な統計を実現しようとすると、Ｅ／１０を導入する必要がある。
【００５９】
図６は、本願に係る清算処理の実施例のフローチャートであり、図６に示すように、ダークローンチにおける清算プログラムは主に、１部のみの清算ファイルがあり、請求書記録テーブルが正式データベース及び試用データベースに分散され、正式データベースと試用データベースにおける清算記録テーブルの構造が異なる可能性があるという２つの問題を処理する。
【００６０】
正式データベース及び試用データベースにおいて清算仮テーブルを作成し、仮テーブルのテーブル構成と清算システムから導出された清算データファイルを一致させることと、
計算ノードが清算データファイル内のエントリを、正式ユーザー（図６のエントリ１、エントリ２及びエントリ３）、試用ユーザー（図６のエントリ４及びエントリ５）のパーティション設定ルールに従って対応する仮テーブルに導入することと、
計算ノードが、各データベースにおける清算プログラム（例えば、記憶過程）を呼び出し、ＳＱＬ書き換えルールをロードすることにより、異なるパーティションノードにおける清算プログラムに異なるパラメータを導入し、データベース内の同名異種の清算テーブルをマッチングする（書き換えることにより、要求内の構文を、データベース内のテーブルの構造と同じようにする調整する）ことと、
各割り当てられたデータベースの清算が終了した後、計算ノードが清算結果をまとめることとを含む。
【００６１】
図７は、本願に係るダークローンチ実現装置の構成概略図であり、図７に示すように、前記装置は、
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定するように構成されるフィルタリングモジュールと、
予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定するように構成される解析モジュールと、
第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行し、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行するように構成される転送モジュールとを少なくとも含む。
【００６２】
１つの実施形態では、本願に係る装置は、
予め設定された試用修正設定情報に基づいて、第１の試用要求又は第２の試用要求における、試用ユーザーのデータを要求する部分を書き換え、そして書き換えた第１の試用要求又は第２の試用要求を転送モジュールに出力するように構成される処理モジュールをさらに含む。
【００６３】
１つの実施形態では、フィルタリングモジュールは、さらに、受信されたアプリケーション要求が正式データを要求する正式要求であると決定すれば、正式要求を、正式要求に対応する正式ユーザーが位置する正式データノードに転送して実行するように構成される。
【００６４】
１つの実施形態では、フィルタリングモジュールは、ＩＰホワイトリストにより、受信されたアプリケーション要求をフィルタリングすることにより、受信されたアプリケーション要求が試用データを要求する試用要求であるか又は正式データを要求する正式要求であるかを区別するように構成される。より具体的には、
ＩＰホワイトリストは、正式要求ＩＰホワイトリスト及び試用要求ＩＰホワイトリストの２つの部分に分けられ、正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントからのアプリケーション要求が正式要求であり、試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントからのアプリケーション要求が試用要求であり、非ホワイトリストＩＰからのアプリケーション要求が破棄される。
【００６５】
１つの実施形態では、解析モジュールは、試用要求に基づいてクエリが必要とするテーブルを決定し、パーティション設定情報に基づいて当該テーブルのパーティショニングルールをクエリし、かつパーティショニングルールに応じて当該試用要求に対応するデータノードを決定するように構成される。
【００６６】
１つの実施形態では、解析モジュールは、さらに、予め設定されたパーティション設定情報に基づいて、分散データベースのデータパーティショニング機能を利用して、データベース層において試用ユーザーのデータと正式ユーザーのデータを区別し、すなわち、試用ユーザーと正式ユーザーを区別するように構成される。また、本願は、同じパーティション設定情報を用いて、同一のユーザーの全ての関連データが同じ分散ルールを有することを保証する。
【００６７】
１つの実施形態では、処理モジュールは、さらに、試用ユーザーと正式ユーザーが使用するデータテーブル構造が異なるように、試用修正設定情報に基づいて、試用ユーザーデータベースのテーブル構造を書き換えるように構成される。
【００６８】
１つの実施形態では、処理モジュールは、さらに、試用ユーザーのアプリケーション特性に応じて、対応する試用テーブルのテーブル構造を修正するように構成される。
【００６９】
１つの実施形態では、処理モジュールは、さらに、試用ユーザーと正式ユーザーに同時に関与する第２の試用要求、例えば統計レポートなどに対して、データの実行が完了した後、試用ユーザーが位置する試用データノードへ送信した一部の実行結果と、正式ユーザーが位置する正式データノードへ送信した一部の実行結果とをまとめるように構成される。
【００７０】
１つの実施形態では、処理モジュールは、さらに、データを再分散して負荷を均等化するように構成され、データを再分散して負荷を均等化することは、一部のホットスポットデータを追加パーティションに移動するか又は負荷の大きいデータノードから負荷の小さいデータノードに遷移することを含む。
【００７１】
１つの実施形態では、処理モジュールは、さらに、
ユーザーが、試用アプリケーションが正式に発行可能であると判断した場合、全ての元の正式データベースのデータ構造を試用データベースのデータ構造に修正し、すなわち元の正式データベースのデータ構造をアップデート処理し、ユーザーが、試用アプリケーションが適用されないと判断した場合、試用データベースのデータ構造を正式データベースのデータ構造にロールバックし、すなわち試用データベースのデータ構造をロールバック処理するように構成される。
【００７２】
実際の応用において、上記ダークローンチ実現装置における各手段が実現する機能は、いずれもダークローンチ実現装置にある中央処理装置（ＣＰＵ、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサ（ＭＰＵ、Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｏｒ  Ｕｎｉｔ）、デジタルシグナルプロセッサ（ＤＳＰ、Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）などによって実現できる。
【００７３】
図８は、本願に係る計算ノードの構成実施例の概略図であり、図８に示すように、ＩＰホワイトリスト、静的ルーティングモジュール及びデータ書き換えモジュールを含み、ＩＰホワイトリストが具体的に図７のいずれか１つのフィルタリングモジュールのように実現され、静的ルーティングモジュールが具体的に図７のいずれか１つの解析モジュールのように実現され、データ書き換えモジュールが具体的に図７のいずれか１つの処理モジュールのように実現される。
【００７４】
データノードが起動するとき、計算ノードは、ＩＰホワイトリストによってＩＰホワイトリスト設定情報をロードし、静的ルーティングモジュールによってデータパーティション設定情報をロードし、ＳＱＬデータ書き換えモジュールによってＳＱＬ書き換えルール設定情報をロードする。本願に係る計算ノードの動作原理は、以下を含む。
【００７５】
データ計算ノードのＩＰホワイトリストモジュールは、受信した全ての外部アプリケーション要求に対してホワイトリストのフィルタリングを行い、ホワイトリストが、正式要求ＩＰホワイトリストと試用要求ＩＰホワイトリストの２つの部分を含む。非ホワイトリストＩＰから送信されてきたＳＱＬ要求を破棄し、正式クライアント（例えば、図中のＩＰ１）から送信されてきた要求をそのまま正式データベースに送信し、試用クライアント（例えば、図中のＩＰ２）から送信されてきた要求を静的ルーティングモジュールに送信して処理し、
計算ノードの静的ルーティングモジュールは、データパーティション設定情報に基づいてＳＱＬ要求に対してルーティング及び解析を行う。ＳＱＬ要求を解析することにより、ＳＱＬ要求を、正式データの個別要求、試用データの個別要求及び多部分ユーザーデータの同時要求の３種類に分類する。正式データを要求するＳＱＬ要求を正式データベースに送信し、試用データを要求するＳＱＬ要求と多部分ユーザーデータを同時に要求するＳＱＬ要求とをデータ書き換えモジュールによって書き換えた後に試用データベースに送信する。
【００７６】
図９は、本願に係る分散データベースに基づいてダークローンチを実現する全体的なアーキテクチャの概略図であり、図９に示すように、分散データベースの先端は、複数のアプリケーション、例えば図１のアプリケーション１、アプリケーション２…アプリケーションＸに通信し、複数のアプリケーションは、それぞれ正式ユーザーからのアプリケーション要求と試用ユーザーからのアプリケーション要求とを処理するために用いられる。
【００７７】
分散データベース内のデータノードクラスターは、複数のデータノード、例えば図１のデータノード１、データノード２…データノードＭを含み、全てのユーザーデータをキャリアするために用いられる。データは、パーティションポリシーによって複数のデータノードに分散され、各データノードは、一部のユーザーデータをキャリアする。
【００７８】
分散データベース内の計算ノードクラスターは、複数の計算ノード、例えば図１の計算ノード１、計算ノード２…計算ノードＮを含み、外部にサービスを提供するために用いられ、具体的に図８のいずれか１つの計算ノードを含む。計算ノードは、無共有アーキテクチャを採用し、アプリケーションに統一的な標準構造化クエリ言語（ＳＱＬ）インタフェースを提供し、複数の計算ノードは、ロードバランシングを行う。計算ノードは、データパーティション情報に基づいて対応するデータセット位置を見つけることにより、対応するＳＱＬ構文を対応するデータノードに送信して実行することができる。
【００７９】
本願は、プロセッサによって実行されると、上記いずれか１つのダークローンチ実現方法のステップを実現するコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体をさらに提供する。
【００８０】
図１０は、本願に係るダークローンチ実現装置の構成概略図であり、図１０に示すように、プロセッサと、上記プロセッサによって実行されると、上記いずれか１つのダークローンチ実現方法を実現する命令が記憶されているコンピュータ可読記憶媒体とを含む。
【００８１】
コンピュータ可読記憶媒体は、フラッシュメモリ、ハードディスク、マルチメディアカード、カード型メモリ（例えば、ＳＤメモリーカード（ＳＤカード、Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  Ｍｅｍｏｒｙ  Ｃａｒｄ）又はデータレジスタ（ＤＸ、Ｄａｔａ  Ｒｅｇｉｓｔｅｒ）メモリなど）、ランダムアクセスメモリ（ＲＡＭ、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、静的ランダムアクセスメモリ（ＳＲＡＭ、Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、リードオンリーメモリ（ＲＯＭ、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、電気的に消去可能なプログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ、Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、プログラマブルリードオンリーメモリ（ＰＲＯＭ、Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気メモリ、磁気ディスク、光ディスクなどのうちのいずれか１つ又は複数を含む。
【００８２】
プロセッサは、中央処理装置（ＣＰＵ、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、コントローラ、マイクロコントローラ、マイクロプロセッサ又は他のデータ処理チップなどであってよい。
【００８３】
以下、具体的な応用シーンを参照しながら本願に係るダークローンチ実現方法について詳細に説明する。
【００８４】
第１の実施例は、分散データベースがサービスの多段ダークローンチをサポートする実施例であり、図１１は、本願に係るダークローンチを実現する第１の実施例の概略図であり、図１１に示すように、第１の実施例の分散データベースは複数のデータノードがあり、通常、全てのデータが正式ライブラリにセットされる。ユーザーが複数の試用修正の比較を同時に行うことを望む場合、試用ユーザーのデータを他の複数のデータノード、例えば試用ライブラリ１、試用ライブラリ２…試用ライブラリｎに割り当てて実行する。具体的には以下を含む。
【００８５】
分散データベースの再分散機能を使用し、試用テストのユーザー分布設定情報ルールに従ってテーブルのパーティション情報を設定し、予め設定された、サービスを満たす適切なパーティションルールを採用して、データに再分散操作を行い、一類試用修正に応用される試験ユーザーのデータを試用ライブラリ１に設定し、二類試用修正に応用される試験ユーザーのデータを試用ライブラリ２に設定し、…ｎ類試用修正に応用される試験ユーザーのデータを試用ライブラリｎに設定し、
パーティション１からパーティションｎまでのそれぞれに対してテーブル構造の試用修正操作を行い、それぞれ新しいパーティション上のテーブルにａｌｔｅｒ操作を行い、例えば、ａｌｔｅｒ  Ｔ  ｓｅｔ  Ｃ＝Ｃ＋１、ａｌｔｅｒ  Ｔ  ｓｅｔ  Ｃ＝Ｃ＋２、…ａｌｔｅｒ  Ｔ  ｓｅｔ  Ｃ＝Ｃ＋ｎにし、異なるパーティションでは、テーブル構造の試用修正操作に対して、対応するＳＱＬ書き換え設定を追加し、例えば、データノードｎにＣ＝Ｃ−ｎを追加する。
【００８６】
このように、システムが実行するとき、計算ノードの静的ルーティングモジュールは、元のＳＱＬ構文を解析しルーティング分割し、全ての分割後のＳＱＬに対して、データ書き換えモジュールによって、当該ＳＱＬに対応する実行ノードのＳＱＬ書き換えルールを見つけ、書き換えた後に対応する試用ライブラリに送信して実行する。構文ｓｅｌｅｃｔ  Ｃ  ｆｒｏｍ  Ｔを例にして、対応するパーティション２上の構文をｓｅｌｅｃｔ  Ｃ−１  ｆｒｏｍ  Ｔに書き換え、対応するパーティション３上の構文をｓｅｌｅｃｔ  ｃ−２  ｆｒｏｍ  Ｔに書き換え、…対応するパーティションｎ上の構文をｓｅｌｅｃｔ  ｃ−ｎ  ｆｒｏｍ  Ｔに書き換える。
【００８７】
全てのオンラインのシングルノード取引（１つのユーザーデータのみに関与するオンラインサービス）はそのまま戻り、計算ノードが構文ｓｅｌｃｅｔ  ｃ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ  ｉｎ  ｓｅｔ  ｎをノードｎのみに送信すると判断すれば、当該構文をｓｅｌｃｅｔ  ｃ−ｎ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ  ｉｎ  ｓｅｔ  ｎに書き換え、バッチのノードクロス取引（複数のパーティションの複数のユーザーに関与するサービス）を、計算ノードによってまとめた後に戻し、計算ノードが構文ｓｅｌｃｅｔ  ｃ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ  ｉｎ  ｓｅｔ｛ｎ−１，ｎ｝をノード（ｎ−１）とノードｎに送信すると判断すれば、当該構文を２つの構文に分割し、１つの構文ｓｅｌｅｔ  ｃ−（ｎ−１）  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ  ｉｎ  ｓｅｔ  ｎ−１をノード（ｎ−１）に送信し、別の構文ｓｅｌｅｔ  ｃ−ｎ  ｆｒｏｍ  Ｔ  ｗｈｅｒｅ  ｉｄ  ｉｎ  ｓｅｔ  ｎをノードｎに送信する。
【００８８】
各試用ノードの試験が完了した後、ある試用修正タイプがユーザーの需要を満たせば、当該試用ノードの修正タイプに対応するＳＱＬ書き換え設定情報によってアップデートスクリプトを直接生成し、かつ当該アップデートスクリプトを利用してデータベース全体に試用アップデートを行うことができる。
【００８９】
第２の実施例は、分散データベースがグローバルサービスの統一的建設をサポートすることであり、図１２は、本願に係るダークローンチを実現する第２の実施例の概略図であり、図１２に示すように、第２の実施例では、サービス設計部門が統一的なアプリケーションプラットフォームの構築を担当し、データ構造を統一的に求めることにより、データレポートの統計を容易にし、下部のサービス建設部門がそれぞれいくつかの特別な需要を有し、同一のサービスに対する処理方式がそれぞれ異なると仮定する。この場合には、本願に係る分散データベースシステムを使用して、グローバルサービスの統一的建設需要を満たすことができる。具体的には以下を含む。
【００９０】
異なるサービス建設部は、統一されたサービスに対して同じテーブル名Ｔを使用し、またプラットフォームのデータ統一に対する要件を満たす。分散データベースの再分散機能を使用し、各部門のユーザー分布設定ルールに従ってテーブルのパーティション情報を設定し、データを再パーティショニングし、例えば、部門１のデータをサービスライブラリ１に設定し、部門２のデータをサービスライブラリ２に設定し、…部門ｎのデータをサービスライブラリｎに設定し、各建設部門は、それぞれのサービスロジックに従って、それぞれのテーブル構造を修正し、それぞれのａｌｔｅｒ構文を実行する。異なるパーティションでは、各部門は、テーブル構造の修正操作に対して、対応するＳＱＬ書き換え設定ルールを追加する。
【００９１】
このように、システムが実行するとき、計算ノードの静的ルーティングモジュールは、ＳＱＬ構文を解析し分割し、全ての分割後のＳＱＬ要求が対応する分割サービスライブラリを有し、対応する分割サービスライブラリのデータ書き換えモジュールによって、対応するＳＱＬ書き換えルールを見つけ、書き換えた後に対応する分割サービスライブラリに送信して実行する。
【００９２】
各サービス構築部門のそれぞれのサービスライブラリに関与するデータのみはそのまま戻り、プラットフォーム部門の統一的なバッチ取引、例えばグローバル統計のようなサービスライブラリクロスクエリは計算ノードによってまとめられた後に戻る。
【００９３】
異なるサービスライブラリは、常に異なるテーブル構造及びデータ書き換えルールを維持する。このように、それぞれのサービスがプラットフォームの統一的要件と矛盾するとき、それぞれのテーブル構造を修正し設定ルールを書き換えることにより調整する。
【００９４】
第３の実施例は、分散データベースを用いてサービスのアップデート及びロールバックを迅速に行い、図１３は、本願に係るダークローンチを実現する第３の実施例の概略図であり、図１３に示すように、第３の実施例では、本願に係る対応するアップデート及びロールバック方法を用いて、サービスバージョンのアップデート及びロールバックを迅速に実現し、かつ基本的にサービス時間を占有せず、サービス中断を引き起こさない。具体的には以下を含む。
【００９５】
サービスがアップデートする必要がある場合、サービスコードを修正する必要がなく、テーブル構造を修正し、構文ａｌｔｅｒ  ｓｅｔ  Ｃ＝Ｂ＋Ｃを実行することにより、元のテーブルＴ（Ａ、Ｂ、Ｃ）をテーブルＴ（Ａ、Ｂ、Ｂ＋Ｃ）にランクアップすればよい。テーブルＴからテーブルＴ´までのテーブル構造の修正に対して、対応するＳＱＬ書き換え設定情報であるＣ＝Ｂ＋Ｃを追加し、追加した後、テーブルＴ’に関連するＳＱＬ構文の全てを当該ＳＱＬ書き換え設定情報に従って書き換え、すなわち、元のＳＱＬコードにおけるＣをＣ−Ｂに置き換え、置き換え完了後に対応するデータノードに送信して実行する。
【００９６】
サービスがロールバックする必要がある場合、サービスコードを修正する必要がなく、そのままテーブルＴに構文ａｌｔｅｒ  ｓｅｔ  Ｃ＝Ｃ−Ｂの操作を実行し、テーブルＴを先のテーブルＴのデータ構造に戻すとともに、ＳＱＬ書き換え設定情報Ｃ＝Ｂ＋Ｃを削除すればよい。このように、サービスが前のバージョンにロールバックすることが簡単に実現される。
【００９７】
第４の実施例は、ＳＱＬ自動書き換え機能とルーティングマスク機能を用いてサービスをホットフィックスし、図１４は、本願に係るダークローンチを実現する第４の実施例の概略図であり、図１４に示すように、第４の実施例では、分散データベースのデータノードの個数を問わない。通常、サービス実行は正常である。ＳＱＬに関連するサービスロジックバグ（ｂｕｇ）が現れるとき、本願に係るＳＱＬ書き換え機能又はＳＱＬマスク機能によってサービスロジックを修正して、ｂｕｇによるユーザーへの影響を低減することができる。具体的には以下を含む。
【００９８】
生産環境で正常に動作する過程で、特に携帯電話のＡＰＰの場合、ロジックｂｕｇが現れれば、アプリケーションが既にユーザーに配布されており、ユーザーのクライアントＡＰＰを直接修正する必要がなく、このような問題に対して、本願は、２つの処理方式を有し、
ロジックが簡単であるｂｕｇに対して、ｂｕｇを修正するロジックに基づいて、関連するテーブルのＳＱＬ書き換え設定情報を追加するか又は修正し、元のｂｕｇのＳＱＬロジックを正常なＳＱＬロジックに修正することにより、ｂｕｇ修正の目的を達成する。例えば、元のＳＱＬ構文がｓｅｌｅｃｔ  Ａ  ｆｒｏｍ  ｔａｂｌｅ  Ｔであり、サービスにおいて単位の計算が間違っており、戻す必要があるのが１０００＊Ａであると仮定すれば、ＳＱＬ書き換え設定情報であるＡ＝１０００＊Ａを追加することにより、このロジックを修正すればよく、
ロジックが複雑であれば、例えば、ＳＱＬ修正によって依然として当該サービスロジックを修正することができない場合、計算ノードの静的ルーティングモジュールで対応するＳＱＬ構文をマスクすることができ、例えば、サービスが当該ＳＱＬ構文を実行するとき、そのままエラーを戻し、このようにｂｕｇの影響範囲も制限される。
【００９９】
本願に係るダークローンチ実現方法及び装置は、サービスコードを修正しない上で、アプリケーションのダークローンチがデータ構造及びサービスロジックを絶えず修正しなければならないという問題を解決し、全ての修正操作をデータベースにまとめて実行し、かつ分散データの再分散機能によってサービス部門がダークローンチデータをより迅速に構築することを容易にし、システムのリソース投入を節約し、サービスの試用反復の効率を向上させる。
【０１００】
以上は、本発明の好ましい実施例に過ぎず、本発明の保護範囲を限定するためのものではない。本発明の精神及び原則内に行われるいかなる修正、同等置換、改善などは、いずれも本発明の保護範囲に含まれるべきである。
【図１】
2021513694.tif 000006
【図２】
2021513694.tif 000007
【図３】
2021513694.tif 000008
【図４】
2021513694.tif 000009
【図５】
2021513694.tif 000010
【図６】
2021513694.tif 000011
【図７】
2021513694.tif 000012
【図８】
2021513694.tif 000013
【図９】
2021513694.tif 000014
【図１０】
2021513694.tif 000015
【図１１】
2021513694.tif 000016
【図１２】
2021513694.tif 000017
【図１３】
2021513694.tif 000018
【図１４】
2021513694.tif 000019
【手続補正書】
【提出日】令和2年6月30日(2020.6.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であることを決定することと、
予め設定されたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定することと、
試用要求が第１の試用要求であると決定された場合、第１の試用要求を試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、又は試用要求が第２の試用要求であると決定された場合、第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行することとを含む、ダークローンチ実現方法。
【請求項２】
予め設定された前記パーティション設定情報に基づいて、分散データベースのデータパーティショニング機能を利用して、データベース層において前記試用ユーザーのデータと前記正式ユーザーのデータを区別することをさらに含み、
同一のユーザーが同じパーティション設定情報を使用する、請求項１に記載の方法。
【請求項３】
前記予め設定されたパーティション設定情報に基づいて、試用要求を解析した後、前記実行を行う前に、
予め設定された試用修正設定情報に基づいて、前記第１の試用要求又は前記第２の試用要求における、試用ユーザーのデータを要求する部分を書き換えることをさらに含む、請求項１に記載の方法。
【請求項４】
前記試用ユーザーと前記正式ユーザーの使用するデータテーブル構造が異なりながら、使用する名称が同じであるように、前記試用修正設定情報に基づいて、試用ユーザーデータベースのテーブル構造を書き換えることをさらに含む、請求項３に記載の方法。
【請求項５】
前記受信されたアプリケーション要求が正式データを要求する正式要求であると決定すれば、
正式要求を、正式要求に対応する正式ユーザーが位置する正式データノードに転送して実行することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
予め設定されたＩＰホワイトリストにより、前記受信されたアプリケーション要求をフィルタリングすることにより、前記受信されたアプリケーション要求が試用データを要求する試用要求であるか又は正式データを要求する正式要求であるかを区別する、請求項１に記載の方法。
【請求項７】
前記ＩＰホワイトリストは、正式要求ＩＰホワイトリスト及び試用要求ＩＰホワイトリストを含み、
前記ＩＰホワイトリストにより、受信されたアプリケーション要求をフィルタリングすることは、
正式要求ＩＰホワイトリスト内の正式アプリケーションデータベースクライアントからのアプリケーション要求が正式要求であると決定することと、
試用要求ＩＰホワイトリスト内の試用アプリケーションデータベースクライアントからのアプリケーション要求が前記試用要求であると決定することと、
非ホワイトリストＩＰからのアプリケーション要求を破棄することとを含む、請求項６に記載の方法。
【請求項８】
予め設定されたパーティション設定情報に基づいて試用要求を解析することは、
前記試用要求に基づいてクエリが必要とするテーブルを決定することと、
前記パーティション設定情報に基づいて当該テーブルのパーティショニングルールをクエリし、かつパーティショニングルールに応じて当該試用要求に対応するデータノードを決定することとを含む、請求項１〜４のいずれか１項に記載の方法。
【請求項９】
前記第２の試用要求のデータの実行が完了した後、
前記試用ユーザーが位置する試用データノードへ送信した一部の実行結果と、前記正式ユーザーが位置する正式データノードへ送信した一部の実行結果とをまとめることをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１０】
データを再分散し、一部のホットスポットデータを追加パーティションに移動するか又は一部のホットスポットデータを負荷の大きいデータノードから負荷の小さいデータノードに遷移することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１１】
前記試用ユーザーのアプリケーション特性に応じて、対応する試用テーブルのテーブル構造を修正することをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１２】
試用アプリケーションが正式に発行されたと判断した場合、全ての正式データベースのデータ構造を、前記試用アプリケーションに対応する試用データベースのデータ構造に修正することと、
試用アプリケーションが適用されないと判断した場合、前記試用アプリケーションに対応する試用データベースのデータ構造を正式データベースのデータ構造にロールバックすることとをさらに含む、請求項１〜４のいずれか１項に記載の方法。
【請求項１３】
受信されたアプリケーション要求を処理し、受信されたアプリケーション要求が試用要求であると決定するように構成されるフィルタリングモジュールと、
ロードされたパーティション設定情報に基づいて試用要求を解析し、試用要求が試用データを要求する第１の試用要求であるか又は試用データ及び正式データを要求する第２の試用要求であるかを決定するように構成される解析モジュールと、
解析モジュールは試用要求が第１の試用要求であると決定された場合、第１の試用要求を試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行することと、又は解析モジュールは試用要求が第２の試用要求であると決定された場合、第２の試用要求における、試用ユーザーのデータを要求する部分を、試用要求に対応する試用ユーザーが位置する試用データノードに転送して実行し、第２の試用要求における、正式ユーザーのデータを要求する部分を、正式ユーザーが位置する正式データノードに転送して実行するように構成される転送モジュールとを含む、ダークローンチ実現装置。
【請求項１４】
２つ以上のデータノードを含み、ユーザーデータをキャリアするように構成される分散データベースにおけるデータノードクラスターと、
２つ以上の計算ノードを含み、サービスを外部に提供するように構成される分散データベースにおける計算ノードクラスターとを含み、データがパーティション設定情報によって複数のデータノードに分散され、前記計算ノードが請求項１３に記載のダークローンチ実現装置を含むダークローンチ実現システム。
【国際調査報告】
2021513694.tif 000020
2021513694.tif 000021
2021513694.tif 000022
2021513694.tif 000023