通称:
- 主キーによる DB パーティショニング
- インデックス サイズの問題。
- DB サイズは 1 日あたり約 1 ～ 3 GB 増加します
- レイドのセットアップ。
- ハイパーテーブルの経験はありますか?
長いバージョン:
ホームサーバーを構築/購入しました：
- Xeon E3-1245 3,4 HT
- 32GBのRAM
- 6x 1.5 TB WD Cavier Black 7200
Server Board INTEL S1200BTL Raidを使用します(Raid コントローラーを購入するお金はありません)。http://ark.intel.com/products/53557/Intel-Server-Board-S1200BTL
メインボードには、4x SATA 3GB/s ポートと 2x SATA 6GB/s ポートがあります。
RAID 10 で 6 台すべての HDD をセットアップできるかどうかはまだわかりませんが、
不可能な場合は、4x hdds Raid 10 (MYSQL DB) & 2xhdds Raid 0 (OS/Mysql インデックス) を考えました。
(RAID 0 が壊れても問題ありません。DB を確保するだけで済みます)
DBについて：
ドメイン、URL、リンクなどが保存されるWebクローラー DBです。したがって、(1-1000000) (1000001-2000000) などの各テーブルの主キーでDBを分割すると考えました。
DBで検索/挿入/選択クエリを実行するとき、ホールテーブルをスキャンする必要があります.ROW 1にあるものとROW 1000000000000にあるものがあります.
主キー (auto_increment) でこのようなパーティションを作成すると、すべての CPU コアが使用されますか? 各パーティションを並行してスキャンするように？または、パーティションなしで 1 つの巨大な DB に固執する必要があります。
DBは非常に大きくなります。現在、私のホームシステムでは、
Table extract: 25,034,072 Rows
Data 2,058.7 MiB
Index 2,682.8 MiB
Total 4,741.5 MiB
Table Structure:
extract_id bigint(20) unsigned NO PRI NULL auto_increment
url_id bigint(20) NO MUL NULL
extern_link varchar(2083) NO MUL NULL
anchor_text varchar(500) NO NULL
http_status smallint(2) unsigned NO 0
Indexes:
PRIMARY BTREE Yes No extract_id 25034072
link BTREE Yes No url_id
extern_link (400) 25034072
externlink BTREE No No extern_link (400) 1788148
Table urls: 21,889,542 Rows
Data 2,402.3 MiB
Index 3,456.2 MiB
Total 5,858.4 MiB
Table Structure:
url_id bigint(20) NO PRI NULL auto_increment
domain_id bigint(20) NO MUL NULL
url varchar(2083) NO NULL
added date NO NULL
last_crawl date NO NULL
extracted tinyint(2) unsigned NO MUL 0
extern_links smallint(5) unsigned NO 0
crawl_status tinyint(11) unsigned NO 0
status smallint(2) unsigned NO 0
INDEXES:
PRIMARY BTREE Yes No url_id 21889542
domain_id BTREE Yes No domain_id 0
url (330) 21889542
extracted_status BTREE No No extracted 2
status 31
externlink とリンク インデックスを修正できることがわかりました。externlinkを追加したところ、そのフィールドをクエリする必要があり、リンク インデックスを使用できませんでした。わかりますか、インデックスで何を調整できますか? 私の新しいシステムは 32 GB になりますが、DB がこの速度で成長する場合、RAM の 90% を数週間/月で使用します。
パックされたINDEXは役に立ちますか? （パフォーマンスの低下はどうですか？）
他の重要なテーブルは 500MB 未満です。
Only the URL Source table is huge: 48.6 GiB
Structure:
url_id BIGINT
pagesource mediumblob data is packed with gzip high compression
Index is only on url_id (unique).
必要なものをすべて抽出したら、このテーブルからデータを消去できます。
ハイパーテーブルの経験はありますか? http://hypertable.org/ <= Google の Bigtable。ハイパーテーブルに移行すると、パフォーマンスが向上しますか (データの抽出/検索/挿入/選択 & DB サイズ)。私はページを読みましたが、まだ無知です。MYSQL と Hypertables を直接比較することはできません。すぐに試してみます。最初にドキュメントを読む必要があります。
私が必要としているのは、私のセットアップに適合するソリューションですが、他のハードウェアのセットアップにお金が残っていないためです。
手伝ってくれてありがとう。