巨大なデータベースを操作しているときに、どのような特定の問題/解決策/アドバイス/ベストプラクティス[言葉で私を罰しないでください]が発生しているのか知りたいです。
巨大な下では、数百万行のテーブルやペタバイトのデータを含むデータベースを含むデータベースを意味します。
プラットフォーム指向の答えも素晴らしいでしょう。
巨大なデータベースを操作しているときに、どのような特定の問題/解決策/アドバイス/ベストプラクティス[言葉で私を罰しないでください]が発生しているのか知りたいです。
巨大な下では、数百万行のテーブルやペタバイトのデータを含むデータベースを含むデータベースを意味します。
プラットフォーム指向の答えも素晴らしいでしょう。
いくつかのアイデア
特定のデータベースエンジンの詳細、その仕組みを学ぶ
クエリを最適化する方法(ヒント、実行プラン)
データベースを調整する方法(インデックスだけでなく、物理ストレージと表現、OS統合)。
再利用可能な一時的な結果を保存するために、一時的なテーブルのような「トリック」をクエリします。
パフォーマンス改善のための非正規化の必要性を評価する方法
データベースのプロファイリングツールを使用して、ボトルネックを特定する方法。
本番DBAからのいくつかのアドバイス(私の経験はMS SQLですが、これらは他のプラットフォームにも当てはまるはずです):
メンテナンスは重大な問題になります(毎晩のバックアップ、DBCC、毎週の再インデックス/最適化ジョブなど)。妥当な夜間または週末のメンテナンスウィンドウを超えて開始するのは非常に簡単です。これは技術的な問題だけでなく、ビジネス上の問題でもあります(「どういう意味ですか、最後の適切なバックアップからデータベースを復元するには4時間かかりますか?」)
開発者は、別の方法で作業する必要があるかもしれないことを理解する必要があります。「あなたは私がそれがうまくDELETE (500m rows) FROM MassiveTable
いくと期待することができないということですか?
もっと考えてみようと思います...
私の最初のアドバイスは、彼らが何をしているのかを知っていて、SOに依存しない人を雇うことです。そうしないと、非常に高額なミスを犯す可能性があります。2つ目は、適切なプラットフォームのハードウェアとソフトウェアを選択することです。詳細は要件によって大きく異なります。
SQLアンチパターンに関するこのプレゼンテーションを読むことを強くお勧めします http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
プレゼンテーションは、一見行き詰まった状況の解決策を見つけるのに役立ちます(はい、それは私を大いに助けました)。
データベースには、設計と管理に関する限り、サイズよりも重要な2つの側面があります。
1つ目は複雑さです。ユーザーテーブルはいくつありますか?それらのテーブルにはいくつの列がありますか?スキーマに数百のユーザーテーブルがあり、それらのテーブルに1,000を超える列があるデータベースは非常に複雑です。ペタバイトのデータが含まれている場合でも、5ダースのテーブルを持つデータベースはそれほど複雑ではありません。
2つ目は、データ共有の範囲です。別々のプログラミングチームによって開発された6つ以上のアプリケーション間でデータを共有するようにデータベースが構築されている場合は、単一のアプリケーションに組み込まれているデータベースとはまったく異なる方法でデータベースを設計および管理する必要があります。
SOで尋ねられるデータベースの質問のほとんどは、単一のアプリケーションデータベースに関するものです。
すでに述べたことに加えて、学ぶべきことがいくつかあります。
テーブルパーティションとテーブル分解の違いを学びます。一部の人々は、パーティション化がより適切に機能する場合、テーブルをすべて同じ列を持つ複数のテーブルに分解します。
データのグラフモデルとデータのリレーショナルモデルの本当の違いを学びましょう。一部の人々は、外部キーが本質的にポインタと同じであるかのようにデータベースを設計します。最終的には、リレーショナルシステムのすべての遅さとグラフシステムのすべての管理不能性をキャプチャするシステムになります。
(注:グラフモデルは、階層モデルまたはネットワークモデルと呼ばれることがよくあります)。
実際のリレーショナルデータベースを設計することは、リレーショナルにモデル化されているように見せかけるが実際にはグラフモデル化されているデータベースを設計するよりもはるかに微妙で価値があります。
RDBMSが非常に大きくなると、特に複雑な結合条件が使用されている場合に、パフォーマンスが低下する可能性があります。データベーススキーマも、大量のトラフィックに対応できるように設計する必要があります。ほとんどのシステムは負荷の処理に非常に優れていますが、複数のマシンに分散する必要がある1つのデータベースがある場合にも問題が発生する可能性があります。
データベースのスケーラビリティに対処するために、多くの新しいツールが登場しています。最も有望なものの1つはMemcachedです。これは、大量のデータをメモリに保存します。これにより、はるかに高速なアクセスが可能になり、複数のデータベースサーバー間の同期が容易になります。スキーマを適用しないアーキテクチャで従来のSQLシステムを強化するNoSQLソリューションの一部。
NoSQLテクノロジーの例としては、Cassandra、CouchDB、Google BigTable、MongoDBがあります。一部の人々は、これらのシステムが「来たるべきデータの爆発的増加」を管理する上で重要になると誓います。