特許 7349506 Ｋ－最近傍探索のための分散型インメモリ空間データストア

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-09-13

(45)【発行日】2023-09-22

(54)【発明の名称】Ｋ－最近傍探索のための分散型インメモリ空間データストア

(51)【国際特許分類】

   G06F 16/909 20190101AFI20230914BHJP

【ＦＩ】

G06F16/909

【請求項の数】 15

(21)【出願番号】P 2021560062

(86)(22)【出願日】2019-04-12

(65)【公表番号】

(43)【公表日】2022-06-15

(86)【国際出願番号】 CN2019082349

(87)【国際公開番号】W WO2020206665

(87)【国際公開日】2020-10-15

【審査請求日】2021-10-27

(73)【特許権者】

【識別番号】518236797

【氏名又は名称】グラブタクシー ホールディングス プライベート リミテッド

【氏名又は名称原語表記】ＧＲＡＢＴＡＸＩ ＨＯＬＤＩＮＧＳ ＰＴＥ． ＬＴＤ．

【住所又は居所原語表記】３ Ｍｅｄｉａ Ｃｌｏｓｅ， ＃０１－０３／０６， Ｓｉｎｇａｐｏｒｅ １３８４９８， Ｓｉｎｇａｐｏｒｅ

(74)【代理人】

【識別番号】100137095

【弁理士】

【氏名又は名称】江部 武史

(74)【代理人】

【識別番号】100091627

【弁理士】

【氏名又は名称】朝比 一夫

(72)【発明者】

【氏名】ザン， ジイン

(72)【発明者】

【氏名】ファン， シャオチェン

(72)【発明者】

【氏名】サン， チャオタン

(72)【発明者】

【氏名】ゼン， シャオリン

【審査官】甲斐 哲雄

(56)【参考文献】

【文献】特開２００９－１９９１５１（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０１３９９１３（ＵＳ，Ａ１）

【文献】特開２０１９－０４０２９２（ＪＰ，Ａ）

【文献】特開２０１３－１７８６７７（ＪＰ，Ａ）

【文献】特開２００５－２７５６７８（ＪＰ，Ａ）

【文献】米国特許第６８７９９８０（ＵＳ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｇ０８Ｇ １／００－９９／００

(57)【特許請求の範囲】

【請求項1】

特定の位置に対して最近傍のオブジェクトを決定するために、複数の移動オブジェクトを探索するように構成されたデータベースシステムであって、
前記複数の移動オブジェクトのそれぞれは、位置データを含む属性を有し、複数のセルで構成される複数の空間的に異なるサブ空間で構成される地理的空間内に位置し、
前記データベースシステムは、
複数の保存ノードと、
オペレーティングシステムと、を含み、
前記オペレーティングシステムは、前記複数の保存ノード間のオブジェクトデータの保存を制御するように構成され、前記複数の保存ノードのそれぞれの１つにおいて、１つまたは複数の空間的に異なるサブ空間を代表するデータを保存させるように構成され、
前記オブジェクトの前記位置データは、各前記複数の保存ノード内の各前記空間的に異なるサブ空間を構成するセルに対して前記オブジェクトをインデックスするために使用され、
前記データは、前記複数の空間的に異なるサブ空間のそれぞれの読み込み及び／又は書き込みロードに基づいて、サブ空間から、どのサブ空間がどの保存ノードに属するかを明示的に定義する保存ノードへの設定可能なマッピングを使用して前記複数の保存ノードに保存されることを特徴とするデータベースシステム。

【請求項2】

前記空間的に異なるサブ空間の前記データは、単一の保存ノードに完全に保存されている請求項１に記載のデータベースシステム。

【請求項3】

前記オペレーティングシステムは、前記空間的に異なるサブ空間の前記データが、データレプリカを形成するために前記複数の保存ノードに複製されるように構成されている請求項１または２に記載のデータベースシステム。

【請求項4】

前記オペレーティングシステムは、前記空間的に異なるサブ空間に対する書き込み動作が、全ての関連する前記データレプリカに伝搬されるように構成されている請求項３に記載のデータベースシステム。

【請求項5】

前記データレプリカの数は、使用ケースに基づいて構成可能であることを請求項３または４に記載のデータベースシステム。

【請求項6】

前記オペレーティングシステムは、ｋ－最近傍クエリに応答するために、幅優先探索アルゴリズムを動作させるように構成されている請求項１ないし５のいずれかに記載のデータベースシステム。

【請求項7】

前記データは、コンシステントハッシュ法によって、前記複数の保存ノードに保存される請求項１に記載のデータベースシステム。

【請求項8】

ロードバランシングのために、前記オペレーティングシステムは、サブ空間から、どのサブ空間がどのノードに属するかを明示的に定義する保存ノードへのユーザ設定可能なマッピングと、コンシステントハッシュ法との両方を使用するように構成される請求項１に記載のデータベースシステム。

【請求項9】

コンシステントハッシュ法は、前記マッピングに含まれないデータのために使用される請求項８に記載のデータベースシステム。

【請求項10】

前記マッピングにおける１つのノードは、新たなジョインをブロードキャストするための静的コーディネータとして使用される請求項１に記載のデータベースシステム。

【請求項11】

前記オペレーティングシステムは、ノード発見のためにゴシップスタイルのメッセージングを適用する請求項１に記載のデータベースシステム。

【請求項12】

前記データベースシステムは、配車アプリケーション用であり、
前記オブジェクトは、サービスプロバイダの車両である請求項１ないし１１のいずれかに記載のデータベースシステム。

【請求項13】

前記データベースシステムは、インメモリに保存される請求項１ないし１２のいずれかに記載のデータベースシステム。

【請求項14】

複数のセルで構成される複数の空間的に異なるサブ空間で構成される地理的空間内の特定の位置に対して、高速で最近傍探索することができるために、複数の移動オブジェクトを表すデータを保存する方法であって、
前記複数の移動オブジェクトのそれぞれは、位置データを含む属性を有し、
データベースシステムは、複数の保存ノードを含み、
前記方法は、プロセッサを含む装置によって実行され、
１つまたは複数の空間的に異なるサブ空間を代表するデータが各単一の保存ノードに保存されるように、前記複数の保存ノードの間でオブジェクトデータを保存する工程と、
各前記複数の保存ノード内の各前記空間的に異なるサブ空間を構成するセルに対して前記複数の移動オブジェクトをインデックスするために、各前記複数の移動オブジェクトの現在の位置データを使用する工程と、
どのサブ空間がどの保存ノードに属するかを明示的に定義する保存ノードに前記サブ空間をマッピングするために、前記複数の空間的に異なるサブ空間のそれぞれの読み込み及び／又は書き込みロードを使用する工程と、を含むことを特徴とする方法。

【請求項15】

請求項１ないし１２のいずれかに記載されたデータベースシステムを含む、ｋＮＮ探索用の拡張可能なインメモリ空間データストア。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、データ保存および検索に関する。より詳細に、もっぱら、本発明は、Ｋ－最近傍探索を容易にするためのデータベースシステムに関する。例示的な実施形態は、配車（ride hailing）サービスを管理する分野にある。

【背景技術】

【0002】

典型的な配車シナリオでは、潜在的なユーザは、スマートフォンアプリを介して予約リクエストを発行する。そして、これは、要求されたサービスを提供するために利用可能な最も適した近くのサービスプロバイダを派遣することによって、ホストによって実行される。

【0003】

最も近い移動オブジェクト（例えば、ドライバ）をリアルタイムで検索することは、配車サービスが対処する必要がある基本的な問題の１つである。ホストは、サービスプロバイダのリアルタイムの地理的位置を追跡し、各予約リクエストに対しユーザの位置の近くのｋ個の利用可能なサービスプロバイダを探索する。なぜなら、最も近いサービスプロバイダが常に最良の選択ではないからである。問題を簡単にするために、経路距離よりむしろ、直線距離を使用する。

