В какой базе хранить и делать поиск при url >100M записей?

Question

[cryptodoxer]

Есть постоянно пополняемая база url. Растет в день на 7-10 миллионов записей.
Сейчас это просто MySQL. Без хеша урла. До 200М записей и размера базы менее 100GB еще живет, далее новые вставки и селекты уже очень медленные на очень хорошем железе.

Куда копать, что выбрать для хранилища?!

Сервер: 32х ядерный xeon - 64gb ram. ssd - 512, centos

CREATE TABLE `url` (
  `id` bigint(10) UNSIGNED NOT NULL,
  `source_id` int(10) UNSIGNED NOT NULL,
  `url` varchar(255) NOT NULL,
  `checked` enum('one','two') NOT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `url`
  ADD PRIMARY KEY (`id`),
  ADD UNIQUE KEY `url` (`url`),
  ADD KEY `checked` (`checked`),
  ADD KEY `source_id` (`source_id`),
ALTER TABLE `url` ADD FULLTEXT KEY `url` (`url`);

ALTER TABLE `url`
  MODIFY `id` bigint(10) UNSIGNED NOT NULL AUTO_INCREMENT;
COMMIT;

фуллтекст - потому что без него вставка медленная после 30 лямов урлов
вставляется так:

$sql = $db->queryBuilder->batchInsert('url', array('url',  'source_id'), $urlInsert);
                    $db->createCommand($sql . ' ON DUPLICATE KEY UPDATE url=url')->execute();

медленная вставка - это когда запрос такой что выше на 20-30к урлах выполняется более 30 секунд.

Comments

[Yan-s]

А какая структура таблицы и какие запросы?

[cryptodoxer]

Yan-s, структура очень простая,
id, url unique, source_id (источник)

медленно при добавлении(инсерте) уникальных записей и выборке каких то данных по source_id

[Никита]

Индексы используете?

[sim3x]

cryptodoxer,
опишите железо
опишите как и чем вставляете
опишите таблицу полностью - тип полей тип индекса и тд
опишите насколько замедляется вставка
опишите свои пожелания на скорость/время вставки
опишите юзкейс самой таблицы

[cryptodoxer]

Никита, конечно. индексы весят размером с базу(

[cryptodoxer]

sim3x, 32х ядерный xeon - 64gb ram. ssd - 512, centos

CREATE TABLE `url` (
  `id` bigint(10) UNSIGNED NOT NULL,
  `source_id` int(10) UNSIGNED NOT NULL,
  `url` varchar(255) NOT NULL,
  `checked` enum('one','two') NOT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE `url`
  ADD PRIMARY KEY (`id`),
  ADD UNIQUE KEY `url` (`url`),
  ADD KEY `checked` (`checked`),
  ADD KEY `source_id` (`source_id`),
ALTER TABLE `url` ADD FULLTEXT KEY `url` (`url`);

ALTER TABLE `url`
  MODIFY `id` bigint(10) UNSIGNED NOT NULL AUTO_INCREMENT;
COMMIT;

[sim3x]

cryptodoxer, зачем на урл FULLTEXT KEY ?

Ну и ответы на другие мои вопросы добавьте в текст вопроса

[cryptodoxer]

sim3x, фуллтекст - потому что без него вставка медленная после 30 лямов урлов
вставляется так:

$sql = $db->queryBuilder->batchInsert('url', array('url',  'source_id'), $urlInsert);
                    $db->createCommand($sql . ' ON DUPLICATE KEY UPDATE url=url')->execute();

медленная вставка - это когда запрос такой что выше на 20-30к урлах выполняется более 30 секунд.

[Everything_is_not_so_bad]

cryptodoxer, какие запросы медленны с select? Какие типичные примеры запросов?

Answer 1

[Andrey Shatokhin]

У нас подобное использование есть. Тоже больше милиарда урлов. Используем elasticsearch. Без анализаторов морфологии конечно.

Comments

[cryptodoxer]

Как быстро вставка и сколько занимает на диске?!

[Andrey Shatokhin]

cryptodoxer, вставка у нас очень быстро. используем refresh_interval в 5s. Обычно на этом индексе не более 2к/c индексаций. Во время реиндекса бывает до 100к/c
У нас там хранятся не только урлы но и еще довольно много числовых данных. на 1ккк документов уходит примерно 400-450Гб + реплики.