0

現在、MySQLCommunityEditionサーバー5.5.16はGPLの下にあります。これは、オープンソースプロジェクトでもあるプロジェクトで使用される可能性があることを意味します。私たちのプロジェクト予算は非常にタイトであり、商用プロジェクトでMySQL無料版を使用するためのソリューションを見つける必要があります。いくつか質問があります。

1)商用プロジェクトで使用するのに十分な堅牢でバグのない以前のMySQLバージョンはどれですか?

2)現在のMySQL Community Editionサーバー5.5.16をGPLで使用することについて:プロジェクトソフトウェアアーキテクチャが多くのDBMSのプラグインをサポートするように設計されている場合、非GPLライセンスの下でプロジェクトソフトウェアを使用することは合法ですか?つまり、ソフトウェアが複数のDBMSをサポートするように設計されており、ソフトウェアが商用ライセンスの下に置かれているとします。クライアントがMySQLGPLバージョンを使用することを選択した場合、彼はGPLライセンスに違反しますか?

3)PostgreSQLがバグがあり、大量のデータセットを変更および保存するために最適化されていないという否定的な回答をいくつか聞きました。それがまだいくつかの小さな商業プロジェクトで使用されている唯一の理由は、それが無料だからです。それについてどう思いますか?

更新:また、複数のサーバーを使用することを計画しているため、マスタースレーブレプリケーションも必要です。

UPDATE2:1つのケースについて聞いた:1GBまでのPostgreSQLDBが使用された。データベースは、ほとんどすべてのデータを変更することにより、更新で頻繁に使用されていました。問題は、データベースが2.5か月ごとに約10回絶えず増大していることでした。彼らはPostgreSQL8.3+CentOSを使用しています。また、AUTOVACUUMが使用されました。データベースをダンプし、古いデータベースを破棄し、データベースを再作成してインポートした後、そのサイズを最大10分の1に減らすことができました。既存の投稿(ここここ)は、この問題が最新のPostgreSQL9バージョンでも相対的であることを示しています。私はそれを通常の動作とは呼びませんし、そのようなサイズの増加は私たちの場合は受け入れられません。

UPDATE3:回答ありがとうございます。すべての回答は相対的であり、質問に役立ちます。

4

5 に答える 5

2

3)PostgreSQLがバグがあり、大量のデータセットを変更および保存するために最適化されていないことについて、多くの否定的な回答を聞きました。それがまだいくつかの小さな商業プロジェクトで使用されている唯一の理由は、それが無料だからです。それについてどう思いますか?

ROFL

冗談じゃないわ!純粋なFUDと他には何もありません。

PostgreSQLデータベースには数TBのデータがあり、それでも月に約200GB増加しています。バグも問題もなく、素晴らしいパフォーマンスです。また、500人の同時ユーザーで、まったく問題はありません。メーリングリストをチェックしてバグを数え、それらがどれだけ早く解決されるかを確認してください。数時間以内に修正があったとしても驚かないでください。MySQLはそれから学ぶことができます。

http://archives.postgresql.org/pgsql-bugs/

于 2011-10-19T09:14:27.567 に答える
2

2) 現在の MySQL コミュニティ エディション サーバー 5.5.16 を GPL で使用することについて: プロジェクト ソフトウェア アーキテクチャが多くの DBMS のプラグインをサポートするように設計されている場合、非 GPL ライセンスの下でプロジェクト ソフトウェアを使用することは合法ですか? つまり、ソフトウェアが複数の DBMS をサポートするように設計されており、ソフトウェアが商用ライセンスの下に置かれているとします。クライアントが MySQL GPL バージョンを使用することを選択した場合、クライアントは GPL ライセンスに違反しますか?

GPL ライセンスのライブラリにリンクするとすぐに、コード全体が GPL の下でライセンスされます。オラクルは、その他の無償ライセンスのみを例外としています。

于 2011-10-19T08:44:11.090 に答える
2

3) PostgreSQL はバグが多く、大量のデータセットを変更および保存するのに最適化されていないという否定的な回答を多く耳にしました。一部の小規模な商用プロジェクトでまだ使用されている唯一の理由は、無料だからです。それについてどう思いますか。

これがFUDです。PostgreSQL は、いくつかの大規模な展開で使用されるフル機能の高性能 RDBMS です。

于 2011-10-19T08:39:37.443 に答える
1

私も同じ問題を抱えていました。以前、私は商用プロジェクトでmysqlを使用していました。しかし、オラクルが引き継いでライセンスポリシーを変更した後、SQL-Express、DB2-Express、SQL-lite、PostgreSqlなどの他のオプションを探しました

周りにたくさんの情報があるので、私は比較に立ち入りません。しかし、PostgreSqlは

a)大規模なデータセットの処理

b)SQL標準

c)インラインドキュメント

d)データベース使用統計

実際、SQLコマンドやドキュメントの変更に関するオーバーヘッドなしで、プロジェクトを一晩で開始できました。

ただし、私はWindowsでdotnetを使用しているので、Npgsqlは私たちを怖がらせる唯一の信頼できるコネクタです。

しかし、これまでのところ、PostgreSql9.0での開発は絶対に簡単でした。

于 2011-10-19T10:22:17.670 に答える
1

他の投稿者は、基本的に mysql にリンクするということは、プロジェクト GPL または Oracle / MySQL が例外としているその他の OS ライセンスのライセンスを取得したこと、またはそれが商用であり、あなたが彼らにお金を借りていることを意味すると述べています。ともかく...

OK、PostgreSQL はそのデータを、MVCC、マルチバージョン同時実行制御をサポートするデータ ストアに格納します。これは単純なレベルで、トランザクションが開始されてからコミットまたはロールバックされるまで一貫したデータベースのスナップショットを取得することを意味します。これは、任意の時点で、単一のタプルがデータベース内に複数のライブ バージョンを持つことができることを意味します。MVCC が pgsql に実装される方法により、これら 2 つのバージョンが同時にデータ ストアに存在します。最終的に、最新のものを除くすべてのトランザクションは、実行中の最も古いトランザクションよりも古くなり、データベースによって回復および再利用できます。これらの古い死んだタプルを再利用するプロセスは、バキューム処理と呼ばれます。

8.3 では、フリー スペース マップと呼ばれる共有メモリ セグメントを使用して、古いデッド ブロックを追跡していました。バキュームが十分に積極的でない場合、または空きスペース マップのスペースが不足している場合、データベースはデッド タプルを回復 (バキューム) または記憶 (空きスペース マップ) よりも速くする可能性があります。

8.4 では、フリー スペース マップは .fsm ファイルでハード ドライブに保存されるため、ユーザーはメンテナンス フリーになります。ただし、真空の問題は依然として存在します。autovacuum は、インストール時にラップトップや小さなサーバーなどを強制終了しないように、攻撃的になりすぎないように調整されています。RAID-10 アレイに 16 個の SSD を搭載したサーバーのような、大量の IO 機能を備えたより大きなマシンでは、autovacuum の積極性を高めることができ、かなりクレイジーな tps レートに追いつくことができます。十分にアグレッシブな自動バキュームと、多数のディスクを備えた高速ハードウェア RAID コントローラーを備えたサーバーでは、1 秒あたり 1,000 から 3,000 のトランザクションを長期間にわたって維持できます。より高価で大規模なサーバーでは、10,000 に近い TPS 数が可能です。何百もの接続にサービスを提供しながら。

tl;dr: 8.3 は古く、def にはいくつかの問題がありました。8.4 以降では空き領域の回復が改善されていますが、重い負荷に対応するには積極的な autovac が必要です。

于 2011-10-20T09:01:22.617 に答える