【0004】

静的オブジェクトについてのｋ－近傍法（ｋＮＮ）クエリ（例えば、ｋ個の最も近いレストランを検索すること）、または、移動オブジェクトについての連続的なｋ－近傍法クエリ（例えば、移動している車に対してｋ個の最も近いガソリンスタンドを見つけること)の既存の研究と異なり、問題は、動的ｋ－近傍クエリを実行する移動しているオブジェクトを伴う。これは、チャレンジである。

【0005】

[先行技術文献]
最も近いレストランの検索のような静的オブジェクトのｋ－最近傍探索は、オブジェクトのインデクシングに適切にフォーカスする。２つの主要なインデクシングアプローチ、すなわち、オブジェクトベースのアプローチおよびソリューションベースのアプローチがある。

【0006】

オブジェクトベースのインデクシングは、オブジェクトの位置をターゲットとする。Ｒ－ツリーは、最小外接矩形を使用して、ｋ－最近傍法が空間結合によって計算される階層インデックスを構築する。ソリューションベースのアプローチは、予め計算されたソリューション空間をインデクシングすること（例えば、ボロノイ図に基づいてソリューション空間を分割すること）にフォーカスし、ボロノイセルに対応する最近傍探索の結果を予め計算する。他のアプローチは、前記２つのアプローチを組み合わせ、ボロノイセル内にある任意のクエリの最近傍のオブジェクトを保存するグリッドパーティションインデックスを提案する。

【0007】

インデックスに基づいて静的オブジェクトのｋＮＮクエリを速めるために、k個の近傍オブジェクトの優先リストを維持しながら、最良の最初の探索を行うためのＲ－ツリーに基づいて、分岐および結合アルゴリズムを開発することが提案されている。

【0008】

別のアプローチでは、静的オブジェクトについて移動するｋＮＮクエリを研究する。それは、新しい位置でのk－近傍クエリが前の結果に含まれるように、ｋ個の結果アイテム以上を戻す。

【発明の概要】

【発明が解決しようとする課題】

【0009】

しかしながら、移動オブジェクトのこのような複雑なインデックスを維持することは、頻繁な位置更新が問題となる。

【0010】

インデクシング移動／モバイルオブジェクトは、次の２つのカテゴリに分類される。それらは、（１）移動オブジェクトの現在および予想される将来の位置のインデクシング、および（２）複数経路（trajectory）のインデクシングである。

【0011】

一つの以前の研究は、移動するオブジェクトの現在および予想される将来の位置のインデクシングにフォーカスし、時間パラメータ化されたＲ－ツリー（すなわち、ＴＰＲ－ツリー）インデックスを提案する。ＴＰＲ－ツリー内の外接矩形は、時間の関数であり、それらが移動するとき、囲まれたデータ点または他の矩形に連続的に従う。

【0012】

インデクシング複数経路アプローチは、複数経路履歴を保存し、Ｒ－ツリーの典型的範囲の探索を可能にする複数経路のバンドルツリー(ＴＢ－ツリー)を提案する。我々の設定では、オブジェクトの過去の複数経路は関心がないことに留意されたい。

【0013】

静的オブジェクトについての連続的なｋ－最近傍探索は、例えば、予め指定された経路に沿った任意の点上の移動車両の３つの最も近いガソリンスタンドを見つけることに注目されている。

【0014】

オブジェクトがインデクシングされる従来のアプローチとは対照的に、別のアプローチは、クエリ(すなわち、Ｑ－インデックス)およびオブジェクト(すなわち、速度制約インデックス(ＶＣＩ))の両方にインデックスを構築する。さらに別のアプローチは、オブジェクトが現在の速度で常に移動し、したがって将来のタイムスタンプでｋ個の最近傍オブジェクトを推論することができると仮定する。全てをモニタリングする連続的なクエリの多くの作業は、インデクシングのクエリに注意を払う。しかしながら、これらの方法は、クエリがどのように移動するか（例えば、複数経路に沿って）についての仮定を行うか、またはインメモリグローバルインデックスを仮定するかのいずれかである。

【0015】

高容量の書込み動作の存在下で前述の複雑なインデックス技術を拡張することは、自明ではないことに注意すべきである。読み出し動作と書き込み動作の両方を容易に拡張する単純なインデックス構造は、実際のアプリケーションによく適している。

【0016】

移動するオブジェクトのデータベースは、非常に困難である。一つのアプローチは、移動オブジェクトの位置を追跡し、更新するデータベースを考慮する。しかし、焦点は、データベース内の移動オブジェクトの位置が更新されるべきである時を決定することである。空間データベースは、空間データを管理し、クエリ点が多角形エリアに含まれているかどうかのような、ＧＩＳ(地理情報システム)クエリをサポートする。

【0017】

技術上の問題は、膨大なＩ／Ｏコストのため、データベースが重たい書き込み負荷を扱うのに適していないということである。

【0018】

拡張可能なインメモリキー値データストア（stores）は、頻繁な書き込みの下でよく拡張する。キー値データストアでは、オブジェクトはキーであり、それらの位置は値である。従って、ｋ－最近傍探索に応答するには、全てのキーをスキャンする必要がある。その待ち時間（レイテンシー）は許容できない。

【課題を解決するための手段】

【0019】

第１の態様では、データ保存が分散されているｋＮＮ探索用に調整された拡張可能なインメモリ空間データストアが開示される。

【0020】

第２の態様では、近傍移動オブジェクト(ドライバ)をリアルタイムで検索するためのシステムおよび方法が開示される。

【0021】

第３の態様では、複数の空間的に異なる空間シャードで構成された地理空間内に位置する最近傍な移動オブジェクトを高速に探索することができるように構成されたデータベースシステムが開示される。複数の空間的に異なる空間シャードは、複数のセルから構成され、複数の保存ノードの間で保存オブジェクトデータを制御するように構成されている。データは、各ノード内の各空間的に異なるシャードを構成するセルに対してそのオブジェクトをインデックスするために使用される各移動オブジェクトの位置データとともに、分散的な状態で保存される。

【0022】

第４の態様では、データベースシステムが開示される。データベースシステムは、複数の空間的に異なるサブ空間から構成される地理的空間内に位置する最近傍のオブジェクトを高速に探索することができるように構成されている。複数の空間的に異なるサブ空間は、複数のセルから構成される。そのデータベースシステムは、複数の保存ノードと、オペレーティングシステムとを含む。オペレーティングシステムは、複数のノード間のオブジェクトデータの保存を制御するように構成される。オペレーティングシステムは、１つまたは複数の空間的に異なるサブ空間を代表するデータを、保存ノードのそれぞれの１つに保存させるように構成されている。そして、各オブジェクトの位置データは、各ノード内の各空間的に異なるサブ空間を構成するセルに対してそのオブジェクトをインデックスするために使用される。

【0023】

別の態様では、複数の空間的に異なるサブ空間で構成される地理的空間内に位置する最近傍のオブジェクトを高速に探索することができるデータを保存する方法が開示される。複数の空間的に異なるサブ空間は、複数のセルで構成されている。データベースシステムは、複数の保存ノードを含む。この方法は、複数の保存ノードの間にオブジェクトデータを保存する工程を含む。その結果、１つまたは複数の空間的に異なるサブ空間を代表するデータは、保存ノードのそれぞれの１つに保存される。その方法はまた、各保存ノード内の各空間的に異なるサブ空間を構成するセルに対してそのオブジェクトをインデックスするために、各オブジェクトの位置データを使用する工程を含む。

【0024】

