3

私はMySQLに慣れていて、今はキーバリューストアの使い方を理解しようとしています。私が見たことがないのは、データベース設計の例のような良いnoobと、情報を挿入して取得する方法です。DynamoDBデータベースデザイン(Key-Value Store、noSQL)

これは、キーストアにMySQLからデータを保存する方法の正しい表現ですか?

TYPE: MySQL 
TABLE: users 
COLUMNS: user_id(primary), username, location 

TYPE: Key Value Store 
TABLE: users 
KEY: user_id 
VALUES: username, location 

したがって、上記のとおりです。一般的なユーザー情報を引き出すことは、理解するのに十分簡単です。しかし、私はどのようにキー値ストアで次のクエリを実行しますか?

SELECT username FROM users WHERE location = 'mexico' 

私はあなたがこれを簡単に行うことができると思った方法は、別のテーブルを作成することです。 、

--Original Table-- 
TYPE: Key Value Store 
TABLE: users 
KEY: user_id 
VALUES: username, location 

--Additional "query" Table-- 
TYPE: Key Value Store 
TABLE: user-location 
KEY: location 
VALUES: user_id 

しかし、今、私たちは新しい誰かが参加する2つのテーブルを調整する必要があるが、その場所を更新する(あなただけの数百を持っていた場合は、これを行うには、他の方法があることを確認イム、5,000以上のユーザーがいると仮定)私が想定している大きな問題ではありません。あなたのアプリケーションのコードで超正確でなければなりません。

これは、これらの問題を解決する最善の方法ですか?または私は何かを逃していますか?

+1

通常、NoSQLのデータストアは少ない機能しか提供しません。開発者の生産性を正確に把握することはできません。 – usr

答えて

2

更新回答(月-2014)

DynamoDBのは、あなたが今の場所にインデックスを入れて、高速なものはメキシコに住んでのみ取得できることを意味Global Secondary Indicesを支援を開始。

書き込み時(これは変更される可能性があります)には、既存のテーブルにインデックスを追加できないことに注意してください。

オリジナル回答(3月-2013)全般のNoSQLに

注:
NoSQLのDBMSは、通常、拡張性に焦点を当てます。
また、通常、サーバー側のコードが増えるという点で、アプリケーションのオーバーヘッドが追加されます。

あなたはメキシコのユーザーに何回問い合わせる必要があるのでしょうか?
答えは、データベースをモデリングするときに適切な方法で指示する可能性が高いです。理由もある
は(少なくとも私の知る限り)は、「パーフェクトフィット」とノー本当に「noobのサンプル」

今特にDynamoDBのを見て、あなたは二次の贅沢を持っていないはありません(NoSQLの他のソリューションとは対照的です)、インデックスごとにテーブルを作成する必要があります。 モデルでは、ハッシュキーが場所であり、範囲キーがユーザーIDであるテーブルを作成できます。したがって、QUERY API呼び出しを使用すると、すべてのMEXICOユーザーを取得できます。

また、DynamoDBでは64KBのオブジェクトしか使用できないため、IDを1つのオブジェクトに連結しておくなどの他の実装も考えられます。ここではスケーリングの問題に遭遇するでしょう。

+0

古くなった答えでは、新しいグローバルセカンダリインデックス機能を使用してください。 –

+0

@DanielSteigerwaldに感謝します。新しいGSI機能を反映するように更新しました。 –

1

YouTubeの最近のビデオは、この質問に対する良い答えです。 10分ほど前に、DynamoDBの使用の詳細について話が始まります。しかし、ビデオ全体は、もっと知りたい人にとっては良いことです。

ウェビナー:アマゾンダイナモDB -

0

デザインは、このような場合にはhttp://youtu.be/meBjA68DeIUあなたは、あなたはレンジキーとしてハッシュキーとのuserIdなどの場所でのユーザーテーブルを再設計する必要があります場所に基づいて検索をたくさんやってしまうこと。 しかし、上記のやり方では、新しいユーザーを挿入する際にuserIDの一意性をチェックすることはできません(MySqlの主キーとは対照的です)。

ここで、場所に基づいて頻繁に検索しないと、スキャン操作を実行する方が良い解決策かもしれません。

あなたが必要とするAPIレベルでこれらの処理をすべて行うには、最善の方法があります。

1

自分で別のインデックステーブルを管理しないでください。

代わりに新しいglobal secondary index機能を使用してください。

関連する問題