1

私は、ユーザーが単語を入力して定義を取得できる英語のWeb辞書を作成しています。私はしばらくこれについて考えましたが、データは100％静的であり、一度に1つの単語しか取得できなかったため、MySQLを使用して定義を格納するのではなく、データベースシステムとしてファイルシステム（ext3）を使用する方が適切でした。MySQLに接続する必要があり、それ自体が非常に遅い操作であることを考えると、オーバーヘッドが少なくなると思いました。

私の恐れは、もし私のシステムが例えば500ワード/秒の検索で攻撃されたとしても、データベースとしてファイルシステムを使用したほうがよいのではないかということです。または、MySQLが内部で行っている可能性があることとは対照的に、ファイルシステムの読み取りが増えるとパフォーマンスが低下しますか？

現在、階層は単語の最初の文字、2番目の文字、3番目の文字で分割されています。したがって、「水」の定義を検索する場合、スクリプト（PHP）は「../dict/w/a/t/water.word」から読み取ろうとします（問題のある文字の単語をクリーンアップした後、小文字）

私はこれで正しい方向に向かっていますか、それともより速い解決策がありますか（memcachedのようなものを使用してメモリに定義を保存することを数えません）？ディレクトリに保存されるファイルの量はパフォーマンスに影響しますか？ディレクトリに保存する必要のあるファイル数の大まかなベンチマークは何ですか？

4

9 に答える 9

2

この決定がソリューションの全体的なパフォーマンスに重要であるというあなたの信念の根拠は何ですか？定義を提供する以外に何をしますか？

とにかくソリューションの一部としてMySQLを使用していますか、それともここでソリューションとして選択した場合に追加する必要がありますか？

定義の決定的な情報源はどこにありますか？（おそらく複製された）ファイルシステム、またはいくつかのオフラインDB？

アーキテクチャ的にDBにあるべきもののようです-ファイルシステムは、多数の名前を値にマップするための奇妙な場所です（ファイルシステム構造が最初の文字で物事を分解していることからも明らかです）

DBにある場合は、「定義はいくつありますか？」などの質問に答えます。はるかに簡単ですが、アプリケーションでそのようなことを気にしないのであれば、これは問題ではないかもしれません。

したがって、これはある程度、パフォーマンスがソリューション全体に大きな違いをもたらさないもののパフォーマンスをハイパー最適化することを検討しているように感じます。

私は「正しくしてから速くする」のファンであり、「正しい」はDBを使用して達成する方が簡単です。

そしてもちろん、最終的な答えは、両方を試して、どちらが状況に最も適しているかを確認することです。

ポール

于 2008-11-02T11:58:33.987 に答える
1

辞書に必要なルックアップのタイプは、まさにデータベースが得意とするものです。あなたが説明するファイルシステムの方法は実行不可能になると思います。難しくしないでください！データベースを使用します。

于 2008-11-02T11:36:34.640 に答える
1

DBへの接続を高速化するために、接続プールを維持できます。

また、このアプリケーションを複数のサーバーに拡張する必要がある場合、ファイルシステムをサーバー間で共有するのは難しい場合があります。

だから、私は提案の3番目です。DBを使用します。

しかし、それが非常に大きな辞書でない限り、キャッシュはほぼ常にローカルメモリからデータを取得していることを意味するので、これがアプリケーションの最大の問題になるとは思わない:)

于 2008-11-02T11:44:14.687 に答える
0

DBはあなたのニーズにぴったりです。また、memcachedが関連する理由もわかりません（データの大きさは？数GBを超えることはできません...そうですか？）

于 2008-11-02T11:40:20.543 に答える
0

データは約数GBです。そして私の目標は速度、速度、速度です（定義はXHRを使用してロードされます）。私が言ったように、データは静的であり、変更されることはありません。また、リクエストごとに1回の読み取り操作以外のものを使用することはありません。そのため、MySQLとそのすべての肥大化を使用することを確信するのにかなり苦労しています。

この戦略、ファイルシステム、またはMySQLを使用して、高負荷で最初に失敗するのはどれですか？スケーリングに関しては、データが変更されることはなく、わずか数GBであるため、レプリケーションがその答えです。

于 2008-11-02T11:49:35.610 に答える
0

最初に機能させます。時期尚早の最適化は良くありません。

データベースを使用すると、スキーマのリファクタリングが容易になり、インデックス ベースのルックアップの実装を記述する必要がなくなりますが、これは実際には重要です。

データベースへの接続が「非常に遅い操作である」と言うのは、問題を誇張しています。実際には接続にそれほど時間はかからず、接続を再利用することもできます。

読み取りスケーリングが心配な場合、1G データベースは非常に小さいため、その読み取り専用レプリカを各 Web サーバーにプッシュし、それぞれのローカル コピーから読み取ることができます。書き込みが読み取りパフォーマンスに影響を与えないレベルにとどまる場合、ほぼ完璧な読み取りスケーラビリティが得られます。

さらに、1G のデータは RAM に簡単に収まるため、起動時に (ノードがロード バランサーにアドバタイズする前に) データベース全体をメモリにロードすることで高速化できます。

1 秒あたり 500 回のルックアップは、ごくわずかです。おそらく、サーバーごとに毎秒5000について心配し始めるでしょう。最新のハードウェアで 1 秒あたり 5000 回のキー検索を達成できない場合 (RAM に収まるデータベースから?!!)、実装に深刻な問題があります。

于 2008-11-02T12:01:25.870 に答える
0

これは時期尚早な最適化であり、MySQL は確実にこのユース ケースに対して十分なパフォーマンスを発揮することに同意します。妥協点として、非常に高速なTokyo Cabinetのようなファイルベースのデータベースを使用することもできます。悲しいことに、PHP バインディングがないため、その祖先であるDBMを使用できます。

とはいえ、ファイルシステムを使用しないでください。私が見る限り、正当な理由はありません。

于 2008-11-02T12:16:04.013 に答える
0

RAMで仮想ドライブを使用するか（ディストリビューションのハウツーについてはGoogleで検索してください）、またはAPCを使用するPHPによってデータが提供されている場合、memcacheはmysqlでうまく機能する可能性があります。個人的には、ここで行っている最適化は、実際に時間を費やすべき場所ではないと思います。1 秒あたり 500 リクエストは膨大です。mysql を使用すると、後で転送機能が改善されると思います。競合他社との差別化を図りたいのであれば、スピードではなく機能に集中する必要があると思います。また、Web の UI についての良い話もいくつかあります。サーバーの速度は、全体像の小さな要素にすぎません。

幸運を

于 2009-01-01T17:53:47.213 に答える
0

このようなもののために、SQL を使用しないデータベース (riak、mongo、さらには redis など) について考えるかもしれません。それらはすべて超高速で、レプリケーションに役立ちます。このような場合、Mysql はやり過ぎでスケールしにくいかもしれませんが、他のインスタンスには堅牢なツールがいくつかあります。

于 2011-01-14T19:43:09.063 に答える