さらに別の態様では、データ間の地理的関係に従って、複数の保存ノードにデータを分配する工程を含む最近傍探索を加速する方法が開示される。それによって、データの探索は、減少された数のリモートコールを使用して実行される。

【0025】

別の態様では、第４の態様で請求されるデータベースシステムを含むｋＮＮ探索用の拡張可能なインメモリ空間データストアが開示される。

【0026】

一実施形態では、空間的に異なるサブ空間のデータは、単一の保存ノードに完全に保存される。

【0027】

実施形態では、空間的に異なるサブ空間のデータは、複数の保存ノードに複製されて、データレプリカを形成する。

【0028】

実施形態では、空間的に異なるサブ空間に関する書き込み動作は、関連する全てのデータレプリカに伝搬される。クォーラムベースのヴォーティングプロトコルが使用される。

【0029】

いくつかの実施形態では、レプリカの数は、使用事例に基づいて構成可能である。

【0030】

いくつかの実施形態では、幅優先探索アルゴリズムは、ｋ－最近傍クエリに応答する。

【0031】

一群の実施形態では、データは、コンシステントハッシュ法を使用して複数の保存ノードに保存される。それによって、抽象的なハッシュサークルに割り当てている。

【0032】

別の群の実施形態では、データは、サブ空間から保存ノード（これはどのサブ空間がどの保存ノードに属するかを明示的に定義する）へのユーザ設定可能なマッピングを使用して、複数の保存ノードに保存される。

【0033】

さらに別の群では、サブ空間から保存ノード（これはどのサブ空間がどのノードに属するかを明示的に定義する）へのユーザ設定可能なマッピングおよびコンシステントハッシュ法の両方が、異なるデータに対して使用される。

【0034】

データベース内のデータは、一組の実施形態では、インメモリに保存される。

【0035】

マッピングに含まれないデータについては、コンシステントハッシュ法が用いられる。

【0036】

マッピング内の１つのノードは、新しいジョイン（joins）をブロードキャスト（broadcast）するための静的コーディネータとして使用される。

【0037】

ゴシップスタイルのメッセージは、ノード発見を可能にするために使用される。

【0038】

オブジェクトは、移動してもよいし、少なくとも移動可能であってもよく、配車システムのサービスプロバイダの車両であってもよい。

【発明の効果】

【0039】

このようなデータベースシステムは、データを異なるノードに分配し、インメモリに保存することによって、書き込み動作の容量の問題に対処するように構成されている。

【0040】

別の態様では、データ間の地理的関係に従って、オペレーティングシステムが複数の保存ノードにデータを配信するデータベースシステムが提供される。それによって、減少した数のリモートコールを用いて、データの探索を実行することができる。

【図面の簡単な説明】

【0041】

【図1】図１は、配車サービスの使用のための例示的な通信システムの部分ブロック図を示す。

【図2】図２は、最近傍探索技術のフローチャートを示す。

【図3】図３は、ｋ－最近傍探索のためのＢＦＳの図である。

【図4】図４は、ナイーブｋ－最近傍探索アルゴリズムを示す。

【図5】図５は、最適化されたｋ－最近傍探索アルゴリズムを示す。

【図6】図６は、アクセスしたシャード内のアクセスしたセルの平均数を示す。

【図7】図７は、ハッシュ対シャードテーブルマッピングの比較を示す。

【図8】図８は、障害回復の結果を示す。

【図9】図９は、異なる地理的空間インデックスの計算を比較する表である。

【図10】図１０は、分散データベースのアーキテクチャの高度に簡略化されたブロック図を示す。

【発明を実施するための形態】

【0042】

本明細書で使用されているように、データベースは、オペレーティング管理システムを有する構造である。その構造は、メモリを含む。そして、オペレーティング管理システムは、メモリに保存されたデータの探索を容易にするために、データをメモリに保存するように構成されている。

【0043】

データベースが、オブジェクトを表す複数の論理行と、オブジェクトの属性を表す複数の論理列とを有するものとみなすことができる場合、「タプル（tuple）」は、特定のオブジェクトの属性のセットを表す単一の行である。

【0044】

「ハッシュ化」は、元の文字列（string）を表す「キー」と呼ばれるデータアイテムに文字列を変換することである。ハッシュ化は、データベース内のアイテムをインデックスし、検索するために使用される。なぜなら、元の値を使用してアイテムを見つけるよりも、ハッシュ化された短いキーを使用してアイテムを見つけることがより速いからである。

【0045】

「コンシステントハッシュ法」は、分散ハッシュスキームである。このスキームは、ノードやオブジェクトを抽象的なサークルまたはハッシュリング上の位置に割り当てることによって、分散ハッシュテーブル内のノードまたはオブジェクトの数とは独立して動作する。これにより、システム全体に影響を与えることなく、ノードおよびオブジェクトを追加または除去することができる。

【0046】

「シャーディング」は、データベースを独自のデータセットに分割し、データを複数のサーバに分配することができ、それによってデータの検索を高速化する。典型的には、データベースの水平パーティションがある。本発明の文脈において、固有のデータセットは、それぞれ、地理的に異なるエリアを表し、そのようなエリアの各々は、シャード(shard)と呼ばれる。

【0047】

用語「シャード」は、ここでは、各エリアのデータ内容を定義するために使用される。その結果、データのシャードｘを参照することは、地理的シャードｘのデータセットを参照する。ｋ－最近傍探索（ｋＮＮ探索）は、考慮中のオブジェクトに対して、ｋ個の最近傍を識別する探索である。

【0048】

「レディス（redis）」(Remote Dictionary Server)は、非常に高い読み込み－取り書込み能力を有するデータベースとして使用可能なデータ構造サーバのタイプである。

【0049】

メインメモリデータベースシステムまたはＭＭＤＢとも呼ばれる「インメモリデータベース」（ＩＭＢＤ）は、コンピュータデータ保存のためのメインメモリに主に依存するデータベース管理システムである。インメモリのデータにアクセスすることは、データを照会する際のシーク時間を低減または除去する。

【0050】

「レプリカセット」という用語は、同じデータの別々に保存されたインスタンスを示す。

【0051】

まず、図１を参照すると、配車アプリケーションのための通信システム１００が示されている。通信システム１００は、通信サーバ装置１０２と、サービスプロバイダ通信デバイス１０４（ここでは、サービスプロバイダデバイスとも呼ばれる）と、クライアント通信デバイス１０６とを含む。これらのデバイスは、例えば、インターネット通信プロトコルを実施する各通信リンク１１０、１１２、１１４を介して通信ネットワーク１０８（例えば、インターネット）に接続される。通信デバイス１０４、１０６は、移動セルラー通信ネットワークを含む他の通信ネットワーク（例えば、公衆交換電話ネットワーク(ＰＳＴＮネットワーク))を介して通信することができる。しかし、これらは、明瞭化のために図１から省略されている。

【0052】

通信サーバ装置１０２は、図１に概略的に示されるような単一のサーバであってもよく、複数のサーバコンポーネントにわたって分散されたサーバ装置１０２によって実行される機能を有する。図１の例では、通信サーバ装置１０２は、多数の個別のコンポーネントを含む。この多数の個別のコンポーネントは、特に限定されないが、１または複数のプロセッサ１１６と、実行可能命令１２０のロードのためのメモリ１１８（例えば、ＲＡＭのような揮発性メモリ)とを含む。実行可能命令は、サーバ装置１０２がプロセッサ１１６の制御下で実行する機能を定義する。通信サーバ装置１０２はまた、サーバが通信ネットワーク１０８を介して通信することができる入出力モジュール１２２を含む。ユーザインタフェース１２４は、ユーザ制御のために提供され、例えば、表示モニタ、コンピュータキーボード等のような従来のコンピュータ周辺デバイスを含む。サーバ装置１０２はまた、データベース１２６を含む。その１つの目的は、処理される際にデータを保存することであり、将来の履歴データとして利用可能なデータを作成することである。

