Mysql 'Partitioning'とデータを別のテーブルに分割する

Question

posts_contentという名前のmysqlテーブルがあります。次のように

構造は次のとおりです。

CREATE TABLE IF NOT EXISTS `posts_content` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `post_id` int(11) NOT NULL, 
    `forum_id` int(11) NOT NULL, 
    `content` longtext CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=79850 ; 

問題は、テーブルはかなり巨大になっているということです。多くのギガバイトのデータ（Googleにはクロールエンジンがあります）。

データを日常的にテーブルに挿入していますが、データを取得することはめったにありません。テーブルがかなり巨大になっているので、テーブルを扱うのが難しくなります。私たちは、forum_idを使用してテーブルを分割するために、2つの可能性

1. 使用MySQLのパーティショニング機能を議論し

   （約50 forum_idsがある約50のパーティションが存在することになるので。そう作られている場合でも、各パーティションなおは最終的に成長します再びデータの多くギガバイトは多分最終的に

2. 独自のドライブを必要とするため、各forum_idごとに1つのテーブルを作成し、そのようなデータを分割します。

私は問題を明確に説明している願っています。私は何知る必要があるのは、上記2つのうちどれが長期的にはよりよい解決策になるかである。アドバイスは何ですか？ディスadv。両方のケースのあなたの違いを

Answer 1

に感謝

は、最初のケースでは、あなたがシャーディングを行うためにMySQLをままにしておくことで、第2の場合には、あなたが自分でそれをやっています。 MySQLはデータを含まない断片をスキャンしませんが、クエリWHERE forum_id IN(...)がある場合は、いくつかの断片をスキャンする必要があります。私が覚えている限り、この場合の操作は同期的です。 MySQLは一度に1つのパーティションを照会し、非同期で実装することができます。一般的に、自分でパーティションを作成すると、より柔軟になりますが、forum_idに基づいて単純なパーティショニングを行う場合は、一度に1つのforum_idだけをクエリすると、MySQLのパーティション分割は問題ありません。

私のアドバイスは、パーティション化に関するMySQLのドキュメント、特にrestrictions and limitationsセクションを読んで、決定することです。

Answer 2

ここでは、あなたの質問のために良い答えを持っています、https://dba.stackexchange.com/a/24705/15243

基本的には、お使いのシステムは、成長させて、あなたがパーティショニングに慣れますが、お使いのシステムが本当に「バラバラにクロップ」する必要がある場合にそれを行いますパーティショニング。

Answer 3

3倍の空間縮小（およびおそらく高速化）のための迅速な解決策は、contentを圧縮してMEDIUMBLOBに入れることです。サーバーではなくクライアントで圧縮を行います。これにより帯域幅が節約され、多くのクライアントサーバー間で計算を分散することができます。

「シャーディング」は、複数のサーバー間でデータを分離しています。 MariaDBとSpiderを参照してください。これにより、サイズの拡大とパフォーマンスのスケーリングが可能になります。シャーディングを終えると、forum_idが最適かもしれません。しかし、これは、フォーラムが大きすぎて1台のサーバーに収まらないと仮定しています。

"パーティション分割"はデータを分割しますが、単一のサーバー内でのみ行います。あなたのユースケースに利点があるとは思われません。 forum_idによるパーティショニングはパフォーマンスを提供しません。

FOREIGN KEYsを削除します。代わりにアプリケーションをデバッグしてください。