Как правильно хранить данные парсинга на сайте?

Question

[BushaevDenis]

Как будет правильно хранить большой объём данных парсинга, например у меня есть 5 тысяч ссылок, в каждой из которых таблица в 5 колонок, 5000 строк.
И каждую ссылку нужно будет парсить раз в n-дней, и сохранять результат не удаляя старый.
Т.е в итоге получится очень и очень много данных.
Как правильно будет хранить все эти данные?

Comments

[sim3x]

бд нормализована?

[BushaevDenis]

sim3x: Я только начал постигать. Вряд ли я смогу ответить на этот вопрос. (Вики уже почитал, мало что понял)

[BushaevDenis]

sim3x: Пока что у меня в базе хранится не так много данных. Можно считать, что она 6НФ(Если я всё правильно понял из статьи).

[sim3x]

BushaevDenis: НФ не зависит обьема

[BushaevDenis]

sim3x: Правильно, она зависит от данных. Пока что у меня мало таблиц и всё более-менее разложено по полочкам. Как будет в итоге - хз)

[sim3x]

по сути у тебя две таблицы

Link
  id
  link

Results
  id
  link_id
  text
  datetime

= 3НФ

[sim3x]

BushaevDenis:
НФ не зависит обьема данных
НЕ зависит

[BushaevDenis]

sim3x: т.е все данне хранить в 1 ячейке? Потом когда нужно будет их представлять - опять парсить эту ячейку, чтоб в нормальном виде юзеру показать?

[sim3x]

BushaevDenis: а вот ето уже зависит от ТЗ
Что нужно хранить и как хранить

В простом случае - лучше хранить страницу у себя в виде файла

Answer 1

[Everything_is_not_so_bad]

Наверно нужно применять тот же подход, что и в системах контроля версий. Тогда каждый результат одного URL можно обновлять (commit), не затирая предыдущего. При этом место в БД будет увеличиваться на дельту (diff).

Answer 2

[igruschkafox]

5000 * 5000 = 25 000 000

раз в день обновляем все ссылки
25 000 000 * 365 = 9 125 000 000 000 в год

Да, для одной таблицы это пожалуй многовато
Рекомендую поступить так
хранить данные в двух таблицах
в первой 25 000 000
во второй (архивной) все записи которые были раньше - до обновления
то есть вся история изменений у Вас будет во второй таблице
Соответственно секционировать архивную таблицу примерно по 2 недели

Таким образом Вы добьетесь что актуальные данные будут доставаться быстро
Архивные подольше - но это и понятно

Потом данные за прошлые периоды можно бэкапить оставляя только последние записи изменений (например хранить в архиве только данные за полгода)

В случае необходимости - всё можно достать и посчитать,
но практика говорит что такие бешеные объемы если и доставать то они считаться будут очень долго, а ввиду давности времени зачастую бывают неактуальны. По прошлогодним ссылкам явно никто аналитику проводить не будет.

Comments

[dez64ru]

А если это парсинг яндекс вебмастера?) Как раз нужна наиболее подробная статистика за довольно длительный период.

[igruschkafox]

Тогда предлагаю как то кластеризовать ссылки
то есть создаем таблицу ссылок в этой таблице поле с номером хранилища (например номер репозитория 1,2,3,4,5)

и разделяем хранение по 5 актуальным таблицам
и соответственно 5 архивным таблицам

Тогда Вы от проблемы бэкапирования не избавитесь - но сможете в архиве держать больше данных в архиве

П.С.
Блин 9 триллионов строковых значений это у Вас диски раньше закончатся, чем Вы начнете что то анализировать

[dez64ru]

igruschkafox: Я погоречился с обновлением в каждый день. Раз в месяц буду обновлять. Решил не парится с БД и записывать всё в xlsx, в бд буду заносить только данные по "количеству запросов в топе".

[igruschkafox]

dez64ru: прой пересмотреть бизнес логику тоже полезно :)