【0053】

サービスプロバイダデバイス１０４は、複数の個別のコンポーネントを含む。この多数の個別のコンポーネントは、特に限定されないが、１または複数のマイクロプロセッサ１２８と、実行可能命令１３２のロードのためのメモリ１３０(例えば、ＲＡＭのような揮発性メモリ)とを含む。実行可能命令は、サービスプロバイダデバイス１０４がプロセッサ１２８の制御下で実行する機能を定義する。サービスプロバイダデバイス１０４はまた、サービスプロバイダデバイス１０４が通信ネットワーク１０８上で通信することができる入出力モジュール１３４を含む。ユーザインタフェース１３６は、ユーザ制御のために提供される。サービスプロバイダデバイス１０４が、例えばスマートフォンまたはタブレットデバイスである場合、ユーザインタフェース１３６は、多くのスマートフォンおよび他の携帯端末において普及しているようなタッチパネルディスプレイを有する。あるいは、サービスプロバイダ通信デバイスが、例えば、従来のデスクトップまたはラップトップコンピュータである場合、ユーザインタフェースは、例えば、表示モニタ、コンピュータキーボード等のような従来のコンピュータ周辺デバイスを有する。

【0054】

クライアント通信デバイス１０６は、例えば、サービスプロバイダデバイス１０４と同じまたは類似のハードウェアアーキテクチャを有するスマートフォンまたはタブレットデバイスである。

【0055】

実施形態では、使用において、サービスプロバイダデバイス１０４は、例えば、ＡＰＩコールをデータベースに直接送信することによって、データのパケットを通信サーバ装置１０２にプッシュするようにプログラムされる。パケットは、例えば、サービスプロバイダデバイス１０４のＩＤ、デバイスの位置、タイムスタンプ、および他の態様（例えば、サービスプロバイダがビジーまたはアイドルである場合）を示す他のデータを表す情報を含む。

【0056】

いくつかの実施形態では、プッシュされたデータは、サーバのクロックに同期してサーバ１０４によってアクセスされることを可能にするためにキューに保持される。他の実施形態では、プッシュされたデータは、直ちにアクセスされる。

【0057】

さらに他の実施形態では、サービスプロバイダデバイス１０４は、サーバにデータをプッシュするよりむしろ、サーバ１０２からの情報リクエストに応答する。

【0058】

さらに他の実施形態では、データは、サービスプロバイダデバイスによって放出されたデータのストリームから情報を引くことによって得られる。

【0059】

データがサービスプロバイダデバイスからプッシュされる実施形態では、実施形態のデータベースへの転送は、Ｋａｆｋａストリームを用いて実行される。このような手段が使用されず、少数の同時データがプッシュされる場合、データベースは、それらを同時に処理するように構成される。多数のプッシュが発生する場合、受信データは、ＦＩＦＯメモリとして実現されるメッセージキューに保持される。

【0060】

サービスプロバイダデバイス１０４からのパケット化されたデータは、多くの方法でサーバによって使用される。その方法は、例えば、サービスプロバイダへのクライアントリクエストをマッチングするための方法、配車システムを管理するための方法（例えば、仕事が利用可能であるまたは利用可能となりそうなサービスプロバイダをアドバイスする方法）、履歴データベース１２６として保存するための方法などである。

【0061】

パケット化されたデータのいくつかは、ｋＮＮ探索を実行するためのデータベースによって保存のためにデータタプルに変換される。

【0062】

一実施形態では、データタプルは、ＩＤによって一意に識別されたオブジェクトがタイムスタンプｔｓの位置ｌｏｃにあることを表す４つの属性（ｉｄ、ｌｏｃ、ｔｓ、メタデータ）からなる。メタデータは、オブジェクトの状態を特定する。例えば、サービスプロバイダのメタデータは、サービスプロバイダが配車のための自動車ドライバであるか、または食品配送のための自動二輪車サービスプロバイダであるかどうかを示す。ｋ－最近傍探索クエリは、ｌｏｃが位置座標であり、ｔｓがタイムスタンプである(ｌｏｃ、ｔｓ、ｋ)として表される。ｋ－最近傍探索クエリ(ｌｏｃ、ｔｓ、ｋ)が与えられると、実施形態のデータベースは、クエリ位置ｌｏｃに最も近いｋ個のデータタプルに戻る。なお、本実施形態では、直線距離を想定している。

【0063】

一群の実施形態では、クエリタイムスタンプｔｓもまた検索されて、データタプルのタイムスタンプを有効化する。なぜなら、焦点（focus）が短時間内にリアルタイム位置にあるからである。

【0064】

本実施形態のデータベースは、データが保存のために異なるノードを横切って拡散される分散データストアを含む。１つまたは複数の地理的シャード内に位置されたサービスプロバイダのデータタプルは、それぞれのノードに保存される。現在の実施例では、データはノード間で複製されず、単一のインスタンスのみが書き込まれる。可能な限り、本実施形態は、空間的に近いサービスプロバイダを表すデータタプルを一緒に書き込み、迅速なｋＮＮ探索を可能にする。しかしながら、関心のある第１のサービスプロバイダが、１つのノードに保存されたシャードの境界にあるか、または、それに近い場合、第１のサービスプロバイダに近いが、実際には、他のノードにデータが保存されている隣接するシャード内に位置するサービスプロバイダであってもよいことに留意されたい。

【0065】

データを保存する場所を決定することは、それらの地理的位置に従って、データタプルをシャードにまず分割することによって達成される。そして、シャーディングアルゴリズムは、どのノードがデータシャードにあるかを決定する。

【0066】

上述したように、データタプルは、それらの地理的位置に従ってシャードに分割される。本実施形態では、これは、２次元ＷＳＧ（世界測地システム）平面をグリッドセル（本明細書ではシャードまたは地理的シャードと呼ぶ）に分割することによって達成される。

【0067】

緯度及び経度の値は、それぞれ、－９０～＋９０、－１８０～＋１８０の範囲である。問題を簡単にするために、グリッドサイズは、ｌ×ｌと定義される。従って、合計

のグリッドセルがある。簡単なインデックス関数ｉｎｄｅｘ(ｌａｔ；ｌｏｎ)を使用して、任意の所与の位置(ｌａｔ；ｌｏｎ)のグリッドｉｄ(すなわち、シャードｉｄ)を計算する。

ここで、(－１８０、－９０)は原点であり、シャードは原点の右上の

セルおよび原点の上の

である。

【0068】

ｋ－最近傍探索を速めるために、本実施形態は、２つのレベルのインデックス階層を維持する。グリッドサイズｌを減少させることにより、地理的シャードは、より小さいセル（以下、セルという）にさらに分割される。問題を簡単にするために、一実施形態では、セルサイズは、各セルが正確に１つのシャードに属するように選択される。各地理的シャードは、１組のセルを含む。シャードの物理的サイズは異なっていてもよく、赤道付近のシャードは極近くのものよりも物理的に大きい。しかしながら、近くのシャードは、同様の物理的サイズ、特に、関心のある焦点が小さな半径（＜１０ｋｍ）内のオブジェクトにある場合を有するものと仮定する。一実施形態では、地理的シャードは、赤道で約２０ｋｍ×２０ｋｍ四方で表す。一方、セルは、約５００メートル×５００メートルのエリアを表す。

【0069】

地理的シャードは、最小の共有単位である。上述したように、同じ地理的シャードに属するデータは、同じノードのメモリに保存される。本実施形態は、シャーディング機能、すなわち、ノード＿ｉｄ＝シャーディング（インデックス（ｌａｔ；ｌｏｎ））に基づいて１または複数の地理的シャードをノードに分配する。

