2

データベースの専門家の助けが必要です。

MySQL で SQL ファイルとしてエクスポートすると、1.5 GB を超える大きなデータベースがあります。

私が直面している問題は、何百万ものデータを保持する統計などのテーブルに対するクエリがサーバーをクラッシュさせることです。

私は現在、これに対するいくつかの解決策を考えており、Redis と MySQL の両方を連携させるだけで、大きなテーブルの Redis 実装に傾いています。特にパーミッションとアクセス制御リストを定義するときに、MySQL には多くの複雑なリレーションが設定されているため、MySQL を維持する必要があると思います。また、Redis が支払いなどの機密データを保存するのに安全かどうかもわかりません。

これは問題を解決するための最良の方法ですか?

これに代わるものとして、パフォーマンスの向上に非常に効果的であると聞いた MySQL シャーディングがあります。

この場合、あなたはどうしますか?

更新 - これは私がMySQLTunerから持っているものです:

-------- Performance Metrics -------------------------------------------------
[--] Up for: 9d 1h 9m 33s (98M q [126.517 qps], 2M conn, TX: 354B, RX: 15B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 232.0M global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 647.2M (10% of installed RAM)
[OK] Slow queries: 0% (876/98M)
[!!] Highest connection usage: 100%  (152/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/294.2M
[OK] Key buffer hit rate: 100.0% (148B cached / 2M reads)
[OK] Query cache efficiency: 81.0% (64M cached / 79M selects)
[!!] Query cache prunes per day: 36845
[OK] Sorts requiring temporary tables: 0% (27 temp sorts / 7M sorts)
[!!] Joins performed without indexes: 8358004
[!!] Temporary tables created on disk: 44% (8M on disk / 18M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (400 open / 266K opened)
[OK] Open file limit used: 38% (398/1K)
[OK] Table locks acquired immediately: 99% (42M immediate / 42M locks)
[OK] InnoDB data size / buffer pool: 67.8M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Reduce or eliminate persistent connections to reduce connection usage
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    max_connections (> 151)
    wait_timeout (< 28800)
    interactive_timeout (< 28800)
    query_cache_size (> 64M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 400)
4

2 に答える 2

2

普遍的な制限はありませんが、1.5 GB をビッグ データと見なすべきではありません。ワークロードを示している可能性がある TPS (1 秒あたりのトランザクション数) の数を提供していません。

ただし、非リレーショナル ソリューションに切り替えると、RDBMS を最適化するよりもはるかに多くの問題が発生します。したがって、次のように自問する必要があります。

  • サーバーをクラッシュさせるクエリはどれですか?
  • クエリは適切なインデックスを使用していますか?
  • 実行時間の長いクエリはテーブルをロックしますか?
  • サーバーは適切に構成されていますか? 利用可能なメモリの 80% を使用するように innodb_buffer_pool_size を設定しましたか? Percona のスライドをご覧ください: http://www.percona.com/files/presentations/WEBINAR2012-03-Optimizing-MySQL-Configuration.pdf
  • システムを遅くするものを使用していますか? たとえば、優れたパフォーマンスが必要な場合は、SELinux は適していません。

すべての答えが「はい」の場合は、他の解決策の使用を検討してください。

  • ハードウェアのアップグレード (重要度の高い順に: RAM の増設、ディスクの高速化、高速バスを備えた CPU の増設)
  • MySQL のパーティショニング
  • Percona の XtraDB クラスター
  • いくつかのシャーディングと負荷分散を行う Shard Query ストレージ エンジン
于 2013-05-22T15:38:08.633 に答える
0

1.5 Gig のデータはビッグ データではありません。正しく構成されていれば、MySql は問題なく処理できます。

したがって、他のものを見る前に、MySql db で、このリストからすべてを試して除外したことを確認してください。

  • あなたはあなたのmysql設定を調整しました(デフォルトは最悪です)
  • インデックスを使用しています
  • クエリを最適化しました(実際にインデックスを使用していることを確認してください)
  • できる限り多くのRAMを使用します

このリストを最後まで読むと、MySql についてさらに多くのことを知ることができ、おそらくスタックに追加のコンポーネントを追加する必要はなくなるでしょう。(または、DBA を雇って同じ結果を得ることができます)

于 2013-05-22T15:34:52.260 に答える