6

これら 2 つのデータベースのどちらかを選択する必要がある状況にあります。私たちは現在 Firebird を使用していますが、トランザクション履歴のスタックが多すぎるなどの理由で遅れることがあり、状況を改善するためにバックアップと復元を適用する必要があります。

私の特定のケースでは: データベースには、数値フィールドで満たされたほとんどのテーブルがあります。ほとんどの場合、クエリには内部結合があります。私が挿入して選択しているレートとほぼ同じです。（しかし、将来的には、より厳しい選択を検討しています）数十億のレコードを持つ3つのメインテーブルがあります（毎秒成長し続けます）。

しかし、上記のような通常のロードと、選択したフィールドの選択と作業、イベントのトリガーとストアプロシージャの実行への全体的なパフォーマンスなど、選択するのに十分な知識があると考えているオーバーロードに最適なものを確認したいと思いますそれらの間で（より多くの意見を歓迎します）、おそらく他の人々が決定を下すのに役立ちます.

私は尋ねています

  • Interbaseと同じですか？
  • Interbase にジャンプする価値はありますか?
  • 全体的にどちらのパフォーマンスが良いですか?
  • Interbase には、データベースを拡大し続けて速度を低下させる Firebird のようなこの履歴の問題がありますか?

PS: 今のところ、解決策を確認せずにこの質問を残します。おそらく、通常の毎日のクエリベースで実際にデータベースを比較する人がいて、質問と結果が私にとってより使いやすくなり、他の人々がそのような状況に陥るでしょう.

4

3 に答える 3

8

あなたが説明する問題は、通常、不適切なトランザクション管理、または実行時間の長いトランザクションが原因です。通常、これを修正するためにバックアップと復元は必要ありません。バックアップで十分です (Firebird はバックアップ中に追加のクリーンアップとガベージ コレクションを行うため)。

Firebird (および Interbase) は両方ともマルチ バージョン同時実行制御を使用します。つまり、変更は新しいレコード バージョンに記録されます。古いレコード バージョンは、そのトランザクションに関心を持つ開いているトランザクションがない場合にのみクリーンアップされます。ロールバックされたトランザクションによって作成されたレコード バージョンは、スイープ中にのみクリーンアップされます。

不適切なトランザクション管理 (長時間実行されているトランザクションがある、またはコミットの代わりにコミット保持を使用する)、予期しない切断などは、トランザクションがまだ開いていることを意味する可能性があります。これは、データベースによってそれらをクリーンアップする必要があることを意味します (Firebird でのいわゆるスイープ) ）。同じレコードの複数のバージョンを読み取る必要があるため、データベースの速度が低下する可能性があります。

前述のように、バックアップを実行するときにスイープが実行されます。したがって、バックアップを行うだけで、ほとんどの問題を取り除くことができます。

詳細については、gfix ハウスキーピングを参照してください。

于 2011-05-27T10:04:37.323 に答える
7

明らかで、かなり退屈な答えは、独自のワークロードを使用して 2 つのベンチマークを実行する必要があるということです。アプリケーションのワークロードは、他のすべてのベンチマークまたはアプリケーションとは異なる可能性があります。

于 2011-05-26T07:22:49.983 に答える
3

テスト データベースとテスト ケースを Firebird 開発者に送信して、速度を向上させることができます。

データベースにはパーティション分割が必要だと思い始めました

于 2011-05-31T08:46:28.810 に答える