【0070】

シャーディングアルゴリズムの詳細は、本明細書では後述される。同様に、シャーディングアルゴリズムは、セルが保存されているノードｉｄにセルをマッピングする。
ノード＿ｉｄ＝シャーディング（セル＿ｉｄ）

【0071】

それぞれのシャード内のサービスプロバイダにデータを保存する複数のノードを有するデータベースが与えられると、タスクは、特定の場所、例えば、クライアントが提供されるべきサービスを必要とする場所（例えば、ピックアップ位置）にｋ個の最近傍を見つけることである。

【0072】

ナイーブｋ－最近傍探索。図４（アルゴリズム１）に戻って、位置が与えられると、実施形態は、幅優先探索（ＢＦＳ）を用いてk個の最近傍オブジェクトを検索する。

【0073】

クエリ位置が属するセルを開始するために、（ライン１）、すなわち、図３の中央ドット３２０が特定される。探索アルゴリズムは、隣接するセル（ライン１１）の幅優先探索を実行する。図３の番号は、反復回数を示す。セルにアクセスする（visiting）とき、セル内のｋ個の最近傍オブジェクトは、アルゴリズム、すなわち、関数ＫＮｅａｒｅｓｔ＿ＩｎＣｅｌｌ（ライン９）によって抽出される。サイズｋのグローバルオブジェクト優先キュー（アルゴリズムの結果）は、オブジェクトと、所与の探索位置との間の距離に基づいて維持される。ライン１０は、セル内のｋ個の最近傍オブジェクトを比較して、最終結果にマージする。

【0074】

反復ｉ＋１（例えば、図３のドット３２３）に見られるオブジェクトは、前の反復ｉ（例えば、ドット３２５）に見られるオブジェクトよりも近いことに留意されたい。

【0075】

クエリ位置が存在するクエリセルが与えられると、反復ｉにおいて見られるセル内の任意の位置と、セル内の任意の位置との間の距離は、（ｉ－１）ｘｌから√２×（ｉ＋１）×ｌの範囲にある。ここで、ｌは、セルの長さである。

【0076】

この実施形態では、一般性を失うことなく、ハーバーサイン（haversine）距離よりむしろユークリッド距離が使用される。従って、ＢＦＳは、結果のｋ個の最近傍オブジェクトが反復ｍｉｎ＿ｉｔｅｒ内に見出される時かつその時に限り、反復ｉの終了時に終了する。（ライン１３）

ｍｉｎ＿ｉｔｅｒは、マージ機能によって維持される（ライン１０）。

【0077】

ナイーブｋ－最近傍探索の問題は、シャーディング（セル）がローカルでない場合に、ＫＮｅａｒｅｓｔ＿ＩｎＣｅｌｌ（ライン９）がリモートコールであるということである。最悪の場合、Ｏ（ｎ）のリモートコールがある（ｎはアクセスされたセルの数である）。なお、同一のシャードに属するセルが同一ノードに保存されていることに注意されたい。これは、同一ノードに対する複数コールにつながる。

【0078】

次に、この問題を解決するために最適化されたｋ－最近傍探索アルゴリズム（図５、アルゴリズム２）を説明する。

【0079】

シャード内のセルが一緒に保存されることを想起されたい。ここで、リモートＫＮｅａｒｅｓｔ＿ＩｎＣｅｌｌ（Ｋ、ｌｏｃ、セル）コールがリモートコールの数をＯ（ｍ）に低減するように同じシャード内にある場合、アルゴリズムは、そのリモートＫＮｅａｒｅｓｔ＿ＩｎＣｅｌｌ（Ｋ、ｌｏｃ、セル）コールを一緒に集める。ここで、ｍは、アクセスされたシャードの数である。実際、サービスは、半径ｒ（ｒ＜＜シャードサイズ）内の最も近いオブジェクトとのみ関係している。したがって、アクセスされたシャードの数は、ほとんど一定である。こうして、リモートコールの数は、Ｏ（１）に低減される。実際、所与の半径ｒが与えられると、アルゴリズム１で必要とされる反復の総数は、ループを早期に出るように予め計算される。さらに、セルにアクセスする前に、セルがサークル半径ｒと交差するかどうかが検証される。

【0080】

アルゴリズム２は、最適化されたｋ－最近傍探索を提示する。アルゴリズムは、最初に、近くの交差するシャードを識別する（ライン１）。その詳細は省略される。次に、ナイーブ＿ＢＦＳ（Ｋ、ｌｏｃ）は、各シャードが保存されているノードで局所的に実行される（ライン３）。次いで、アルゴリズムは、全てのシャードからの結果をマージする（ライン４）。シャードは互いに独立しているので、リモートコールは並行に送られる。セルもまたナイーブ＿ＢＦＳ（Ｋ、ｌｏｃ）内で独立している。そのため、ＫＮｅａｒｅｓｔ＿ＩｎＣｅｌｌ（Ｋ、ｌｏｃ、セル)も並行して実行される。

【0081】

オブジェクトが移動すると、実施形態はオブジェクトの位置を更新する。高速更新のために、インメモリの全てのデータタプルを保存する。インデックス（ｌｏｃ）は、その新しい位置がどのセルに属するかを一意に識別することを想起されたい。オブジェクトがセル内に既に存在する場合、その位置は単に更新される。そうでなければ、新しいデータタプルは、セルに挿入される。本実施形態は、タプルの古い位置を直ちにディアクティベートしない。データタプルは、ＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ）を有する。シャードからの読出しまたはシャードへの書込時に、ＴＴＬが満了したシャード内のタプルは、ディアクティベートされる。このようにして、ｋ－最近傍クエリがサービスプロバイダの最新の位置に戻らないことが起こり得る。それにもかかわらず、タプルの適時性は、タイムスタンプによって保存される。この実施形態は、ｋ最近傍クエリの定義を緩めて、ｋデータタプルまで戻す。ｋデータタプルは、期間内のクエリ位置に最も近い。これは、実際のアプリケーションにおいて十分である。

【0082】

本実施形態は、さらに、無駄なデータシャードを定期的にリリース（release）する。多くのドライバがアクティブである日中に作成されたデータシャードは、ドライバが仕事を終えた時の夜間にリリースされる。

【0083】

正式には、データシャードは、シャード内の全てのドライバの位置が古くなった（例えば、１０分前）場合に、メモリからリリースされる。実際には、データシャードは、１５分毎にクリーンアップされる。

【0084】

地理的空間インデックスは、以下の条件が満たされる場合、分割の目的に役立つと仮定することができる。
・地球を小さなチャンクに分割する
・一意に、地理的座標をチャンク（ａ．ｋ．ａ．ａシャード）にマッピングする
・隣接するチャンクを効率的に検索する

【0085】

最近開発された、地理的空間インデックス（例えば、グーグルによるＳ２）、ウーバーによるＨ３は、実際、クエリフェーズを速める可能性を有する。例えば、Ｈ３のヘキサゴンは、探索空間を減少させる正方形よりも少ない近傍を有する。しかし、本実施形態の単純なインデックスは、はるかに速く計算することができる（図９）。高速インデックス計算は、書込みおよび読出し動作の両方を速める。それにもかかわらず、本実施形態はモジュール式であり、前述のインデックスは必要に応じてシステムにプラグインされる。

【0086】

低レイテンシー、高信頼性および利用可能性を達成するために、本実施形態が分散された設定においてノードをどのように管理するかについての説明を以下に示す。第１の提案は、ロードバランスを達成するために、データシャードをノードに分配するためのコンシステントハッシュ法に対する補間としてのシャードテーブルである。既知のゴシッププロトコルＳＷＩＭは、ノードの発見と、障害検出のために使用される。最後に、実施形態がどのように地域の障害から迅速に回復するかということが示されている。

