tl;rd:
- Разделение БД с помощью первичного ключа
- Проблема размера индекса.
- Размер БД увеличивается примерно на 1-3 ГБ в день.
- Настройка рейда.
- У вас есть опыт работы с Hypertable?
Длинная версия:
я только что построил/купил домашний сервер:
- Ксеон E3-1245 3,4 НТ
- 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 hdds Raid 10 (база данных MYSQL) и 2xhdds Raid 0 для (индексы OS/Mysql).
(Если рейд 0 сломается, для меня это не проблема, мне нужно только защитить БД)
О БД:
Это база данных поискового робота, где хранятся домены, URL-адреса, ссылки и тому подобное. Поэтому я решил разбить БД с первичными ключами каждой таблицы, например (1-1000000) (1000001-2000000) и так далее.
Когда я выполняю поиск/вставку/выбор запросов в БД, мне нужно сканировать таблицу отверстий, потому что некоторые вещи могут быть в ROW 1, а другие в ROW 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
Я вижу, что могу исправить externlink & индексы ссылок, я просто добавил externlink, потому что мне нужно было запросить это поле, и я не смог использовать индекс ссылок. Вы видите, что я мог бы настроить на индексы? Моя новая система будет иметь 32 ГБ, но если БД будет расти с такой скоростью, я буду использовать 90% оперативной памяти за НЕСКОЛЬКО недель/месяцев.
Помогает ли упакованный ИНДЕКС? (Как снижается производительность?)
Другие важные таблицы меньше 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/ ‹= Google Bigtables. Если я перейду на Hypertables, поможет ли это мне в производительности (извлечение данных/поиск/вставка/выбор и размер БД). Я читал на странице, но я все еще не знаю. Потому что вы не можете напрямую сравнивать MYSQL с Hypertables. Я попробую это в ближайшее время, сначала нужно прочитать документацию.
Что мне нужно, решение, которое подходит для моей установки, потому что у меня не осталось денег на любую другую настройку оборудования.
Спасибо за помощь.
