0

選択クエリを使用して数十億のレコードを処理しているときに、パフォーマンスの問題があります。

CREATE TABLE `temp_content_closure2` (
  `parent_label` varchar(2000) DEFAULT NULL,
  `parent_code_id` bigint(20) NOT NULL,
  `parent_depth` bigint(20) NOT NULL DEFAULT '0',
  `content_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  KEY `code_content` (`parent_code_id`,`content_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY KEY (parent_depth)
PARTITIONS 20 */ |

テーブルを細分化することでパフォーマンスを向上させるパーティションを使用しましたが、私の場合は役に立ちません。このテーブルでサンプルを選択します

+----------------+----------------+--------------+------------+
| parent_label   | parent_code_id | parent_depth | content_id |
+----------------+----------------+--------------+------------+
|  Taxonomy |          20000 |            0 |        447 |
| Taxonomy |          20000 |            0 |       2286 |
|  Taxonomy |          20000 |            0 |       3422 |
| Taxonomy |          20000 |            0 |       5916 |
+----------------+----------------+--------------+------------+

ここで、content_id は parent_dept に関して一意になるため、parent_depth をパーティショニングのキーとして使用しました。すべての深さで、2577833 行を処理する必要があるため、ここではパーティショニングは役に立ちません。Web サイトからアーカイブ ストレージ エンジンを使用するアイデアを得ました。ただし、フルテーブルスキャンを使用し、選択でインデックスを使用しません。基本的に99％、このテーブルで選択クエリを使用し、このテーブルは毎日カウントを増やします.現在、バージョン5.0.1のmysqlデータベースにいます.i使用するnosqlデータベースについてのアイデアを得ましたが、mysqlで処理する方法はありますか.nosqlを提案している場合、cassandraまたはaccumuloのどちらを使用できますか?.

4

2 に答える 2

0

そのサイズと量のデータでは、マシンのクラスタにシャードされた MySQL セットアップをセットアップする必要があります (Facebook と Twitter は、シャードされた MySQL セットアップに大量のデータを保存したため、可能です)。さまざまなクラスター内のノード間でデータをネイティブに分散する Big Table ベースのソリューション - ここでは Cassandra と HBase が最も一般的な代替手段です。1 台のマシンに 10 億件のレコードがあると、システムのほぼすべての制限に達することを認識しておく必要があります。最初に IO、次にメモリ、次に CPU が続きます。それは単に実現不可能です。

Big Table を採用する場合は、Cassandra が最も迅速にセットアップとテストを行うことができます。ただし、map-reduce タイプの分析のニーズが予想される場合、HBase は Hadoop エコシステムとより緊密に統合されており、うまく機能するはずです。パフォーマンスに関しては、どちらも互角なので、どちらかを選んでください。

于 2013-09-27T11:40:52.037 に答える
0

次のようにインデックスを追加します。

ALTER TABLE table ADD INDEX content_id ('content_id')

より具体的な SELECT 基準がある場合は、複数のインデックスを追加して速度を上げることもできます。

複数インデックスと単一インデックス

全体として、このようなテーブルが非常に急速に成長している場合は、SQL 設計の再構築を検討する必要があります。

「ビッグデータ」ソリューションもご覧ください。

于 2013-09-27T05:25:05.217 に答える