【0087】

シャーディングアルゴリズム
このセクションは、実施形態がデータシャードを異なるノードにどのように分配するかを記載する。

【0088】

コンシステントハッシュ法は、等しい数のデータシャードを異なるノードに分配するために広く使用されている。これは、新しいノードが追加されるとき、最小量のデータを移動する必要があるという利点がある。しかしながら、このアプローチは、アンバランスなシャードサイズおよびクエリの必要性のために、実際には大きな性能上の問題を生じる。あるシャードは、他のものよりもはるかに多くのオブジェクトを含んでいる。例えば、より大きな都市（例えば、シンガポール）のシャードは、より小さい都市（例えば、バリ）よりも５倍多いドライバを有する。第二に、高需要エリア（例えば、ダウンタウンエリア）におけるシャードは、地方のエリアよりもはるかに多く問合せされる。シャードをノードに均等に分配する場合、あるノードは８０％を超えるＣＰＵ使用量を有するホットスポットとなり、他のいくつかのノードはアイドル状態であることが観察される。

【0089】

さらに、コンシステントハッシュ法の下で新しいコンピュータ（machines）を追加すると、特に悪いことがある。例えば、アマゾンウェブサービス（ＡＷＳ）では、スケールアウトは、典型的に、ノードの高いＣＰＵ使用量（すなわち、ホットスポット）によってトリガされる。新しいノードが追加されると、コンシステントハッシュ法は、１つまたは数個のノードをランダムに選択し、それらのデータシャード（従って、クエリ負荷）を新しいノードに使わない（spare）。残念ながら、ホットスポットノードは、選択されることが保証されない。これは、ホットスポットが全く緩和されないが、新しいアイドルノードの追加につながる。

【0090】

従って、本実施形態は、シャードテーブルを使用することによって、データ移動時間と、高速クエリ時間との間で交換する。シャードテーブルは、シャードからノードへのユーザ設定可能なマッピングである。そのノードは、どのシャードがどのノードに属するかを明示的に定義する。一実施形態では、ノードは、都市内の高需要のエリアに専用である。場合によっては、ノードは、多数の小都市に役に立つ。シャードテーブルにないシャードに対して、フォールバックは、コンシステントハッシュ法を使用することである。

【0091】

シャードテーブルは、半自動である。ホットスポットノードが観察されると、本実施形態は、シャード上の読み込み／書き込みロードに基づいて移動する必要のあるシャードを計算する。次に、管理者は、既存のアイドルノードまたは新しいノードにシャードを移動する。

【0092】

半自動構造は、本出願人に対して良好に働く。シャードテーブルが第１の場所で適切に構成される場合、人間の介入は、ほとんど必要とされない。

【0093】

ノード発見および障害回復
本実施形態は、ノード発見のためにゴシップスタイルのメッセージを適用する。各ノードは、ネットワークトポロジー上でその知識を中心にゴシップする。特に、Ｓｅｒｆは、ライフガード強化を用いてＳＷＩＭを実施するから選択される。ＳＷＩＭに関する一つの問題は、新しいノードが結合すると、静的コーディネータが多数のメンバー応答を回避するためにジョインリクエストを処理するために必要とされるということである。

【0094】

実施形態は、新しいジョインをブロードキャストする静的コーディネータのように、シャードテーブル内の１つのノードを微妙に再使用する。ＳＷＩＭは、時間有界の完全性を提供する、すなわち、任意のメンバーの障害の最悪の場合の検出時間を制限することに価値がある。これを達成するために、ＳＷＩＭは、ラウンドロビンプローブターゲット選択を適用する。各ノードは、現在のメンバシップリストを維持し、ランダムよりむしろラウンドロビン方式でピンターゲットを選択する。新しいノードは、脱優先されることを避けるために、エンドに付加される代わりに、ランダムな位置でリストに挿入される。リストの順序は、現在、および１回のスキャンが終了した後にシャッフルされる。加えて、ＳＷＩＭは、故障したようなノードを示す前に、メンバーがノードを疑うことができることによって、障害の偽陽性を減少させる。

【0095】

第三者のノード発見サービスを使用することは、可能な限りサービス依存性を最小にするために、故意に回避されることに注意されたい。

【0096】

実施形態は、障害回復のために、定期的にデータのスナップショットを取る。スナップショットは、外部キー値のデータストアＲｅｄｉｓに保存される。全てのノード電力サイクル、従って全てのインメモリデータが失われている停止状態の場合、実施形態は、Ｒｅｄｉｓ内のデータスナップショットをスキャンすることによって開始することができる。実験は、実施形態が１分間で障害から回復することができることを実証する。

【0097】

レプリカセットおよびクエリ転送
高い信頼性および耐久性は、データ複製（duplication）を必要とする。実施形態は、データ複製（replication）のためのレプリカセットを適用する。各データシャードは、ノードが等しく処理される複数のノードに複製される。シャードの書き込み動作は、全てのレプリカノードに伝搬される。コンシステシー構成に応じて、クォーラムベースのヴォーティングプロトコルは、適用されてもよいし、適用されていなくてもよい。利用可能性がコンシステシーを優先する場合、位置データの適時性のために、コンシステシーを緩和することができる。レプリカの数は、使用事例に基づいて構成可能である。

【0098】

一実施形態は、マスタースレーブデザインよりレプリカセットを好む。マスターメンバーシップを維持すること、またはマスターを再選択することは、余分なコストを招く。対照的に、レプリカセットは、より柔軟である。これは、利用可能性のためにコンシステシーをトレードする。コンシステトハッシュ法によって、ノードに分配されるシャードに対して、古典的な実装が使用される。すなわち、リング内の次のノードにそのレプリカを保存する。シャードテーブルにおけるシャードの場合、マッピングは、シャードのレプリカが保存されている場所を維持する。

【0099】

ｋ－最近傍クエリに応答すると、この実施形態は、各レプリカノードを等しく処理する。ノードが位置でｋ－最近傍探索リクエストを受信すると、それはアルゴリズム１を起動する。

【0100】

リモートコール（アルゴリズム１におけるライン３）に関して、シャード用のレプリカが存在するので、レプリカ、ファンアウト、またはラウンドロビンに対するクエリをバランスさせるための２つの戦略がある。ファンアウト設定では、ノードは、リモートコールをレプリカに並列に送る。そして、最も速く返された方の結果を受け取る。ラウンドロビン設定では、レプリカは、順番にリモートコールを取る。

【0101】

ｋ－最近傍クエリ
このセクションでは、出願人の実際のｋ－最近傍クエリを使用して、ｋ－最近傍クエリアルゴリズム１およびアルゴリズム２の性能を比較する。出願人は、毎日約６百万の自動車（rides）をサポートする。それにより、1日当たり１０億のｋ－最近傍クエリに達している。アルゴリズム１の時間の複雑さは、リモートコールの数によって支配される。これは、アクセスされたセルの数において線形である。アルゴリズム２は、アクセスされたシャードの数において線形である。従って、アクセスされたシャード内のアクセスされたセルの平均数は、アルゴリズム１に対するアルゴリズム２の改善を実証するために使用される。

【0102】

図６は、アクセスされたシャード内のアクセスされたセルの平均数を示す。時間の変化（ｘ軸）として、アクセスされたシャード内のアクセスされたセルの平均数はわずかに変化することに留意されたい。平均して、シャードにアクセスすることは、１２０個のセルの最悪の場合で、２７：３のセルをスキャンする。従って、アルゴリズム２は、平均して、アルゴリズム１より２７：３倍速い。さらに、アルゴリズム２でアクセスされたシャードの平均数は、１：２７である。これは、一定時間の複雑さを有効にする。

