22

内部設定データベースとしてHSQLDBを使用する確立されたソフトウェア製品があります。顧客のプロジェクトはこのデータベースに保存されます。何年にもわたって、HSQLDBは​​かなりうまく機能してきましたが、安定性や破損の問題があり、サークルをコーディングする必要がありました。それでも、HSQLDBから完全に保護することはできません。

内部データベースの変更を検討しています。これを行うことは、開発の観点からはかなり苦痛ですが、破損したデータベース（および失われたデータ）を顧客に説明するのは楽しいことではありません。

だから私の質問は：Apache Derbyの長期的な安定性を検討するのに十分な経験を持っている人はいますか？ダービーが不安定だとグーグルで投稿したのですが、2006年からなので、ここ4年で改善されたと思います。または、私が使用できる別の純粋なJava組み込み（インプロセス）データベース（商用またはオープンソース）はありますか？パフォーマンスは私にとってそれほど重要ではありません。安定性が王様です。電力損失全体にわたるデータの整合性、優れたBLOBサポート、およびホットバックアップはすべて必須です。

SQLベースのリレーショナルデータベースではないものを提案しないでください。おかげで、ゼロから始めるのではなく、既存の製品を改造しようとしています。

4

8 に答える 8

21

データベースエンジンごとに、破損のリスクがあります。私はH2データベースの主な作成者であり、壊れたデータベースに関するレポートも受け取りました。テストはバグの可能性を減らすことができますが、残念ながら、一部のソフトウェアが「バグフリー」であることを保証することはほとんど不可能です。

3つのJavaデータベースHSQLDB、Apache Derby、およびH2については、どれが最も安定しているかはわかりません。私はH2についてしか話すことができません。ほとんどの操作で、H2は安定していると思います。データベースが破損するかどうかを特別にテストするテストケースはたくさんあります。これには、停電の自動テストが含まれます（クリスマスライトタイマーを使用）。電源障害テストで、安定性はファイルシステムにも依存することがわかりました。オペレーティングシステムがファイルを読み取れないことを意味する「CRCエラー」メッセージが表示されることがありました（Windowsでした）。その場合、できることはあまりありません。

ミッションクリティカルなデータについては、いずれにせよ、ソフトウェアが安定していることに依存しません。定期的にバックアップを作成し、それらをテストすることは非常に重要です。一部のデータベースには、バックアップを作成するための複数の方法があります。たとえば、H2には、オンラインバックアップ機能と、SQLスクリプトファイルを作成する機能があります。別の方法は、レプリケーションまたはクラスタリングを使用することです。H2はシンプルクラスターモードをサポートしています。Derbyはレプリケーションをサポートしていると思います。

于 2010-07-03T17:14:14.820 に答える
13

ビルドの自動化とテスト管理システムをサポートする内部データベースとして、Derby を 4 年間 24 時間年中無休で実行しました。世界中のチームが使用しており、クラッシュしたり、データを失ったり、記録が破損したりすることはありませんでした。使用をやめた唯一の理由は、当社が他社に買収され、より高いレベルの決定が下されたためです。Derby は堅牢で信頼性が高く、検討する価値があります。

于 2010-06-29T22:05:47.707 に答える
9

この検索で​​は、文字列「破損」を含む HSQLDB ユーザー メーリング リストの 215 件の投稿が表示されます。 http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.java.hsqldb.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.java.hsqldb.user---A

この検索で​​は、同じ文字列を含む Derby ユーザー メーリング リストの 264 件の投稿が表示されます。 http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.user&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcomp.apache.db.derby.user---A

これは、同じ文字列http://search.gmane.org/?query=corrupt&author=&group=gmane.comp.apache.db.derby.devel&sort=date&DEFAULTOP=and&xP=Zcorrupt&xFILTERS=Gcompを持つ Derby Dev メーリング リストの 1003 件の投稿を示しています。 .apache.db.derby.devel---A

投稿のいくつかを見ると、データベース開発者の最善の努力にもかかわらず、データベース破損の可能性または実際のケースが発生することが示されています。

HSQLDB には独自のデータベース破損の問題がありましたが、長年にわたって改善されてきました。最新バージョンでは、過去数年間に報告されたすべての問題を防ぐための予防措置と修正が導入されています。

ただし、新しいロブ ストレージ機能には、更新後にロブが「忘れられる」という論理的なバグがあることが判明しました。これは現在修正中であり、修正をサポートするためのより広範なテストが行​​われています。

CarlG のようなユーザーは、Derby と HSQLDB の両方のバグ修正作業において長年にわたって多くの支援をしてきました。

