4

私たちは、（できれば）数千の顧客をサポートする新しいプロジェクトに着手しようとしているので、アーキテクチャを検討しています。アプリケーションの重要な側面の 1 つは、複数の言語 (英語、スペイン語など、言語の数に制限はありません) のサポートです。これは従来の RDBMS (Sql Server、Oracle など) のモデル化に多くの経験がありますが、NoSQL の「モデル化」に関しては苦労しています。SQL モデルでは、すべての異なる言語を含む「言語」テーブルを指す「言語」列を持つ「テキスト」テーブルを作成します。これにより、すべてのテキストをサポートされているすべての言語で表すことができます。簡単な例を考えてみましょう:

表: カテゴリ列: id (PK)、Enabled (Bool)

表: Category_Descriptions 列: id (PK)、CategoryID (FK)、LanguageID (FK)、説明 (テキスト)

表: 言語の列: id (PK)、Enabled (Bool)

表: Language_Descriptions 列: id (PK)、DescriptionLanguageID (FK)、LanguageID (FK)、Description (Text)

したがって、すべての言語が Language テーブルに格納され、対応する説明が Language_Descriptions テーブルに格納されます。さらに、すべてのカテゴリが Category テーブルに格納され、すべての言語の説明が Category_Descriptions テーブルに格納されます。特定の言語 (英語 = 1) のすべてのカテゴリを取得するには、次のようにします。

select c.id, cd.Description 
from   Category c, Category_Descriptions cd 
where  c.id = cd.CategoryID 
and    c.Enabled = 1;

もちろん、カテゴリはそれ自体ではあまり役に立ちません。インシデント レポートなど、別のエンティティの一部になります。

表: インシデントの列: ID (PK)、Created (日付)、CategoryID (FK) など。

このテーブルから情報を取得するには、前と同じ結合を行い、正しい言語の説明列を選択します。基本的なことは、これまでに行ったことがある...

最後に、私の質問にたどり着きます。これを NoSQL データベースに適切に保存するにはどうすればよいでしょうか。:)

私はいくつかの（悪い）解決策を見てきました：

  1. コードのみを保存し、正しい説明ランタイムを検索します
  2. 最後に使用した説明を言語コードとともに保存し、言語が変更された場合は更新します (別のユーザー)
  3. すべての説明を同じドキュメントに保存する
  4. コードの説明をアクティブな言語で保存し、必要に応じて新しい言語に説明を追加します (つまり、未使用の言語で要求された場合)。

これらのソリューションにはすべて、かなりの数の欠点があり、実装と維持に多くの作業が必要です...したがって、これを最適に解決する方法についての意見をいただければ幸いです。

編集: NoSQL を検討している理由は 2 つあります。

  1. パフォーマンス (スケール)
  2. 動的スキーマ (SQL でこれを実現するには、多くの作業を行う必要があります)
4

2 に答える 2

3

これが尋ねられてからしばらく経ちましたが、なぜそうではないのか考えました =) ...

私の NoSQL の経験から、RDMS のバックグラウンドとデータの正規化に対する強い願望を最初に本当に忘れる必要があります。重複データがあっても大丈夫です。ものを大量に保存しても問題ありません (冗長であっても!) データが一貫していなくても問題ありません。言い換えれば、言語記述を潜在的に 5 つの場所に保存することになるため、これらの 5 つの場所が一定期間異なっていても問題ありません。

パフォーマンスと動的スキーマの名の下にこれらの譲歩を喜んで行う場合は、モデル化に役立つ可能性があります。

UI をモデルとして使用することから始めるのがよいと思います。あなたが Web 開発者で、このデータが必要な場合、何が必要ですか? 理想的には、Web 開発者が必要なものを取得するために必要な呼び出しの数を最小限に抑える必要があります。これは、文書内に入れる情報量を決定するのに役立つ場合があります。

SQL の例で、ドキュメント全体でクエリを実行する機能をほのめかしたと思います。つまり、頑張って 10 種類の文書型を作成し、おおむね順調に進んでいるのに、突然「結合」を行う必要があることに気付いた場合、問題が発生します。

NoSQL は、概念的な結合を行うのが得意ではありません。

それらのほとんどの方法は、map/reduce を使用することです。たとえば、Mongo では、本質的に結合機能を提供する map/reduce 関数を作成できます。ただし、料金は迅速に支払う必要があります。

ただし、複雑なクエリ (元のドキュメント モデルに適合しないもの) の実行を少し遅くしても構わない場合は、必要なことは何でも達成できます。

どのクエリを高速にする必要があり、どのクエリを少し遅くする必要があるかをどのように判断しますか? ここでも、UI について説明します。

また、モデリングに関する単純な試行錯誤も本当に役に立ちました。私はそれが不十分な提案であることを理解していますが、それは本当です. =)

于 2013-01-06T04:11:06.683 に答える