【0103】

ロードバランシング
このセクションでは、コンシステントハッシュ法は、それらのロードバランシング性能においてシャードテーブルと比較される。実験は、１０個のノードで実行された。１つの設定で、コンシステントハッシュ法がシャード分布のために使用される。一方、他の設定で、実施形態は、シャードテーブルインデックスおよびコンシステントハッシュ法の両方とともに使用される。書込みおよびｋ－最近傍クエリ負荷の両方は、実際の環境と比較される。いくつかのレベルの詳細は、商業的な理由のための二次対策のみを提示するために示されていない。

【0104】

図７ａは、コンシステントハッシュ法下で、１０個のノードの書込みおよびクエリ負荷分散を示す。シャードが物理的な世界と等しいとしても、ある国は、他の国よりも１つのシャードにおいてより多くのドライバを有する。そして、書き込み動作は、ドライバの数において線形である。図７ａに示すように、最も極端なノードは、ドライバ全体の３２：９％をホストする。一方、他のノードは、ドライバの少なくとも０：３７％をとる。サンプル分散は、１０３程度の高さである。同様に、ｋ－最近傍クエリ負荷も、０：７２％～３９：８４％の範囲で不均衡である。

【0105】

図７ｂは、本実施形態を用いた１０個のノード間の書き込みクエリ負荷分散を示す。書き込み負荷は、８：７１％～１３：９２％の範囲で、非常に良好にバランスされていることは明らかである。サンプルの分散は、３：６４程度の低いものである。現在の実施形態がｋ－最近傍クエリ負荷に対する書き込み負荷をバランスさせるのに好ましいということは、注目に値する。図７ｃは、実施形態のクエリ負荷分散を示す。バランスのとれた書き込み負荷で、すなわち、各ノードがほとんど同じ数のドライバをホストしながら、クエリ負荷は、１：９３％～３５：４９％の範囲で依然として変動する。しかし、それは、コンシステントハッシュ法よりも良好である。

【0106】

障害回復
このサブセクションでは、実施形態の性能は、障害回復について評価される。実験は、２．７ＧＨｚのインテルコアｉ７および１６ＧＢのメモリを備えたＭａｃＰｒｏ上で実行された。図８は、結果を示す。

【0107】

回復時間は、ドライバの数が増加するにつれて評価される。図８に示すように（ドライバの数の対数目盛りに注意）、ドライバの数が１ｋから５百万に増加するにつれて、回復時間は直線的に増加する。本実施形態は、５百万人のドライバであっても、２５秒未満で回復することができる。

【0108】

フローチャート
図２を参照すると、フローチャートは、複数のノード内でそれぞれ実行する２つのプロセス４３０および４５０を示す。ブロック４７０は、複数のレプリカセットを表す。データスナップショットプロセス４９０は、各ノード内で同様に実行される。

【0109】

図示のように、リクエストおよび書込みデータ４０１は、ロードバランシングデバイス４１１に入力される。そのデバイス４１１は、異なるノード間でリクエストおよび書込みを分配するように動作する。それによって、多くの負荷および書込みを処理する能力と負荷さえ保証する。ロードバランシングデバイス４１１は、書き込みデータタプルを含むリアルタイム位置データ４１３と、ｋ－最近傍クエリリクエスト４１５とのタイプによって、データを書き込みにソートする。

【0110】

書き込みデータタプルは、本明細書の他の場所に記載されているように、例えば、配車状況の車両、各オブジェクトのＩＤ、タイムスタンプ情報、およびメタデータなどの検討中のオブジェクトの地理的位置を含む。

【0111】

ｋ－最近傍クエリリクエストは、例えば、位置データ、タイムスタンプ、ｋ、および探索の半径を含むパケットのデータを含む。

【0112】

リアルタイム位置データ４１３は、２つの決定を実行する保存ユニット４３０に渡される。第１の決定ユニット４３１は、ＷＳＧ平面をシャードに分割したことを示すデータと、地理的データソース４２１からのコールとが供給され、インデックス機能を実行する。これにより、リアルタイム位置データ４１３がどのシャードおよびセルに属するかに関する決定が行われる。

【0113】

この決定を行った後、シャードがどのノードレプリカセットに位置されているかを決定するように、リアルタイムデータは、第２の決定ユニット４３３に渡される。これは、構成データ４２３、シャードテーブルおよびレプリカセットサイズに関連するデータが供給される。

【0114】

次いで、結果として得られたデータは、書込みユニット４３５によって使用されて、オブジェクト（配車アプリケーションにおける車両）の位置をノードレプリカセットのシャードに挿入する、または既にこのシャードに存在する場合には、オブジェクト位置を更新する。

【0115】

保存ユニットは、ノード発見４７１およびレプリカセットのデータ４７３を含む分散メモリ４７０にこのデータ４８１を書き込む。

【0116】

ｋ－最近傍リクエストデータ４１５は、クエリユニット４５０に渡す。クエリユニット４５０は、一次シャードデータをホストするノードにリクエストを転送するための第１のプロセス４４９と、レプリカセット内のクエリを転送するための第２のプロセス４５１と、第３のプロセス４５３とを実行する。すなわち、分散されたｋ－最近傍クエリアルゴリズムを実行する。その結果は、読み出しデータ４８７として分散メモリ４７０に出力される。この実施形態では、検索アルゴリズムの結果は、第１の場所でクエリを開始した発信者にさらに戻される(チャートには示されていない)。検索結果は、ｋ最近傍ドライバのＩＤと、それらの位置データと、タイムスタンプとである。

【0117】

分散メモリ４７０はまた、書き込みプロセス４８３を介してデータスナップショット４９０を書き込む。これは、障害回復４８５に使用可能である。

【0118】

アーキテクチャ
図１０を参照すると、インメモリデータベースシステムの簡略化された実施形態の概略ブロック図は、図２に関して先に説明したロードバランシングユニット４１１と共に、３つの保存ノードＡ、Ｂ、Ｃからなる。各保存ノードＡ、Ｂ、Ｃはそれぞれ、プロセッサＸ、Ｙ、Ｚおよびメインメモリ（例えば、ＲＡＭ）Ａ１、Ａ２、Ａ３を含む。使用時には、プロセッサＸ、Ｙ、Ｚは、図２に関して説明したように、プロセス４３０、４５０を実行する。インメモリ（すなわち、ＲＡＭ）ストレージは、大量のデータ書込み／更新リクエストをサポートするために使用される。

【0119】

将来のリモートまたはクラウドストレージが予想されるが、配車アプリケーションに必要とされる書き込み負荷のソートを扱うことは現在可能ではない。

【0120】

本実施形態では、大量のデータフローに対するデータ転送時間が有意にならないように、保存ノードを互いに十分に近接させることが重要である。

【0121】

複数のピアセットであるレプリカセットは、異なるノードに保存される。この理由の一つは、１つのノードが故障した場合、別のノードが依然として機能するということである。ハッシング／インデクシングプロセス（コンシステントハッシュ法またはシャードテーブルインデクシング）を使用して、複数のどのノードで、特定のシャードが保存されるかを決定する。本実施形態では、データは、そのデータの一次ホームとして固定されてるノードなしに複数のノードに保存される。

【0122】

以下の説明では、説明を容易にするために、添付図面を単一の線として示している。このことは、実際の実施形態の場合ではないことが理解される。その実施形態において、非常に高いデータレートは、多導体バスまたは他の相互接続を介して転送される。

【0123】

