4

C++ で実装されている負荷分散された Web 向けアプリケーションのバックエンドとして、GDBM キー値データベースがあります。アプリケーションによって提供されるデータが非常に大きくなったため、管理者は GDBM ファイルを「ローカル」ストレージ (Web サーバー上、またはそのすぐ近く) から大規模な共有のリモート NFS マウント ファイルシステムに移動しました。

これはパフォーマンスに影響を与えました。当社のパフォーマンス テスト (テスト環境) では、ページの読み込み時間が数百ミリ秒 (ローカル ディスクの場合) から数秒 (NFS、ローカル ネットワーク経由) に跳ね上がり、時には 30 秒に達することもあります。問題の大部分は、アプリケーションが GDBM ファイルからランダムな読み取りを大量に行うことであり、NFS ではこれらの読み取りが遅く、本番環境ではさらに悪化すると考えています (フロントエンドとバックエンドでさえそれらの間のより多くのネットワーク ハードウェア) と、データベースがさらに大きくなるにつれて。

これは重要なアプリケーションではありませんが、パフォーマンスを改善し、アプリケーション開発者の時間や Unix 管理者などのリソースを利用できるようにしたいと考えています。私の主な制約は、数週間しかリソースを持てない時間です。

私が見ているように、私のオプションは次のとおりです。

  1. パラメータを調整して、NFS のパフォーマンスを向上させます。私の本能は、これから多くを得ることができないということですが、私は以前に間違っていました.NFSのチューニングについてはあまり知りません.

  2. memcachedbやTokyo Cabinetなどの別のキー値データベースに移動します。

  3. NFS を他のプロトコルに置き換えます (iSCSI について言及されていますが、私はそれに慣れていません)。

この問題にどのようにアプローチすればよいですか？

4

4 に答える 4

10

「リレーショナルと非リレーショナル」の比較にこだわりすぎないでください。この問題には無関係のようです。

アプリケーションが越えた境界は、ローカルの高速ファイル ストレージ上の小さなデータベースから、ネットワーク経由でアクセスされる大規模なデータベースまでとは異なります。この一線を越えるということは、専用のネットワーク サービス データベース管理システムによって、より適切にサービスを提供できるようになったことを意味します。管理サーバーがリレーショナル データベースを管理するかどうかは、その側面には関係ありません。

すぐに起動して実行するには、MariaDB (MySQL の後継) がおそらく最善の策です。現在の場所をはるかに超えて成長すると予測する場合は、PostgreSQLに配置することもできます。いずれにせよ最終的にはそこに移動する必要があるからです :-)

于 2009-03-29T22:52:08.890 に答える
2

これはあなたが聞きたいことではないようですが、正直なところ、私があなたなら、mysqlテーブルにそれを投げます。GDBM-over-NFSとは異なり、実際に状況に合わせたリモートアクセスプロトコルなど、操作が意味のあるほど難しいわけではなく、多くのメリットがあります。

于 2009-03-29T21:54:13.973 に答える
1

非リレーショナル データベースに固執したい場合は、BDBまたは DJB のCDBを試すことができます。私はこれまで両方を使用してきましたが、パフォーマンスに関して言えば、GDBM よりも優れていると思います。

ただし、bignose の回答を念頭に置いておいてください。ボトルネックは、使用しているデータ構造 (GDBM) ではなく、インフラストラクチャである可能性があると私も考えています。

于 2009-07-13T19:55:32.670 に答える
0

ネットワーク上でフラットファイルを使用するファイルシステムi/oはお勧めできませんが、i / o、クエリなどを作成するマルチスレッドTCPサーバーの作成を検討する必要があります。そのマシンで、結果を返します。dbファイル全体ではなくデータの小さなチャンクを転送します。

高可用性の問題を克服するためにキャッシュ永続性メカニズムを設計しています。Pythonでコーディングします。

于 2011-02-20T16:26:35.243 に答える