tl; rd:
- Секционирование БД с помощью первичного ключа
- Проблема с размером индекса.
- Размер БД увеличивается примерно на 1-3 ГБ в день
- Raid setup.
- У вас есть опыт работы с Hypertable?
Длинная версия:
Я только что собрал / купил домашний сервер:
- Xeon E3-1245 3,4 HT
- 32 ГБ ОЗУ
- 6x 1,5 ТБ WD Cavier Black 7200
Я буду использовать Серверная плата INTEL S1200BTL Raid (нет денег на контроллер рейда).http://ark.intel.com/products/53557/Intel-Server-Board-S1200BTL
Системная плата имеет 4 порта SATA 3 ГБ / с и 2 порта SATA 6 ГБ / с
Я пока не уверен, смогу ли я настроить все 6 жестких дисков в RAID 10,
если не возможно, я подумал, что 4x HDD Raid 10 (MYSQL DB) и 2xhdds Raid 0 для (OS / Mysql индексы).
(Если рейд 0 не работает, для меня это не проблема, мне нужно только защитить БД)
О БД:
Это веб-сканер БД , где хранятся домены, URL, ссылки и тому подобное.Поэтому я подумал, что я разделю БД с первичными ключами каждой таблицы, например (1-1000000) (1000001-2000000) и так далее.
Когда я выполняю поиск / вставку / выбор запросов в БД, мне нужно сканировать таблицу отверстий, потому что некоторые вещи могут быть в строке 1, а другие в строке 1000000000000.
Если ясделать такой раздел по первичному ключу (auto_increment) будет ли это использовать все мои ядра процессора ?Чтобы он сканировал каждый раздел параллельно ?Или я должен придерживаться одной огромной БД без раздела.
БД будет очень большой, в моей домашней Системе сейчас ее,
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
Я вижуя мог исправить внешние ссылки и индексы ссылок , я просто добавил внешние ссылки , потому что мне нужно было запросить это поле, и я не смог использовать индекс ссылок.Вы видите, что я мог настроить на индексы?Моя новая система будет иметь 32 ГБ, но если БД будет расти с такой скоростью, я буду использовать 90% ОЗУ в несколько недель / месяцев.
Помогает ли упакованный INDEX ?(Как снижается производительность?)
Другие важные таблицы не превышают 500 МБ.
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).
Из этой таблицы можно удалить данные, когда я извлеку все, что мне нужно.
Есть ли у вас опыт работы с Hypertables ?http://hypertable.org/ <= Googles Bigtables.Если я перейду на Hypertables, это поможет мне в производительности (извлечение данных / поиск / вставка / выбор & <strong>Размер БД ).Я читаю на странице, но я все еще немного невежественна.Потому что вы не можете напрямую сравнить MYSQL с Hypertables.Я попробую это в ближайшее время, должны сначала прочитать документацию.
Что мне нужно, решение, которое вписывается в мои настройки, потому что у меня нет денег на другие установки оборудования.
Спасибо за помощь.