図示のように、バランシングユニット４１１に向かって示している矢印７１３は、システムに入力されるサービスプロバイダ（例えば、ドライバ位置）更新情報を表す。矢印７１４は、入力されている最近傍探索リクエストを表す。ユニット４１１から上方を指示する矢印７１５は、データベースから出力されるクエリ結果を表す。ロードバランサ４１１は、読み出しおよび書き込みの負荷をバランスするために、ノード間で探索リクエストおよびサービスプロバイダデータを分配する。ロードバランスユニット４１１からノードＡへの矢印７１７は、ノード（ノードＡ）に渡されるサービスプロバイダデータを表す。矢印７１９は、ノードから出るクエリ結果を表す。７０７は、ユニット４１１からノードＣへのデータである。７０９は、ノードＣからのクエリ結果である。

【0124】

ノードＡにおいて、矢印７２３は、プロセッサＸから保存位置Ａ１へ、および保存位置Ａ１からプロセッサＸへのドライバデータフローを表す。保存位置Ａ３は、位置Ｂ２に保存されたデータのシャードのレプリカセットを表す。ノードＢは、位置Ｂ２に保存されたデータのシャードのためのホストノードである。

【0125】

矢印７２５は、保存位置Ａ３への読取りおよび書込みアクセスを表す。これは、位置Ｂ２に保存されたデータのレプリカセットを保存する。上述したように、一実施形態では、レプリカセットは、異なるノードに保存される。その結果、１つのノードが問題を有する場合には、別のノードまたは他のノードを使用するサービスが依然として存在する。

【0126】

矢印７２７は、ノードＡおよびＢのプロセッサＸとＹとの間のデータ転送を表す。矢印７２９は、位置Ｂ２へ、および位置Ｂ２からのデータ転送を表す。矢印７３１は、プロセッサＹとＺとの間のデータフローを表す。

【0127】

動作の簡単な例として、探索は、位置Ｂ２に保存されたデータを探索するために、ロードバランサ４１１でリクエストされ、この探索リクエストは、ライン７０７を介してノードＣにロードバランサ４１１によって渡されることを仮定する。ノードＣがリクエストを受信した後、それは、接続７３１を介して、「ホスト」ノード、ノードＢにリクエストを転送するために、“ｋｎｏｗ”に対してコンシステントハッシュ法またはシャードテーブルインデックスを使用する。クエリ位置は、保存される。次に、ホストノード、ノードＢのプロセッサは、ライン７２９を介してクエリを実行する。位置Ｂ２に保存されたデータを更新する場合、プロセッサＹは、位置Ａ３のレプリカセットも更新されるように、接続７２７を介して更新データを転送する。

【0128】

上記は、非現実的なシステムの非常に簡略化された説明を表す。実際には、多数のノードにある複数のレプリカセットが存在する。多くの実施形態では、ノードＡからノードＢからノードＣへの単純な相互接続は、相互接続のネットワークによって置き換えられる。

【0129】

使用時に、探索クエリがファンアウトモードで実行される場合、ノードＡおよびノードＢの両方は、データおよびリターンに関するクエリを実行する。この場合、ＡおよびＢの両方は、ホストノードである。設定がラウンドロビンである場合、例えば、ノードＡおよびノードＢは、クエリを実行するためにホストノードとなることを交代で行う。

【0130】

実施形態の利点
実施形態は、キーによる大量の頻繁な書き込みのためのサポートを提供する。すべてのオブジェクトの現在位置を更新し追跡するために、書込み操作が必要である。ドライバは、シンガポールのような発展した国で、毎秒２５メートルを移動することができる。従って、ミリ秒でなければ、秒毎にドライバの位置を更新することが重要である。従って、書込み動作のためにディスクＩ／ＯＳで被る従来の相関的データベースまたは地理的空間データベースは、使用するにはあまりにも高価である。実施形態は、分散環境におけるインメモリのデータを保存する。

【0131】

全てのオブジェクトが１つのコンピュータ（machine）のメモリに適合することができるとしても、単一のコンピュータは、大量の書き込みおよびｋＮＮクエリによってすぐに圧倒される。そして、リアルタイム位置が報告されるドライバの数を念頭に置いている。この問題を解決するために、実施形態は、オブジェクト（例えば、ドライバ）をそれらの地理的位置に従って、異なるノード（すなわち、コンピュータ）に分配する。

【0132】

地理的位置によるｋＮＮのサポート
周知のキー値データストア（例えば、ダイナモおよびメモキャッシュ）は、キーとしてオブジェクトを保存し、それらの位置を値として保存する。次に、ｋＮＮ探索は全てのキーをスキャンし、ペアワイズ距離を計算することを必要とする。そのレイテンシーは許容できない。従来のｋＮＮ探索アルゴリズムは、クエリを速めるために、Ｒ－ツリーのようなインデックスに依存する。しかし、頻繁な書き込みを処理しながら、このような複雑なインデックスを維持することは不可能である。実施形態は、ｋ最近傍クエリに応答するために、幅優先探索アルゴリズムを適用する。シャードを小さなセルにさらに分割することにより、実施形態は、十分なシャードスキャンを回避する。それは、クエリポイントが存在するセルから開始し、隣接するセルを徐々に探索する。リモートコールを減少させるために、実施形態は、シャードレベルでコールを集約する。これは、並列性も達成する。

【0133】

不均衡な負荷のためのサポート
地理的シャードは固定された物理的サイズ（例えば、２０ｋｍ×２０ｋｍ）であるので、あるシャードが他のシャードよりも多くのデータおよびクエリを有することは驚くべきことではない。例えば、より大きな都市（例えば、シンガポール）のシャードは、より小さい都市（例えば、バリ）のシャードよりも５倍多くのドライバを有する。その結果、前者のシャードは、後者のシャードよりも５倍多くの書込みを有する。高需要エリア（例えば、ダウンタウンエリア）におけるシャードは、地方のエリアよりもはるかに多く照会される。このような不均衡な負荷は、スケールアウトポリシーの極端な困難性の原因になる。コンシステントハッシュ法は、ノードを横切って移動する必要があるデータの量を最小にするので、スケールアウトに広く使用されている。しかし、１つのノードがホットスポットになり、新しいノードが追加されると、コンシステントハッシュ法は、ランダムにノードを選択し、そのデータの一部を新しいノードに転送する。残念ながら、ホットスポットノードが選択されないと、その状況は全く緩和されない。この状況は、新しいアイドルインスタンスを追加するデッドループで終了する可能性が非常に高い。

【0134】

一実施形態は、ロードバランシングのためのコンシステントハッシュ法に対する補間として、およびコンシステントハッシュ法と一緒に使用する補間として、シャードテーブルを提案する。コンシステントハッシュ法は、ほぼ等しい数のシャードをノードに分配するが、シャードテーブルは、１つまたは複数のノードを１つの特定のシャードに専用にするように構成されている。シャードテーブルは、半自動構造であるが、実際には、人間の介入はほとんど必要とされない。

【0135】

信頼性、高速障害検出および回復
実施形態は、高利用可能性のために強いコンシステンシーを犠牲にするレプリカセットを使用する。同時に、異なるレプリカは、異なるデータ状態を見る。これは、我々の使用ケースに重要ではない。レプリカセットは、システム全体を高い利用可能性にする。実施形態は、高速障害検出を達成するために、ゴシップスタイルのプロトコルＳＷＩＭを利用する。地域的な停止状態の場合、実施形態は、データスナップショットが非同期に維持される外部データストアから迅速に回復することができる。

【0136】

本発明は、一例としてのみ記載されていることが理解される。添付の特許請求の範囲の精神および範囲から逸脱することなく、本明細書に記載された技術に対して種々の変更が可能である。開示された技術は、独立して、または互いに組み合わせて提供される技術を含む。したがって、１つの技術に関して説明された特徴を他の技術と組み合わせて提示することもできる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】