ホーム > 特許ランキング > ドライブネッツ リミテッド
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022109898
(43)【公開日】2022-07-28
(54)【発明の名称】分散データベースシステム
(51)【国際特許分類】
G06F 16/28 20190101AFI20220721BHJP
G06F 16/22 20190101ALI20220721BHJP
【ＦＩ】
G06F16/28
G06F16/22
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2022004354
(22)【出願日】2022-01-14
(31)【優先権主張番号】63/137,750
(32)【優先日】2021-01-15
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】519425187
【氏名又は名称】ドライブネッツ リミテッド
(74)【代理人】
【識別番号】100067736
【弁理士】
【氏名又は名称】小池 晃
(74)【代理人】
【識別番号】100192212
【弁理士】
【氏名又は名称】河野 貴明
(74)【代理人】
【識別番号】100200001
【弁理士】
【氏名又は名称】北原 明彦
(72)【発明者】
【氏名】フレイリクマン，グレゴリー
(72)【発明者】
【氏名】ヘット，オレン
(72)【発明者】
【氏名】コレン，イド
(72)【発明者】
【氏名】ロテンバーグ，ガル
(72)【発明者】
【氏名】ラスリー，アミット
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175AA01
5B175CA02
5B175KA08
(57)【要約】 （修正有）
【課題】各々のクライアントプラットフォームの静的部分を得る分散データ記憶システムを提供する。
【解決手段】分散データ記憶システム２００は、複数のデータ型に関連するキー値を記憶するように構成されたデータベースサーバ２２０と、複数のクライアントプラットフォーム２１０と、を含む。複数のクライアントプラットフォームのそれぞれは、少なくとも１つのデータ型のデータを記憶し、索引化情報を記憶するように構成され、前記複数のクライアントプラットフォームのそれぞれは、データベースロジックコンパイラ（ＤＢＬＣ）により、各々のデータスキームのコンパイルをオブジェクト関係マッピング（ＯＲＭ）２１６内に実装し、各々のクライアントプラットフォームの静的部分を得る。
【選択図】図２
【解決手段】分散データ記憶システム２００は、複数のデータ型に関連するキー値を記憶するように構成されたデータベースサーバ２２０と、複数のクライアントプラットフォーム２１０と、を含む。複数のクライアントプラットフォームのそれぞれは、少なくとも１つのデータ型のデータを記憶し、索引化情報を記憶するように構成され、前記複数のクライアントプラットフォームのそれぞれは、データベースロジックコンパイラ（ＤＢＬＣ）により、各々のデータスキームのコンパイルをオブジェクト関係マッピング（ＯＲＭ）２１６内に実装し、各々のクライアントプラットフォームの静的部分を得る。
【選択図】図２
【特許請求の範囲】
【請求項1】
複数のデータ型に関連するキー値を記憶するように構成されたデータベースサーバを含む分散データ記憶システムであって、
前記分散データ記憶システムが複数のクライアントプラットフォームを有し、前記複数のクライアントプラットフォームのそれぞれは、少なくとも１つのデータ型のデータを記憶し、索引化情報を記憶するように構成され、前記複数のクライアントプラットフォームのそれぞれは、データベースロジックコンパイラ（ＤＢＬＣ）により、各々のデータスキームのコンパイルをオブジェクト関係マッピング（ＯＲＭ）内に実装するように構成され、それにより、各々のクライアントプラットフォームの静的部分を得ることを可能にすることを特徴とする分散データ記憶システム。
前記分散データ記憶システムが複数のクライアントプラットフォームを有し、前記複数のクライアントプラットフォームのそれぞれは、少なくとも１つのデータ型のデータを記憶し、索引化情報を記憶するように構成され、前記複数のクライアントプラットフォームのそれぞれは、データベースロジックコンパイラ（ＤＢＬＣ）により、各々のデータスキームのコンパイルをオブジェクト関係マッピング（ＯＲＭ）内に実装するように構成され、それにより、各々のクライアントプラットフォームの静的部分を得ることを可能にすることを特徴とする分散データ記憶システム。
【請求項2】
前記少なくとも１つのデータ型は、ハッシュマップ、ソートされたセット、リスト、２分探索木（ＢＳＴ）から成るグループの要素であることを特徴とする請求項１に記載の分散データ記憶システム。
【請求項3】
前記データスキームは、データ型、データ関係、データが索引付けされるべきか、そしてどのように索引付けされるべきかの少なくとも１つに関する情報を含むことを特徴とする請求項１に記載の分散データ記憶システム。
【請求項4】
前記データベースロジックコンパイラ（ＤＢＬＣ）は、コンパイル中の各データ入力の為のシャードＩＤを計算するように構成されることを特徴とする請求項１に記載の分散データ記憶システム。
【請求項5】
全ての関連データ入力は単一のシャード上に記憶され、無関係のデータは異なるシャード上に記憶されることを特徴とする請求項３に記載の分散データ記憶システム。
【請求項6】
前記データベースサーバを維持する為に必要な周期関数は、追加のコンピュータプラットフォームにより実装されることを特徴とする請求項１に記載の分散データ記憶システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、包括的には、データベースの分野に関する。特に、データベースのロジックの存在場所に関する。
【0002】
ＢＳＴ：２分探索木（Binary Search Tree）
ＣＰＵ：中央処理装置（Central Processing Unit）
ＣＳＤＤ：クライアント側分散データベース(Client-Side Distributed Database)
ＤＢＬＣ：データベースロジックコンパイラ(Database Logic Compiler)
ＯＲＭ：オブジェクト関係マッピング(Object Relational Mapping)
ＴＴＬ：有効時間(Time to Live)
ＣＰＵ：中央処理装置（Central Processing Unit）
ＣＳＤＤ：クライアント側分散データベース(Client-Side Distributed Database)
ＤＢＬＣ：データベースロジックコンパイラ(Database Logic Compiler)
ＯＲＭ：オブジェクト関係マッピング(Object Relational Mapping)
ＴＴＬ：有効時間(Time to Live)
【背景技術】
【0003】
データベースの分野において、当業者に共通のアプローチは、サーバは重いモノリシックのデバイスであるということである。サーバは、「スマート」であり、例えば、索引付け、スキーム実施、複雑なクエリ（結び付け）、周期的クリーンアップルーチン、シャード(shards)、複製等の必要なロジック全てを維持し、一方、クライアントエンティティは薄いロジックである（即ち、多くのロジックを含まない、又は、即ち、エンティティ自体が比較的「データ処理能力のない」(“dumb”)エンティティである）。
【0004】
そのような実装は、多くの困難を伴う。
ａ．各々の新しい機能が導入されると、サーバは再展開されなければならず、時には、クライアントエンティティを更新する必要がある。
ｂ．クライアントエンティティはサーバの機能のサブセットを使用することができるが、それでも多数のクライアントエンティティが同じコードパスを使用した場合、性能が低下することがある。サーバへの新たな機能の追加に伴い、この難点は時間と共に悪化する。
ｃ．クライアントエンティティは薄いエンティティであるから、実行されたクエリ上のきめ細かい制御を通常有していない。その結果、クライアントエンティティは、例えば、インデックスを更新することなくデータベース内のエントリを更新することができない。
ａ．各々の新しい機能が導入されると、サーバは再展開されなければならず、時には、クライアントエンティティを更新する必要がある。
ｂ．クライアントエンティティはサーバの機能のサブセットを使用することができるが、それでも多数のクライアントエンティティが同じコードパスを使用した場合、性能が低下することがある。サーバへの新たな機能の追加に伴い、この難点は時間と共に悪化する。
ｃ．クライアントエンティティは薄いエンティティであるから、実行されたクエリ上のきめ細かい制御を通常有していない。その結果、クライアントエンティティは、例えば、インデックスを更新することなくデータベース内のエントリを更新することができない。
【0005】
大きくてスケーラブルなデータベースアーキテクチャを実装する多くの慣習的なデータベースシステムが存在する。様々なデータベースアーキテクチャが選択され、特定のデータ要件に適合される。しかしながら、様々なアーキテクチャをサポートするシステムの数が増加すると、データベースシステムの複雑性も同様に増加する。いくつかの場合、データベースシステムの管理がアーキテクチャ自体と同様に複雑になり、大きなデータベース上に変更を加える必要がある管理者を対応不可能にする。
【0006】
この複雑性の少なくとも一部を解決する試みにおいて、米国特許公報ＵＳ１０７１３２８０には、クラウドベースのリソースと、クラウドベースのリソース上で実行されるデータベースサブシステムと、クラウドリソースに接続されたクライアントシステムから通信される接続文字列に基づいてクライアントシステムの認証を制御するように構成されたプロキシ層と、を含むクラウド分散データベースが開示されている。上記公報は、データベース構築における構成選択上のクライアントの入力を可能にしながら、多くの分散データベース実装に関連する設計課題を解消するクラウドサービスとしてデータベースを開示する。また、クライアントは、データベースノードの数、ノードの能力、そして数分の内に、完全に機能する、スケーラブルな、複製の、セキュア分散データベースをクラウド内に識別することができる。
【0007】
米国特許出願公報ＵＳ２０１３０２９０２４９には、分散データベースのスケール変更を提供しながら、分散データベース環境における非同期複製を管理するシステム及び方法が記載されている。この公報に記載の解決策により、ノードのクラスタは、データベース内のデータの分割を管理し、データベース要求を処理する役割を割当られる。各クラスタは、書込動作を処理し、少なくとも１つの二次ノードへの動作の非同期複製を管理する主な役割を有するノードを含むことができる。各クラスタ又はノードのセットは、データベースのデータの１以上の分割をホストすることができる。集合的に、クラスタ又はノードのセットは、分散データベースの全てのデータをホストするシャードクラスタ(shard cluster)を定義する。各シャードクラスタ、個別のノード、又はノードのセットは、新しいシステムを含む為のシャードクラスタの管理拡張、及び／又は、任意のホストされた分割、分離されたデータベース分割、マイグレートされた分割のサイズを管理するように構成されることができる。
【0008】
本開示は、高性能アジャイルデータベースシステムを提供する新しい解決策を提供する。
【発明の概要】
【発明が解決しようとする課題】
【0009】
本開示は、添付の特許請求の範囲を参照することによって要約することができる。
【0010】
本開示の目的は、薄型高性能データベースサーバを含む新規な記憶システムを提供することである。
【0011】
本開示の他の目的は、シャードＩＤ(shard ID)等のプリコンパイルされたデータを含む低レベルサーバ運用にデータスキームをコンパイルするように構成された新しいＤＢＬＣロジックを含む新規の記憶システムを提供することである。
【0012】
本開示の他の目的は、システムのメインロジックがクライアント側に存在する新規の記憶システムを提供することである。
【0013】
本開示の他の目的は、現在実行することが必要な機能のみを実装するようにクライアントが構成される新規の記憶システムを提供することである。
【0014】
本開示の他の目的は、以下の説明から明らかになる。
【課題を解決するための手段】
【0015】
本開示の第１の実施形態によると、複数のデータ型に属するデータに関連するキー値を記憶するように構成されたデータベースサーバを含む分散データ記憶システムであって、前記分散データ記憶システムが複数のクライアントプラットフォームを有し、前記複数のクライアントプラットフォームのそれぞれは、少なくとも１つのデータ型のデータを記憶し、索引化情報を記憶するように構成され、前記複数のクライアントプラットフォームのそれぞれは、データベースロジックコンパイラ（ＤＢＬＣ）により、各々のデータスキームのコンパイルをオブジェクト関係マッピング（ＯＲＭ）内に実装するように構成され、それにより、各々のクライアントプラットフォームの静的部分を得ることを可能にすることを特徴とする分散データ記憶システムが提供される。
【0016】
即ち、提案されているシステムは、異なるデータ型の使用を可能にしながら、低レベル高性能動作のセットを提供するデータベースサーバを含む。
【0017】
クエリ及びデータベースロジックは、データソース（即ち、クライアント側）の近くに実装されるので、当業者には既知の現在の実装においては不可能である最適化が可能になる。それにより、経時的に性能劣化することなく、より高いエンドツーエンド性能及びアジャイル機能開発を可能にする。
【0018】
他の実施形態によると、少なくとも１つのデータ型は、ハッシュマップ、ソートされたセット、リスト、２分探索木（ＢＳＴ）等から成るグループの要素である。
【0019】
他の実施形態によると、データスキームは、データ型、データ関係、データが索引付けされるべきかそしてどのように索引付けされるべきか、及び他の適用可能なメタデータの少なくとも１つに関する情報を含む。
【0020】
これらのデータ型はクライアントプラットフォームにより使用され、（適切なデータ型を使用して）データ記憶及び索引化の両方を実装する。このことは、中央処理装置及びコンパイラに類似し、（データベースサーバに類似する）中央処理装置は基本動作を提供し、（クライアントプラットフォームに類似する）コンパイラは、これらの低レベル動作の複雑なアプリケーションロジックをコンパイルするように構成される。
【0021】
また、ランタイムフラグは、（例えば、データ入力の正確なキーが既知である場合）インデックスをチェックすることのない直接的データクエリ、又は、非索引化データ記憶を実行する追加の適応性を可能にする。
【0022】
他の実施形態によると、データベースロジックコンパイラ（ＤＢＬＣ）は、コンパイル中の各データ入力の為のシャードＩＤを計算するように構成される。
【0023】
他の実施形態によると、全ての関連データ入力は単一のシャード上に記憶され、無関係のデータは異なるシャード上に記憶される。
【0024】
この実施形態の実装は、単純な水平方向及び垂直方向への拡張（データベースサーバが同じホストで広げられて水平方向の成長が得られ、他のサーバまで広げられて垂直方向の拡張が得られること）を可能にする。
【0025】
他の実施形態によると、データベースサーバを維持する為に必要な周期関数は、追加のコンピュータプラットフォームにより実装される。
【0026】
好ましくは、データベースサーバを維持する為に必要な周期関数、例えば、クリーンアップ又は他の任意の周期関数は、（データベースサーバに含まれない他のクライアントとして動作する）追加のコンピュータプラットフォームにより実装され、それにより、データベースサーバを可能な限り薄型及び高速に維持する。
【0027】
この明細書の一部を構成し、ここに組み込まれる添付の図面は、本開示のいくつかの実施形態を図示しており、明細書の記載と共に、ここに開示されている実施形態の原理を説明するものです。
【図面の簡単な説明】
【0028】
【発明を実施するための形態】
【0029】
以下の詳細な説明における特定の詳細及び値の一部は、本開示の特定の例を示している。但し、この説明は、例示的なものであり、本発明の範囲を限定することを意図するものではない。特許請求されるシステムは、当該技術分野で公知の他の手法によって実現できることは、当業者にとって明らかである。更に、ここに記述した実施形態は、実行される異なるステップを含むが、その全てが本発明の全ての実施形態において必要とされるわけではない。本発明の範囲は、添付の特許請求の範囲を参照することにより要約できる。
【0030】
本開示の基礎原理の１つは、分散データ記憶システムが低レベル高性能動作のセットを可能にする薄型高性能データベースサーバを含み、したがって、クエリ及びデータベースロジックがクライアント側に実装されるので、実行される必要がある動作を最適化することが可能になる。
【0031】
図１には、本発明の実施形態によるＤＢＬＣコンパイルの例が示されている。この実施例によると、（不図示の）クライアントプラットフォームは、データベースロジックコンパイラ（ＤＢＬＣ）（１１０）により、各々のデータスキーム（１００）のコンパイルをオブジェクト関係マッピング（ＯＲＭ）（１２０）内に実装するように構成され、それにより、各々のクライアントプラットフォームの静的部分を得ることを可能にする。この図に図示されているように、データモデルの為に正しいインデックスが選択される。エンティティ「車」には、同じオブジェクト関係マッピング（１２０）に含まれるエンティティ「グループ」又はエンティティ「人」のシャードＩＤ：０とは異なるシャードＩＤ：１が提供される。本発明を使用することにより、このオプションを実装することが可能になる。なぜなら、独立して、データスキームに異なるシャードを使用することができるからである。このコンパイル時間決定は、ランタイムでシャードＩＤが計算され、その後、データがクラスタ内の正しいシャードにリダイレクトされる一般的な実装とは対照的に、クライアントから直接クラスタ内の正しいシャードにデータを送信することを可能にする。この実施例は、性能を改善する為にコンパイル時間決定／最適化がどのような影響を受けるかを実証する役割を果たすものである。
【0032】
図２には、本発明の実施形態に従って解釈される、分散データ記憶システム（２００）の例が示されており、中でも、静的部分及び動的部分が示されている。
【0033】
この実施例に示されている分散データ記憶システム（２００）は、クライアントプラットフォーム（２１０）（他のクライアントプラットフォームは不図示）及び薄型データベースサーバ（２２０）を含む。
【0034】
クライアントプラットフォーム（２１０）は、２つの主部分を含み、２つの主部分の１つは、ユーザアプリケーション（２１４）から受信された情報に基づいて実行されるランタイム動作である動的部分（２１２）である。もう１つの主部分は、対応するデータスキーム（２１８）から受信された情報に基づく静的部分、オブジェクト関係マッピング（２１６）である。システムは、クライアントプラットフォーム（２１０）からデータベースサーバ（２２０）へ低レベルコマンドを伝送し、そのサーバから各応答を受信することにより、動作する。
【0035】
ここで、クライアントが名前「アリス」を有する「人」エンティティ（図１参照）を作成する実施例を考慮する。以下の処理手続が実装される。まず、「アリス」がインデックス「／人」に追加され、その後、人エンティティ「アリス」がキー値記憶装置に追加される。これらの低レベル命令は、静的部分を使用して生成される。しかしながら、クライアントはフラグを追加することができるので、インデックスを操作することなく、キー値記憶装置に人エンティティを追加することのみが作用する。好ましくは、このことは、インデックスが既に作成され、データの更新のみが必要であることがクライアントには確かである場合に実行される。そのような方法を適用することは、性能を劇的に改善する為に効果的である。
【0036】
本発明は、単なる例として提供され、本発明の範囲を限定することを意図していない実施形態の詳細な説明を使用して、説明されている。記載されている実施形態は異なる構成を含み、全ての構成が本発明の全ての実施形態において必要であるわけではない。本発明のいくつかの実施形態は、いくつかの構成のみ、又は構成の可能な組み合わせを使用するものである。記載されている本発明の実施形態の変形、及び記載の実施形態に示されている構成の異なる組み合わせを含む本発明の実施形態は、当業者には自明である。本発明の範囲は、以下の特許請求の範囲によってのみ限定されるものである。
【図1】
【図2】
【外国語明細書】
A DISTRIBUTED DATABASE SYSTEM
TECHNICAL FIELD
The present disclosure generaly relates to the field of databases. More specifically, it relates to where the logic of the database resides.
GLOSSARY
BST - Binary Search Tree.
CPU - Central Processing Unit.
CSDD - Client-Side Distributed Database.
DBLC - Database Logic Compiler.
ORM - Object Relational Mapping.
TTL - Time To Live.
BACKGROUND
In the field of databases, the common approach in the art is that servers are heavy monolithic devices. The servers are “smart” and maintain all the required logic, for example, indexing, scheme enforcement, complex querying (joins), periodic cleanup routines, shards, replications, and the like, while client entities are thin (i.e., they do not comprise too much logic, or in other words, entities which are relatively “dumb” entities).
Such implementations entail a number of difficulties:
The server must be redeployed when each new feature is introduced thereat, and sometimes also client entities need to be updated.
Although a client entity may use a subset of the server’s features, still, its performance might deteriorate if a substantial number of client entities use the same code path. This difficulty will intensify in time, along with the addition on new features to the server.
Because client entities are thin entities, they usually do not have a fine-grained control over the executed queries. Consequently, a client entity would not be able to update an entry within the database without updating the index, for example.
A number of conventional database systems exist that implement large and scalable database architectures. A variety of database architectures can be selected and tailored to specific data requirements. However, as the number of systems that support the various architectures increase, the complexity of the database system likewise increases. In some cases, management of the database system becomes as complex as the architecture itself, and can overwhelm administrators who need to make changes on large databases.
In an attempt to solve at least some of this complexity, US 10713280 discloses a cloud distributed database that comprises a cloud-based resource, a database subsystem executing on the cloud-based resource, a proxy layer configured to control authentication of client systems based on connection strings communicated from the client systems connecting to the cloud resources. The publication discloses a database as a cloud service that eliminates the design challenges associated with many distributed database implementations, while allowing the client's input on configuration choices in building the database. Also, clients may identity a number of database nodes, capability of the nodes, and within minutes have a fully functioning, scalable, replicated, and secure distributed database in the cloud.
US20130290249 describes systems and methods for managing asynchronous replication in a distributed database environment, while providing for scaling of the distributed database. By the solution described in this publication, a cluster of nodes is assigned with roles for managing partitions of data within the database and processing database requests. Each cluster may include a node with a primary role to process write operations and mange asynchronous replication of the operations to at least one secondary node. Each cluster or set of nodes can host one or more partitions of database data. Collectively, the cluster or set of nodes define a shard cluster that hosts all the data of the distributed database. Each shard cluster, individual nodes, or sets of nodes can be configured to manage the size of any hosted partitions, splitting database partitions, migrating partitions, and/or managing expansion of shard clusters to encompass new systems.
The present disclosure provides a new solution that provides a high performance, agile database system.
SUMMARY
The disclosure may be summarized by referring to the appended claims.
It is an object of the present disclosure to provide a novel storage system that comprises a thin, high performance database server.
It is another object of the present disclosure to provide a novel storage system that comprises a new DBLC logic configured to compile data scheme to the low-level server operations, with precompiled data such as shard ID.
It is another object of the present disclosure to provide a novel storage system wherein the main logic of the system resides at the client side.
It is another object of the present disclosure to provide a novel storage system wherein clients are configured to implement only features which are currently needed to be carried out.
Other objects of the present disclosure will become apparent from the following description.
According to a first embodiment of the present disclosure there is provided a distributed data storage system comprising:
a database server adapted to store key values associated with data being data that belong to a plurality of data types; and
wherein said distributed data storage system is characterized by having a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.
In other words, the proposed system comprises a database server that provides a set of low level, very high-performance operations while enabling the use of different data types.
Because the querying and database logic is implemented close to the data source (i.e., at the client side), optimizations that would otherwise be impossible in current implementations known in the art, become possible. Thereby, allowing higher end-to-end performance and agile feature development without performance degradation over time.
According to another embodiment, the at least one data type is a member of a group that consists of: a hash map, a sorted set, a list, a binary search tree (BST), and the like.
In accordance with another embodiment, the data scheme comprises information that relates to at least one of: data types, data relations, if and how data should be indexed, and other applicable metadata.
These data types are used by client platforms to implement both data storing (using the appropriate data type) and indexing. This is analogous to a CPU and compilers: the CPU (analogous to the database server) provides basic operations, while the compilers (which are analogous to client platforms) are configured to compile complex application logic for those low-level operations.
In addition, runtime flags may enable additional flexibility to enforce non-indexed data stores, or query data directly without having to check the index (e.g., if the exact key of the data entry is known).
By yet another embodiment, the database logic compiler (DBLC) is configured to calculate a shard ID for each data entry during compilation.
According to still another embodiment, all related data entries are stored on a single shard, while unrelated data may be stored on a different shard.
Implementing this embodiment, allows simple horizontal and vertical expansion (an instance wherein the database server is spanned at the same host to obtain horizontal growth, and to another server to obtain a vertical expansion).
In accordance with yet another embodiment, periodic functions that are required to maintain the database server are implemented by an additional computing platform.
Preferably, the periodic functions required to maintain the database server such as, for example, cleanups, or any other periodic function are implemented by an additional computing platform (i.e., one which operates as another client not included in the database server), to maintain the database server as thin and as fast as possible.
BRIEF DESCRIPTION OF DRAWINGS
The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate several embodiments of the disclosure and, together with the description, serve to explain the principles of the embodiments disclosed herein.
FIG. 1 illustrates an example of a DBLC compilation construed in accordance with an embodiment of the present invention; and
FIG. 2 demonstrates an example of a distributed data storage system construed in accordance with an embodiment of the present invention.
DESCRIPTION OF EXEMPLARY EMBODIMENTS
Some of the specific details and values in the following detailed description refer to certain examples of the disclosure. However, this description is provided only by way of example and is not intended to limit the scope of the invention in any way. As will be appreciated by those skilled in the art, the claimed system may be implemented by using other methods that are known in the art per se. In addition, the described embodiments comprise different steps that are carried out, not all of which are required in all embodiments of the invention. The scope of the invention can be summarized by referring to the appended claims.
One of the underlying principles of the present disclosure is that distributed database storage system comprises a thin, high performance database server that enables a set of low level, very high-performance operations, therefore since the querying and database logic is implemented at the client side, it becomes possible to optimize operations that need to be carried out.
FIG. 1 illustrates an example of a DBLC compilation in accordance with an embodiment of the present invention. According to this example, a client platform (not shown in this figure) is configured to implement compilation of its respective data scheme (100) by a database logic compiler (DBLC) (110) into an object relational mapping (ORM) (120), to enable obtaining a static part of that respective client platform. As may be seen in this figure, the right indexes are selected for the data-model. It should be noted that the entity "car" is provided with a different shard ID, 1, than the shard ID, 0, of the "group" entity or the "person" entity included at the same ORM (120). By using the present invention, it becomes possible to implement this option because the different shard may be used in the data scheme, independently. This compile time decision allows to send data to the right shard in the cluster directly from the client, as opposed to common implementations in which shard ID is computed at runtime and then the data is redirected to the right shard in the cluster. The example serves to demonstrate how compile time decisions/optimizations may be affected in order to improve performance.
FIG. 2 demonstrates an example of a distributed data storage system (200) construed in accordance with an embodiment of the present invention, presenting among others the static and dynamic parts thereof.
Distributed data storage system (200) shown in this example comprises a client platform (210) (other client platforms are not shown in this figure) and a thin database server (220).
Client platform (210) comprises two main parts, a dynamic part (212) at which runtime operations are carried out base on information received from user application (214). The other main part is a static part, ORM (216), which is based on information received from a corresponding data scheme (218). The system operates by conveying low-level commands from client platform (210) to database server (220) and receiving the respective responses from that server.
Now, let us consider an example where a client creats a "Person" entity (see FIG. 1) with the name “Alice”. The following procedure may be implemented. First “Alice" will be added to index “/person”, and then “Alice” Person entity will be added to key-value storage. These low-level instructions are generated using the static part. However, a client may add a flag so that only adding of a Person entity to the key-value storage, will be affected without manipulating the index. Preferably, this is done if the client is sure that the index has already been created, and data only needs to be updated. Adopting such a method is effective in improving performance quite dramatically.
The present invention has been described using detailed descriptions of embodiments thereof that are provided by way of example and are not intended to limit the scope of the invention in any way. The described embodiments comprise different features, not all of which are required in all embodiments of the invention. Some embodiments of the present invention utilize only some of the features or possible combinations of the features. Variations of embodiments of the present invention that are described and embodiments of the present invention comprising different combinations of features noted in the described embodiments will occur to persons of the art. The scope of the invention is limited only by the following claims.
TECHNICAL FIELD
The present disclosure generaly relates to the field of databases. More specifically, it relates to where the logic of the database resides.
GLOSSARY
BST - Binary Search Tree.
CPU - Central Processing Unit.
CSDD - Client-Side Distributed Database.
DBLC - Database Logic Compiler.
ORM - Object Relational Mapping.
TTL - Time To Live.
BACKGROUND
In the field of databases, the common approach in the art is that servers are heavy monolithic devices. The servers are “smart” and maintain all the required logic, for example, indexing, scheme enforcement, complex querying (joins), periodic cleanup routines, shards, replications, and the like, while client entities are thin (i.e., they do not comprise too much logic, or in other words, entities which are relatively “dumb” entities).
Such implementations entail a number of difficulties:
The server must be redeployed when each new feature is introduced thereat, and sometimes also client entities need to be updated.
Although a client entity may use a subset of the server’s features, still, its performance might deteriorate if a substantial number of client entities use the same code path. This difficulty will intensify in time, along with the addition on new features to the server.
Because client entities are thin entities, they usually do not have a fine-grained control over the executed queries. Consequently, a client entity would not be able to update an entry within the database without updating the index, for example.
A number of conventional database systems exist that implement large and scalable database architectures. A variety of database architectures can be selected and tailored to specific data requirements. However, as the number of systems that support the various architectures increase, the complexity of the database system likewise increases. In some cases, management of the database system becomes as complex as the architecture itself, and can overwhelm administrators who need to make changes on large databases.
In an attempt to solve at least some of this complexity, US 10713280 discloses a cloud distributed database that comprises a cloud-based resource, a database subsystem executing on the cloud-based resource, a proxy layer configured to control authentication of client systems based on connection strings communicated from the client systems connecting to the cloud resources. The publication discloses a database as a cloud service that eliminates the design challenges associated with many distributed database implementations, while allowing the client's input on configuration choices in building the database. Also, clients may identity a number of database nodes, capability of the nodes, and within minutes have a fully functioning, scalable, replicated, and secure distributed database in the cloud.
US20130290249 describes systems and methods for managing asynchronous replication in a distributed database environment, while providing for scaling of the distributed database. By the solution described in this publication, a cluster of nodes is assigned with roles for managing partitions of data within the database and processing database requests. Each cluster may include a node with a primary role to process write operations and mange asynchronous replication of the operations to at least one secondary node. Each cluster or set of nodes can host one or more partitions of database data. Collectively, the cluster or set of nodes define a shard cluster that hosts all the data of the distributed database. Each shard cluster, individual nodes, or sets of nodes can be configured to manage the size of any hosted partitions, splitting database partitions, migrating partitions, and/or managing expansion of shard clusters to encompass new systems.
The present disclosure provides a new solution that provides a high performance, agile database system.
SUMMARY
The disclosure may be summarized by referring to the appended claims.
It is an object of the present disclosure to provide a novel storage system that comprises a thin, high performance database server.
It is another object of the present disclosure to provide a novel storage system that comprises a new DBLC logic configured to compile data scheme to the low-level server operations, with precompiled data such as shard ID.
It is another object of the present disclosure to provide a novel storage system wherein the main logic of the system resides at the client side.
It is another object of the present disclosure to provide a novel storage system wherein clients are configured to implement only features which are currently needed to be carried out.
Other objects of the present disclosure will become apparent from the following description.
According to a first embodiment of the present disclosure there is provided a distributed data storage system comprising:
a database server adapted to store key values associated with data being data that belong to a plurality of data types; and
wherein said distributed data storage system is characterized by having a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.
In other words, the proposed system comprises a database server that provides a set of low level, very high-performance operations while enabling the use of different data types.
Because the querying and database logic is implemented close to the data source (i.e., at the client side), optimizations that would otherwise be impossible in current implementations known in the art, become possible. Thereby, allowing higher end-to-end performance and agile feature development without performance degradation over time.
According to another embodiment, the at least one data type is a member of a group that consists of: a hash map, a sorted set, a list, a binary search tree (BST), and the like.
In accordance with another embodiment, the data scheme comprises information that relates to at least one of: data types, data relations, if and how data should be indexed, and other applicable metadata.
These data types are used by client platforms to implement both data storing (using the appropriate data type) and indexing. This is analogous to a CPU and compilers: the CPU (analogous to the database server) provides basic operations, while the compilers (which are analogous to client platforms) are configured to compile complex application logic for those low-level operations.
In addition, runtime flags may enable additional flexibility to enforce non-indexed data stores, or query data directly without having to check the index (e.g., if the exact key of the data entry is known).
By yet another embodiment, the database logic compiler (DBLC) is configured to calculate a shard ID for each data entry during compilation.
According to still another embodiment, all related data entries are stored on a single shard, while unrelated data may be stored on a different shard.
Implementing this embodiment, allows simple horizontal and vertical expansion (an instance wherein the database server is spanned at the same host to obtain horizontal growth, and to another server to obtain a vertical expansion).
In accordance with yet another embodiment, periodic functions that are required to maintain the database server are implemented by an additional computing platform.
Preferably, the periodic functions required to maintain the database server such as, for example, cleanups, or any other periodic function are implemented by an additional computing platform (i.e., one which operates as another client not included in the database server), to maintain the database server as thin and as fast as possible.
BRIEF DESCRIPTION OF DRAWINGS
The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate several embodiments of the disclosure and, together with the description, serve to explain the principles of the embodiments disclosed herein.
FIG. 1 illustrates an example of a DBLC compilation construed in accordance with an embodiment of the present invention; and
FIG. 2 demonstrates an example of a distributed data storage system construed in accordance with an embodiment of the present invention.
DESCRIPTION OF EXEMPLARY EMBODIMENTS
Some of the specific details and values in the following detailed description refer to certain examples of the disclosure. However, this description is provided only by way of example and is not intended to limit the scope of the invention in any way. As will be appreciated by those skilled in the art, the claimed system may be implemented by using other methods that are known in the art per se. In addition, the described embodiments comprise different steps that are carried out, not all of which are required in all embodiments of the invention. The scope of the invention can be summarized by referring to the appended claims.
One of the underlying principles of the present disclosure is that distributed database storage system comprises a thin, high performance database server that enables a set of low level, very high-performance operations, therefore since the querying and database logic is implemented at the client side, it becomes possible to optimize operations that need to be carried out.
FIG. 1 illustrates an example of a DBLC compilation in accordance with an embodiment of the present invention. According to this example, a client platform (not shown in this figure) is configured to implement compilation of its respective data scheme (100) by a database logic compiler (DBLC) (110) into an object relational mapping (ORM) (120), to enable obtaining a static part of that respective client platform. As may be seen in this figure, the right indexes are selected for the data-model. It should be noted that the entity "car" is provided with a different shard ID, 1, than the shard ID, 0, of the "group" entity or the "person" entity included at the same ORM (120). By using the present invention, it becomes possible to implement this option because the different shard may be used in the data scheme, independently. This compile time decision allows to send data to the right shard in the cluster directly from the client, as opposed to common implementations in which shard ID is computed at runtime and then the data is redirected to the right shard in the cluster. The example serves to demonstrate how compile time decisions/optimizations may be affected in order to improve performance.
FIG. 2 demonstrates an example of a distributed data storage system (200) construed in accordance with an embodiment of the present invention, presenting among others the static and dynamic parts thereof.
Distributed data storage system (200) shown in this example comprises a client platform (210) (other client platforms are not shown in this figure) and a thin database server (220).
Client platform (210) comprises two main parts, a dynamic part (212) at which runtime operations are carried out base on information received from user application (214). The other main part is a static part, ORM (216), which is based on information received from a corresponding data scheme (218). The system operates by conveying low-level commands from client platform (210) to database server (220) and receiving the respective responses from that server.
Now, let us consider an example where a client creats a "Person" entity (see FIG. 1) with the name “Alice”. The following procedure may be implemented. First “Alice" will be added to index “/person”, and then “Alice” Person entity will be added to key-value storage. These low-level instructions are generated using the static part. However, a client may add a flag so that only adding of a Person entity to the key-value storage, will be affected without manipulating the index. Preferably, this is done if the client is sure that the index has already been created, and data only needs to be updated. Adopting such a method is effective in improving performance quite dramatically.
The present invention has been described using detailed descriptions of embodiments thereof that are provided by way of example and are not intended to limit the scope of the invention in any way. The described embodiments comprise different features, not all of which are required in all embodiments of the invention. Some embodiments of the present invention utilize only some of the features or possible combinations of the features. Variations of embodiments of the present invention that are described and embodiments of the present invention comprising different combinations of features noted in the described embodiments will occur to persons of the art. The scope of the invention is limited only by the following claims.
CLAIMS
1. A distributed data storage system comprising:
a database server adapted to store key values associated with a plurality of data types; and
wherein said distributed data storage system is characterized by having a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.
2. The distributed data storage system of claim 1, wherein the at least one data type is a member of a group that consists of: a hash map, a sorted set, a list, a binary search tree (BST).
3. The distributed data storage system of claim 1, wherein the data scheme comprises information that relates to at least one of: data types, data relations, if and how data should be indexed.
4. The distributed data storage system of claim 1, wherein the database logic compiler (DBLC) is configured to calculate a shard ID for each data entry during compilation.
5. The distributed data storage system of claim 3, wherein all related data entries are stored on a single shard, while unrelated data may be stored on a different shard.
6. The distributed data storage system of claim 1, wherein periodic functions required to maintain the database server are implemented by an additional computing platform.
1. A distributed data storage system comprising:
a database server adapted to store key values associated with a plurality of data types; and
wherein said distributed data storage system is characterized by having a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.
2. The distributed data storage system of claim 1, wherein the at least one data type is a member of a group that consists of: a hash map, a sorted set, a list, a binary search tree (BST).
3. The distributed data storage system of claim 1, wherein the data scheme comprises information that relates to at least one of: data types, data relations, if and how data should be indexed.
4. The distributed data storage system of claim 1, wherein the database logic compiler (DBLC) is configured to calculate a shard ID for each data entry during compilation.
5. The distributed data storage system of claim 3, wherein all related data entries are stored on a single shard, while unrelated data may be stored on a different shard.
6. The distributed data storage system of claim 1, wherein periodic functions required to maintain the database server are implemented by an additional computing platform.
ABSTRACT
A distributed data storage system is provided. The system comprises: a database server adapted to store key values associated with a plurality of data types; and a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.
A distributed data storage system is provided. The system comprises: a database server adapted to store key values associated with a plurality of data types; and a plurality of client platforms, each adapted to store data of at least one data type and to store indexing information, and wherein each of the plurality of client platforms is configured to implement compilation of its respective data scheme by a database logic compiler (DBLC) into an object relational mapping (ORM), to enable obtaining a static part of that respective client platform.