たとえば、Google App Engine は標準データベースではなく Google Datastore を使用してデータを保存します。データベースの代わりに Google Datastore を使用するためのヒントはありますか? テーブル構造に直接マップされるオブジェクトの関係を 100% 考えるように頭を鍛えたようで、今では何も違うものを見るのは難しいです。Google Datastore の利点の一部 (パフォーマンスやデータ分散機能など) は理解できますが、一部の優れたデータベース機能 (結合など) が犠牲になります。
Google Datastore または BigTable を使用したことがある方で、それらを使用する上で何か良いアドバイスはありますか?
「従来の」リレーショナル データベースと比較した場合、App Engine データストアについて慣れる必要がある主な点が 2 つあります。
理解すべき重要な点 (およびこれらの違いの背後にある理由) は、Bigtable が基本的に巨大な順序付けられた辞書のように機能することです。したがって、プット操作は、そのキーの以前の値に関係なく、特定のキーの値を設定するだけであり、フェッチ操作は単一のキーまたは連続した範囲のキーのフェッチに制限されます。インデックスを使用すると、より高度なクエリが可能になります。インデックスは、基本的には独自のテーブルであり、連続した範囲でのスキャンとしてより複雑なクエリを実装できます。
それを理解すると、データストアの機能と制限を理解するために必要な基本的な知識が得られます。恣意的に思えるかもしれない制限は、おそらくもっと理にかなっています。
ここで重要なことは、これらはリレーショナル データベースでできることに対する制限ですが、Bigtable が処理するように設計されている規模までスケールアップすることが実際的である理由は、これらと同じ制限であるということです。紙の上では良さそうに見えても、SQL データベースでは非常に遅いようなクエリを実行することはできません。
データの表現方法をどう変えるかという点で、最も重要なのは事前計算です。クエリ時に結合を行う代わりに、データを事前に計算し、可能な限りデータストアに保存します。ランダムなレコードを選択する場合は、乱数を生成して各レコードに保存します。この種のヒントとコツをまとめたクックブックがここにあります。
私がマインドスイッチについて行ってきた方法は、データベースを完全に忘れることです.
リレーショナル データベースの世界では、常にデータの正規化とテーブル構造について心配する必要があります。それをすべて捨ててください。Web ページをレイアウトするだけです。それらをすべて並べます。今それらを見てください。すでに 2/3 に達しています。
データベースのサイズが重要であり、データを複製してはならないという考えを忘れているとしたら、4 分の 3 ということになり、コードを書く必要さえありません! ビューにモデルを指示させます。リレーショナルの世界のように、オブジェクトを 2 次元にする必要はありません。形状のあるオブジェクトを格納できるようになりました。
はい、これは試練の簡単な説明ですが、データベースを忘れてアプリケーションを作成するのに役立ちました。私はこれまでにこの哲学を使って 4 つの App Engine アプリを作成しました。
人々が出てくるとき、私はいつも笑います-それは関係性ではありません. 私は django で cellectr を作成しました。以下に私のモデルのスニペットを示します。ご覧のとおり、ユーザーによって管理または指導されるリーグがあります。リーグからすべてのマネージャーを取得するか、特定のユーザーから、彼女がコーチまたはマネージャーを務めるリーグを返すことができます。
特定の外部キーのサポートがないからといって、リレーションシップを持つデータベース モデルを使用できないわけではありません。
私の2ペンス。
class League(BaseModel):
name = db.StringProperty()
managers = db.ListProperty(db.Key) #all the users who can view/edit this league
coaches = db.ListProperty(db.Key) #all the users who are able to view this league
def get_managers(self):
# This returns the models themselves, not just the keys that are stored in teams
return UserPrefs.get(self.managers)
def get_coaches(self):
# This returns the models themselves, not just the keys that are stored in teams
return UserPrefs.get(self.coaches)
def __str__(self):
return self.name
# Need to delete all the associated games, teams and players
def delete(self):
for player in self.leagues_players:
player.delete()
for game in self.leagues_games:
game.delete()
for team in self.leagues_teams:
team.delete()
super(League, self).delete()
class UserPrefs(db.Model):
user = db.UserProperty()
league_ref = db.ReferenceProperty(reference_class=League,
collection_name='users') #league the users are managing
def __str__(self):
return self.user.nickname
# many-to-many relationship, a user can coach many leagues, a league can be
# coached by many users
@property
def managing(self):
return League.gql('WHERE managers = :1', self.key())
@property
def coaching(self):
return League.gql('WHERE coaches = :1', self.key())
# remove all references to me when I'm deleted
def delete(self):
for manager in self.managing:
manager.managers.remove(self.key())
manager.put()
for coach in self.managing:
coach.coaches.remove(self.key())
coaches.put()
super(UserPrefs, self).delete()
私はリレーショナル データベースの世界から来て、このデータストアのことを見つけました。コツをつかむのに数日かかりました。さて、私の発見のいくつかがあります。
Datastore はスケーリングするように構築されており、それが RDMBS との違いであることを既にご存じのはずです。大規模なデータセットでより適切にスケーリングするために、App Engine はいくつかの変更を行いました (いくつかの変更は多くの変更を意味します)。
RDBMS VS DataStore
構造
データベースでは、通常、データをテーブル、データストアにある行で構造化し、種類とエンティティになります。
関係
RDBMS では、ほとんどの人が 1 対 1、多対 1、多対多の関係に従います。データストアでは、「結合なし」であるため、「ReferencePropertyを使用して正規化を達成できます。 " 例: 1 対 1 の関係の例.
インデックス
通常、RDMBS では、主キー、外部キー、一意のキー、インデックス キーなどのインデックスを作成して、検索を高速化し、データベースのパフォーマンスを向上させます。データストアでは、種類ごとに少なくとも 1 つのインデックスを作成する必要があります (好むと好まざるとにかかわらず、自動的に生成されます)。データストアはこれらのインデックスに基づいてエンティティを検索し、それが最良の部分であると信じています。RDBMS では、次を使用して検索できます。しばらく時間がかかりますが、そうなるでしょう。Datastore では、非インデックス プロパティを使用して検索することはできません。
カウント
RDMBS ではカウントする方がはるかに簡単ですが(*)、データストアでは、1000 制限があり、エンティティと同じくらい小さな操作のコストがかかるため、通常の方法で考えることさえしないでください (カウント機能があります)。は良くありませんが、常に良い選択肢があります。シャード カウンターを使用できます。
Unique Constraints
RDMBS では、この機能が気に入っていますよね? しかし、データストアには独自の方法があります。プロパティを一意として定義することはできません:(。
Query
GAE Datatore は、GQLである SQL (データストアにはLIKEキーワードがありません) と同じくらい優れた機能を提供します。
データの挿入/更新/削除/選択
RDMBS では、RDBMS と同じように、挿入、更新、削除、選択に 1 つのクエリが必要です。書き込み、読み取り、小規模な操作(データストア呼び出しの読み取りコスト) に関するput または get であり、データ モデリングが機能する場所です。これらの操作を最小限に抑え、アプリを実行し続ける必要があります。読み取り操作を減らすには、 Memcacheを使用できます。
Objectify のドキュメントを参照してください。ページの下部にある最初のコメントには次のように書かれています。
「いいですね。あなたは Objectify を説明するためにこれを書きましたが、これは私が今まで読んだ appengine データストア自体の最も簡潔な説明の 1 つでもあります。ありがとうございます。」
ORM マップ エンティティについて考えるのに慣れている場合は、Google の App Engine のようなエンティティ ベースのデータストアが基本的にどのように機能するかを理解できます。結合のようなものについては、参照プロパティを見ることができます。バックエンドは GQL と Datastore API インターフェースによって抽象化されているため、バックエンドに BigTable を使用するか、それ以外の何かを使用するかどうかを気にする必要はありません。
私がデータストアを見る方法は、種類はテーブル自体を識別し、エンティティはテーブル内の個々の行です。Google が構造のない 1 つの大きなテーブルよりも種類を取り出した場合、エンティティに必要なものを何でもダンプできます。言い換えれば、エンティティが種類に関連付けられていない場合、エンティティに任意の構造を持たせ、1 つの場所に格納することができます (構造のない大きなファイルのようなもので、各行には独自の構造があります)。
元のコメントに戻りますが、Google データストアと bigtable は 2 つの異なるものであるため、Google データストアをデータストア データ ストレージの意味と混同しないでください。Bigtable は bigquery よりも高価です (使用しなかった主な理由)。Bigquery には適切な結合があり、SQL 言語のような RDBMS があり、安価なので、bigquery を使用しないでください。そうは言っても、bigquery にはいくつかの制限があり、データのサイズに応じて、遭遇する場合と遭遇しない場合があります。
また、データストアの観点から考えると、「NoSQLデータベースの観点から考える」という表現が適切だったと思います。最近は利用できるものが多すぎますが、Google クラウド SQL (mySQL) 以外の Google 製品に関しては、それ以外はすべて NoSQL です。
データベースの世界にルーツを持つ私にとって、データ ストアは巨大なテーブルです (そのため、"bigtable" という名前が付けられました)。BigTable は悪い例ですが、通常のデータベースでは実行できない他の多くのことを実行しますが、それでもデータベースであることに変わりはありません。おそらく、Google の「bigtable」のようなものを構築する必要があることを認識していない限り、標準的なデータベースで問題ないでしょう。彼らは非常に大量のデータとシステムを一緒に処理しているため、それが必要であり、商業的に入手可能なシステムは、彼らが仕事をする必要があることを示すことができる正確な方法で実際に仕事をすることはできません.
(bigtable 参照: http://en.wikipedia.org/wiki/BigTable )