MySQL разбиение или нет SQL как AWS DynamoDB? - PullRequest
Новая
       124

MySQL разбиение или нет SQL как AWS DynamoDB?

0 голосов
/ 31 января 2020

Бизнес-логика c:

Мое приложение сканирует множество (сотни, а иногда и тысячи) веб-страниц каждые несколько часов и сохраняет все ссылки (т.е. все теги привязки) на этом веб-страница в таблице базы данных MySQL, скажем, links. Эта таблица растет очень день ото дня (уже около 20 миллионов записей).

Технические данные:

У меня есть уникальный индекс, объединенный на [webpage_id, link] в таблице links. Также у меня есть столбец crawl_count в той же таблице. Теперь, когда я сканирую веб-страницу, я уже знаю webpage_id (внешний ключ к таблице webpages), и я получаю ссылки на этой веб-странице (то есть массив link), которые я просто делаю запрос вставки или обновления, не беспокоясь о что уже есть в таблице. 

INSERT INTO ........ ON DUPLICATE KEY UPDATE crawl_count=crawl_count+1

Проблема:

Таблица растет каждый день, и я хочу оптимизировать таблицу для производительности. Я рассмотрел следующие варианты:

  • Разделение: таблица разделов по доменам. Все веб-страницы принадлежат определенному домену. Например: веб-страница https://www.amazon.in/gp/goldbox?ref_=nav_topnav_deals принадлежит домену https://www.amazon.in/
  • Нет SQL, как DynamoDB. У меня есть другие таблицы приложений в MySQL DB, которые я не хочу переносить в DynamoDB, если это абсолютно не требуется. Также я рассмотрел изменение в логике приложения c (например: измените структуру таблицы webpages на что-то вроде 
{webpage: "http://example.com/new-brands", links: [link1, link2, link3]}

и перенесите эту таблицу в DynamoDB, чтобы у меня не было links таблица. Но, опять же, существует ограничение для каждой записи в DynamoDB (400 КБ). Что, если оно превысит этот предел?

Я прочитал за и против использования любого из подходов. Что касается моего Понимание идет, DynamoDB, кажется, не подходит для моей ситуации. Но все же хотел опубликовать этот вопрос, чтобы я мог принять правильное решение для этого сценария.

1 Ответ

0 голосов
/ 18 февраля 2020

PARTITION BY domain - Нет. Повышение производительности не будет. В любом случае, вы обнаружите, что один домен доминирует над таблицей, а миллионы доменов появляются только один раз. (Я говорю из опыта.)

Единственная концепция «массива» - это отдельная таблица. В вашем случае webpage_id и link будут иметь 2 столбца PRIMARY KEY (что является «уникальным»).

Normalize. Это сделано для того, чтобы избежать большого количества копий каждого домена и каждой ссылки. Это экономит место.

Я предполагаю, что у вас есть две категории ссылок: ссылки на отсканированные страницы и страницы, ожидающие сканирования. И, вероятно, два набора похожи по размеру. Я не понимаю цели подсчета сканирования, но это увеличивает стоимость.

Я мог бы посоветовать дополнительно, если увижу запросы - как вставку, так и выбор. Кроме того, насколько велики таблицы (ГБ) и каково значение innodb_buffer_pool_size? Собрав их вместе, мы можем обсудить возможные моменты, если вялость.

Также поможет медленный журнал.

Имеете ли вы дело с не-ascii URL? URL слишком длинные для индексации? Вы разделяете URL-адреса на домен + путь? Вы снимаете "# ..."? И "? ..."?

...