Fred Toussi、HSQLDB プロジェクト

于 2010-07-03T11:48:29.683 に答える
7

Apache Derby の長期的な安定性を検討するのに十分な経験を持っている人はいますか? (...)

Derby、元 IBM Cloudscape (現在は Sun によって JavaDB としても配布されています) は ACID 準拠のデータベースであり、多数の同時ユーザーに対応し、組み込みモードまたはサーバー モードで実行でき、堅牢で実動対応であることが知られています。HSQLDB ほど高速ではありませんが (Derby は永続的な操作を使用します)、堅牢です。それでも、それに対して独自のテストを実行する必要があります。

こちらもご覧ください

于 2010-06-29T22:19:36.193 に答える
4

H2を調べてみてください。これは、元々HSQLDBを作成した人によって作成されましたが、ゼロから作成されたため、HSQLDBコードを使用していません。私は長年HSQLを使用しておらず、現在は短命のデータベースにのみH2を使用しているため、その安定性がHSQLとどのように比較されるかわかりません。個人的には、H2はダービーよりも簡単に実行できると思いましたが、それはおそらくH2に虎の巻のWebページがあるためです。

抽象化レイヤーを使用するように再コーディングしてから、テストを実行して、H2とDerbyを見つけた問題と比較することができる場合があります。

フェンスのプロジェクト管理側で、ロードマップにメジャーバージョンが登場しますか？これは、この方法で内臓を取り除くのにかなり適切な時期かもしれません。管理が難しい多くの回避策を削除できる可能性があるため、あなたが気が狂っているとは言えません。警告やバックアップを十分に行わずに、稼働中のシステムに影響を与える可能性のある変更を加えたい場合は、気が狂っている可能性があります。

于 2010-06-29T21:35:03.977 に答える
3

HSQLDB に関しては、SQLite が持っているプロジェクトとして持っていないものの 1 つは、堅牢なテスト スイートのドキュメントと、熱心な ACID 準拠のオンライン ドキュメントです。

HSQLDB から何かを奪うつもりはありません。これは、SQLite が意図する fopen() ではなく、MySQL の代替として機能することを意図しています。HSQLDB (実際にはすべての Java RDBMS) の範囲は、はるかに野心的であると言えます。Fredt と彼のグループは、HSQLDB を使用して並外れた成果を達成しました。それでも、「HSQLDB ACID に準拠していますか?」という Google 検索を行っても、アーリー アダプターは、SQLite Web サイトでテスト ハーネスについて読んだ後に感じるほど自信を持っていません。

http://sqlite.org/transactional.htmlで

「SQLite はトランザクショナルです

トランザクション データベースは、すべての変更とクエリが Atomic、Consistent、Isolated、Durable (ACID) であるように見えるデータベースです。SQLite は、トランザクションがプログラムのクラッシュ、オペレーティング システムのクラッシュ、またはコンピューターの電源障害によって中断された場合でも、原子的で、一貫性があり、分離され、耐久性のあるシリアル化可能なトランザクションを実装します。

ここで、前の文を強調し直し、拡大します。SQLite の 1 つのトランザクション内のすべての変更は、変更をディスクに書き込む操作が中断された場合でも、完全に発生するか、まったく発生しないかのいずれかです。

  • プログラムのクラッシュ、
  • オペレーティング システムのクラッシュ、または
  • 電源障害。

前の段落の主張は、オペレーティング システムのクラッシュと電源障害のデータベース ファイルへの影響をシミュレートする特別なテスト ハーネスを使用して、SQLite 回帰テスト スイートで広範囲にチェックされます。」

http://sqlite.org/testing.htmlで

"1.0はじめに

SQLite の信頼性と堅牢性は、徹底的かつ慎重なテストによって部分的に達成されます。

バージョン 3.7.14 の時点で、SQLite ライブラリは約 81.3 KSLOC の C コードで構成されています。(KSLOC は、数千の「コードのソース行」、つまり空白行とコメントを除くコード行を意味します。)比較すると、プロジェクトには 1124 倍のテスト コードとテスト スクリプト (91421.1 KSLOC) があります。

1.1 要旨

独立して開発された 3 つのテスト ハーネス デプロイされた構成での 100% のブランチ テスト カバレッジテスト assert() と実行時チェックの広範な使用 Valgrind 分析 符号付き整数オーバーフロー チェック"

于 2013-01-27T17:08:30.860 に答える
1

自己完結型 (サーバーが関与しないもの) を探している場合は、SQLite を試してみてください。これは android の db api をサポートするものであり、非常に安定しています。

于 2012-06-15T14:52:53.777 に答える