1つのテーブルに50Mのレコードが含まれるデータベースを設計する必要があります(レコードの数が少ない他のテーブルが存在します)。結合クエリとデータベースへのデータ(挿入)の書き込みにもっと関心があります。更新が少なくなり、クエリが削除されます。
私はPostgresqlとMySQLのパフォーマンス比較について この記事 を読みました。
また、以下のリンクも確認しました。
https://stackoverflow.com/questions/8181604/postgres-9-1-vs-mysql-5-6-innodb
https://stackoverflow.com/questions/110927/would-you-recommend-postgresql-over-mysql
https://stackoverflow.com/questions/724867/how-different-is-postgresql-to-mysql
MySQL vs PostgreSQL:MySQLがPostgreSQLより優れている理由
私の問題は、stackoverflowの一部のリンクが古くなっていることです。一部の人々は、Mysqlの方が優れていると言っています。
結合クエリとデータベースへのデータの書き込みに関心があるので、どちらが適していますか? Postgresql対MySQL?このようなデータベースを設計するには、どのようなアプローチを取るべきですか?
これをPostgresqlとMySQLの別の質問と見なさないでください。私は自分の研究を終え、結合クエリとデータベースシナリオへのデータの書き込みのみに関心があります。また、GISデータにはPostgreSQLの方が優れていることも知りました。 。
データベースは異なります。一般的に、答えは特定のクエリに大きく依存します。一般的なユースケースに関しては、いくつかの理由でPostgreSQLのパフォーマンスが向上することを期待しますが、MySQLのパフォーマンスが向上することを期待するケースもあります。
PostgreSQLでは、すべてのテーブルがヒープテーブルです。 MySQLでは、すべてのinnodbテーブルは、ペイロードにタプルを含むbtreeインデックスです。つまり、MySQLではプライマリキーの検索が高速になりますが、PostgreSQLでは一般的なクエリが高速になります。また、通常、MySQLでより多くのインデックスが必要になるため、書き込みが遅くなります。
たとえば、次のクエリは、MySQLでPostgreSQLよりも優れたパフォーマンスを期待します。
SELECT u.username, p.*
FROM users u
JOIN preferences p ON u.id = p.user_id
WHERE u.id = 123;
両方のテーブルが同じ主キー(u.idとp.user_id)を共有している場合、両方のテーブルに数千の行が存在します。
一方、次のクエリは、メモリ、キャッシュされていないデータ、適切なインデックス、適切なサイズのテーブルなどに収まらないdbで、MySQLよりもPostgreSQLの方がPostgreSQLでパフォーマンスが高いと予想されます。
SELECT c.legal_name, a.*
FROM company c
JOIN address a on a.company_id = c.id
WHERE a.Zip_code like '95%' and country = 'us';
この場合、他のインデックスを使用する必要があります。これは、MySQLでランダムなディスクI/Oが大量に発生することを意味します。
私が期待する2番目の問題は、書き込みパフォーマンスです。ヒープテーブルでは都合の良い場所であればどこでも挿入が可能であり、維持するインデックスの数も少なくて済むため、PostgreSQLは一般的にここで勝つと思います。