私のチームは、外部キー関係を持つリレーショナルデータベースエンティティを怖がっており、その理由がわかりません
私は比較的大学を卒業していないので、リレーショナルデータベースに精通していることのほとんどは、BCNFまたは3NFにないものは茶番である私のデータベースコースの出身です。確かにそれは極端な一端ですが、私の職場のチームは本当にそれを完全に反対の端に持って行っているようです。
マイクロサービスのdbスキーマでは、エンティティが複数のテーブルを持つことはほとんどありません。通常、別のテーブルに正規化するものはすべてjson列に格納されます。このjsonのプロパティの1つをクエリする必要があることが後で判明した場合、新しい列が追加され、データが両方の場所（同じテーブルの2つの異なる列）に保存されます。
多くの場合、これらのjson列には間違いなく利点があります。そのデータに対してクエリを実行する必要がなく、そのデータに一方的な変更を加える必要がない場合（これは明らかに予測できないことです）、それは悪い考えではありません。さらに、私たちのサービスの多くはサーバーを認識しないか、必要なディスク領域がわいせつなマシンでホストされているため、データの重複は大きな問題ではありません。 （私は一般的に哲学からは避けたいものですが）
現在、私たちは、所有する一連の条件に基づいてルールに一致するサービスを構築しており、ルールが真（たとえば、すべての条件が真）のときに、それらのルールに関連付けられた一連のアクションを実行します。このサービスをすぐに構築している私のサブチームは、スキーマ内のルールから離れてアクションと条件を正規化することには大きなメリットがあると信じています。明らかにこれらのテーブルは、ルールIDとの外部キー関係を維持しています。私たちの観点からは、条件のデータの重複を回避できるため、条件が一度だけ評価されることを保証でき、必要なときに必要な条件とルールを簡単に見つけることができます。すべてのルールを引き出してメモリ内で検索する必要はありません。
今日、私たちの主要なエンジニアの1人と話していると、彼はこのスキーマから遠く離れて私をプッシュしようとしました。私たちが実際にそれを必要としないというあらゆる方法で主張しようとすると、将来的にパフォーマンスの問題が発生するようになり、私たちが所有する古い設計のモノリスを参照します。彼は私たちがやっていることを「古い方法」と呼び、jsonを使用したフラットテーブルを「新しい方法」と呼びました。彼は、私が原子性を必要とする場所ではそれを必要とせず、クエリの代わりにメモリ内でより多くのことをすべきだと主張しました。これは、私たちのサービスの多くが現在従う設計原則です。データ量が大幅に増加してクエリを迅速に維持できるとは予想していません。予想されるのは、ルールの評価とアクションの実行に費やされる多くの時間です。できるだけ多くの負担をSQLに移すことは理にかなっています。
非リレーショナルデータベースが近年人気を博していることは理解していますが、外部キー関係のパフォーマンスへの影響に関する情報を積極的に検索している場合でも、彼の主張を裏付ける情報は多くありません。問題を引き起こす可能性のある大きなトランザクションを導入する傾向があると思いますが、それは外部キー自体とは関係のない問題のようです。
これは私の初心者ですか？または、これは本当に私と私のサブチームが欠けているものですか？私は必ずしもその解決策を探しているわけではないので、問題の詳細情報を明示的に提供していません。それが私たちの大規模なチームの一般的な傾向であることを考えると、彼らがこれで何かをしているのかどうか本当に知りたいです。
ここであなたのチームがどこから来ているのかを理解するためのキーワードは「マイクロサービス」です。特に次の情報については、最初にその概念について読む価値があります。
- データはどのように保存すべきですか？
- 設計原則？
- それらはどのようにスケーリングするように設計されていますか？
物事を行うための比較的新しい方法と同様に（ソフトウェアアーキテクチャに関しては5〜10年は比較的新しい）、理想と現実は少し異なることがわかります。
理想の1つは、すべてのマイクロサービスが独自のデータストアを持つ必要があることです。 注：私はデータベースではなく、データストアと言いました。通常のデータベースではなく、単に検索エンジン、BLOBストレージ、または単純なキャッシュが必要な場合があります。話し相手によっては、その理想はマイクロサービスインスタンスごとにデータストアに行くことさえあるかもしれません！
結論としては、インターネットスケールへの移行について話しているとき、1つのデータベースに数百万のユーザーがいる場合、ACID（原子性、一貫性、分離、および耐久性）トランザクションの安全性と親しみやすさはスケーリングされません。 NoSQLの出現により、パラダイムはBASE（基本的に利用可能、ソフト状態、結果整合性）によりシフトしました。 （ 参照 ）
データの管理方法のPHを変更すると、次のような影響があります。
- データベースがあなたに代わって処理していたものは、コードで管理する必要があります
- サーバーに「無限」リソースを追加するよりも、問題に対してより多くのマイクロサービスインスタンスをスローする方が、スケーリングが簡単です。
- 複雑さが増す代わりに、信頼性が向上します
あなたのチームの詳細や、彼らがソリューションを取得することを意図している大きさについて答えることはできませんが、通常、あなたはオールオアナッシングソリューションを持っている必要はありません。ここに座って、チームが正しい選択をしているかどうかを判断するつもりはありません。私はあなたにいくつかのコンテキストを提供しているだけなので、少なくともそれらがどこから来ているのか理解できます。
OK、プロジェクトの主任エンジニアではないので、このプロジェクトの彼の指示に従う必要があります。
トレードオフを理解できるように、システムの独自の設計とプロトタイプを自宅で作成することをお勧めします。これはあなた自身の教育のために行い、実際に動作する例を示すことができるときにのみ職場で言及してください。
私の経験では、制約によりデータベースのパフォーマンスが低下するという主張があります。そして、そうです、それらの制約をチェックする必要があります。ただし、データベースに一貫性がない場合ははるかに大きな問題であり、これにより、SQLとより多くのコードを記述して補正する必要があり、システムの複雑さが増すだけでなく、速度が低下します。
3nfを適切に実行すると、保存される冗長データが少なくなるため、データベースの多くをキャッシュできるため、データベースが高速になります。ただし、現在のジョブでは、正規化されたデータベースと正規化されていないデータベースのパフォーマンスの違いを実際に確認するのに十分な大きさのデータセットがない場合があります。
参照整合性そのものではなく、以前と同じ古い「裏切り」を再作成するのが怖いのではないでしょうか。
彼は、私が原子性を必要とする場所では、それを必要としないと主張しました...
アトミック性を必要とするために確かなケース（別名、機能以外の要件）を作成できる場合は、提供から抜け出すために、適切で堅固な反論が必要になります。
...クエリの代わりに、メモリ内でより多くのことを行う必要があります。これは設計原則です...データ量が大幅に増えるとは予想していません...
Let's hopeそうです。パフォーマンスを維持するために「十分に小さい」データのままにすることはリスクを伴うことをお勧めします。
また、これらのルールの変化率はどのくらいですか？重複が多いほど、複数の場所で同じものを更新するのに多くの時間（別名：お金）が無駄になります。
RDBMSの背後にある主要な概念は、40年以上前のものです。当時、ストレージは非常に高価であり、あらゆる種類の冗長性が嫌われていました。 RDBMSの背後にある概念はまだ健全ですが、パフォーマンスを非正規化（結合を減らすため）するという考えは、ここ数十年で一般的に受け入れられるようになりました。
したがって、特定のサイズのRDBMSの場合、通常、パフォーマンスのために論理設計（冗長性なし）と物理設計（冗長性あり）があります。
ストレージが安価でプロセッサがかつてないほど高速になっている今日に早送りしますが、設計上のプレッシャーの一部はそれほど重要ではありません。結局、それはあなたが冗長性と孤立したレコードについてあなたがcareかどうかに関する判断の呼びかけです。銀行業務などの一部の業界では、データの正確性が不可欠であるため、RDBMSからどのように移行するかを確認することは困難です。他の業界では、新しいプレーヤーが常に市場に参入しているため、選択肢は無数にあります。
あなたのチームがRDBMSがもたらす制限に不快であるかどうかについては-誰が知っていますか？確かに私が目にするジュニア開発者は、前世代の開発者が持っていたRDBMSのようなものを持っていませんが、これはおそらく、開発者テクノロジーとデータベースプラットフォームの急増に関係しています。
開発者が学ぶことができるテクノロジーの終わりはなく、あなたのキャリアに適切なパントを作ることは難しい場合があります。確かに、開発者がすべての取引のジャックであった時代は過ぎ去りました-学ぶことができることが多すぎます。
しかし-手元の質問に。あなた自身の許可により、あなたはデータ量が増えることを期待せず、システムはうまく機能しています。知覚できる利益なしに物事をリエンジニアリングするというアイデアを売るのは、あなたにとってかなりのストレッチです。おそらく、RDBMSアプローチdidがメリットを享受するという概念実証を行うことができれば、それは別の話になるでしょう。
使用しているデータベースによって異なります。
従来のRDBMSでは、そのとおりです。データの複製は嫌なものです。列とそれらのjsonの等価性は、強制するものがないため、必然的に非同期になります。外部キーのサポートはよく知られており、関係の説明と実施において素晴らしい仕事をします。そして、原子性は、データを使用してほとんどすべてを行うために不可欠です。
Nosqlの種類の設定では、それほど明確ではありません。しっかりとした関係がないので、関係の執行はそれほど重要ではなくなります。列インデックスを使用したこのようなjsonコンテンツは、これらのシステムでより一般的です。これは、関係がないということは、非同期になる可能性が低いためです。そして、原子性は単一のテーブルに制限されています。これは、このようにしてnosqlが機能するためです。
どちらが良いかは、実際に何をしているか、そして実際に何が必要かによって異なります。
しかし、あなたの同僚は貨物カルトにいるように聞こえます。彼らは古い悪いものに噛まれたので、今は新しい光沢のあるものである必要があります。数年後、彼らが新しい光沢のあるものに噛まれたら、SQLとnoSQLがトレードオフのセットであることを彼らはうまくいけば理解するでしょう。
しかし、彼らはしません。うまくいけば、あなたはそうします。