0

これは一般的な質問に聞こえるかもしれませんが、ここで共有することで進化できるアイデアがいくつかあります。

私たちのアプリには、1,000 万を超えるレコードのテーブルがいくつかあります。それらのクエリには約 40 秒かかります。主キーやインデックスなどの使用など、既知のデータベース設計手法に従いました。古い行のアーカイブやテーブルの分割なども試しましたが、まだそれほど印象的ではありません。

このアプリケーションは非常にデータ集約的ですが、銀行などの多くのサイトには膨大なデータがありますが、それでもパフォーマンスが優れていることは理解しています。私はデータベースの専門家ではありません。ここで誰かが私が欠けているものを指摘できますか?

データベース クラスタリングなどの標準的な手法がいくつかありますが、インフラストラクチャで許可されていないものもあります。

生のストレージと比較して、より処理された形式でデータを保存できるかどうかについて、漠然とした考えがありますか? データベースの設計に新たな設計慣行はありますか? NoSQL に簡単に移行できますか? また、NoSQL はどの程度優れていますか?

4

2 に答える 2

7

1000万行はそれほど多くありません。クエリを個別に調整します。40 秒かかるクエリが 1 つある場合は、それがどれであるかを調べて修正します。インデックスが作成されていない where 句で単一の列を使用すると、パフォーマンスが 0.0001 秒から 40 秒に向上します。ほとんどのデータベースには、クエリの実行方法を知らせる「クエリの説明」機能があります。

私が最近取り組んだ小規模な「ビッグ データ」の問題には、1000 億行 (圧縮された 10 TB 程度のデータ) が含まれていました。

クエリが遅い理由がわからない場合は、まだ RDBMS 以外のソリューションを検討するべきではありません。

于 2013-06-27T12:00:49.323 に答える