1

Google Cloud SQL と Google Datastore でホストする必要があるグローバル ERP / スケジューリング システムを設計しています。

ほとんどの場合、データは強力なリレーショナルであり、ボリュームや揮発性が大きくないため、リレーショナル データベースに自然に適合します。

現在の設計では、customer、contract、employee、site、workorder、contractedSites テーブルにローカルに保存されたアドレスがあります。合計で約 12 の異なる場所です。私は DEV チームに設計を変更して、他のすべてのエンティティから参照できる ADDRESS テーブルを作成するように依頼しました (アドレス履歴、複数のアドレスなどに柔軟性を提供するために、必要に応じてテーブルをリンクして)。

質問 - 住所/連絡先の詳細形式は、これらすべてのシナリオ、国や複数の電話番号などで大きく異なるため、住所と連絡先の詳細をデータストアに移動し、Cloud SQL プラットフォームの ID で参照する必要があると考えていました。そのため、構造は完全に柔軟で、世界中の住所形式に対応できます。

これは理にかなっているように聞こえますか、それともソリ​​ューションのエンジニアリングが過剰であり、CLoud SQL でのみ一般的なアドレス テーブルを使用する必要がありますか?

Google プラットフォームのボトルネックは単一の MySQL マスターにあるように見えるため、懸念があります。これは 16 個の vCPU に制限されたマネージド サービスであるため、より多くの機能領域をデータストアに移動しようとしています。

それが理にかなっていることを願っています！

4

1 に答える 1

1

あなたは確かにそれを行うことができ、混合データベース システムを実行する最初の人ではないでしょう。ただし、複雑さが増します。その道を進む前に、考慮すべきことがいくつかあります。

  • あなたは 16 個の vCPU 制限について言及しています - Cloud Datastore はより簡単にスケーリングできますが (私たちがあなたのためにそれを行います)、アドレスがこれについて心配する理由になるとは考えにくいです。

  • より多様なスキーマ要件を持つデータの場合、すでに Could SQL を使用しているため、JSON タイプを使用してデータを格納できます。Cloud SQL Second Gen を使用している限り。

  • トランザクション: Cloud SQL と Cloud Datastore の両方のデータに関係するオペレーションをトランザクション対応にする必要がある場合は、それを自分で実装する必要があります。潜在的な不一致やクリーンアップに耐えることができれば、問題ありません。

  • Cloud Datastore を使用すると、このタイプのデータを格納し、大規模かつ効率的にクエリを実行するための柔軟性が大幅に向上します。それは、優れたユースケースです。

于 2016-06-09T17:14:20.913 に答える