Как лучше реализовать хранение данных в БД? Какой стек технологий выбрать?

Question

[John Smith]

Кратко опишу суть проекта.

Есть дистрибьютор, который реализует товар (скажем, 300 наименований) пятидесяти другим мелким фирмам-оптовикам, у каждой из которых есть свой сайт. Дистрибьютор желает регулярно (каждый день) парсить эти 50 сайтов, преследуя следующие цели:

1. Контроль демпинга цен.
   
2. Возможность видеть динамику изменения цен на свой товар.
   

Немного о себе: есть опыт написания веб-скрейперов на Node.js (1 год). Есть небольшой опыт работы с noSQL базой данных RethinkDB (1 проект).

Проект будет состоять из:

1. Собственно, веб-скрейпер.
   
2. Небольшая админ-панель на локалхосте.
   

Админ-панель будет состоять из:

1. Главная страничка, с которой осуществляется управление скрейпером: "старт", "пауза", "стоп", "загрузить новые данные о товарах" (загрузить .csv файл со списком точных наименований товаров и их стоимостью; по умолчанию будет использоваться последний загруженный файл). Также на главной страничке будет отображаться ход парсинга в виде лоадера (реализую это через socket.io), а по окончании парсинга - краткая сводка с результатами (на каких сайтах продается товар ниже себестоимости).
   
2. Страничка со списком всех товаров в следующем виде: слева товар, справа - график (chart.js) средней цены на этот товар за последний месяц.
   
3. Можно кликнуть по товару и перейти на страницу с этим товаром, которая содержит следующую информацию: графики цен на каждом из 50 сайтов (lazy loading) за последние N дней.
   
4. Можно кликнуть по любому из сайтов и перейти на страничку с соответствующей информацией: слева товары, справа - графики цен на товар на данном сайте за последние N дней.
   

Реализовать весь бэкенд планирую в следующем виде: server.js, который будет хостить админпанель и который будет запускать менеджер парсеров manager.js (через child_process.fork()), который в свою очередь будет форкать 50 парсеров (firstsitecom.js, secondsitecom.js, ...). Зачем столько форков? Почему просто не сделать это через module.export? Для того, чтобы ошибка в одном из парсеров не положила всю систему. Так, я буду иметь возможность при выходе из строя одного из модулей просто перезапустить его, либо игнорировать и парсить дальше.

И, наконец-таки, сам вопрос, точнее, два:

1. Как лучше реализовать хранение данных в БД? Может быть, создать таблицу на каждый из пятидесяти сайтов, или лучше создать по таблице на каждый товар? За любой подробный ответ буду очень благодарен.
   
2. Какой стек технологий лучше всего подойдет? Я пока остановился на MEAN: Node.js, Express, Angular 2 (прошел туториалы PhoneCat и Hero на оф. сайте, вроде всё понятно, но смущает его монструозность и TypeScript), MongoDB (похожа на RethinkDB). Если у Вас есть советы касательно выбора стека, буду раз узнать их.
   

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

Возможно, Вам есть что сказать, либо на ум пришли какие-то полезные ссылки. Буду рад любому ответу. Спасибо.

Answer 1

[4X_Pro]

А зачем такое делать на NoSQL? Тут реляционные базы вполне подходят.
Я бы вообще ограничился тремя таблицами:
1) сайт
2) товар вообще (по сути, там хранится только его id и наименование)
3) товар на конкретном сайте (тут хранится id товара, id сайта, цена, дата парсинга).

Comments

[John Smith]

Спасибо за ответ!
Я выбрал noSQL, т.к. это единственный тип баз данных, с которым я реально работал (RethinkDB). Увы, с MySQL и подобными я не имею опыта, хоть и знаю немного язык SQL.
Как я понял, вы предлагаете следующее:
1. Таблицу, содержащую список сайтов и их ID
2. Таблицу товаров и их ID
3. Таблицу с результатами парсинга
Итого, в последней таблице за один запуск (день) окажется 300 (товаров) * 50 (сайтов) = 15 000 записей. За месяц 450 000 записей и за год - 5 400 000 записей.
Как Вы считаете, через год работы, много ли времени будет занимать один запрос, который, допустим будет возвращать стоимость определенного товара на определенном сайте за год (365 записей)?

[4X_Pro]

John Smith: Да, вы поняли все правильно. А чтобы время выборки было небольшим, нужно корректно настроить индексы в этих таблицах. В принципе, для реляционных баз данных 5 млн записей — не такой уж большой объем, особенно если нет ситуаций параллельного чтения и записи множеством пользователей.
Вариант «один товар — одна таблица», в принципе, тоже возможен, но очень неудобен в плане возможного расширения (вдруг потребуется новый товар добавить), а по быстродействию по сравнению с нормально индексированной таблицей разница будет не особо велика.

[John Smith]

4X_Pro: Спасибо, значит, так и сделаю. Что стоит почитать по теме правильной настройки индексов?

[4X_Pro]

Лучше всего общую теорию по реляционным базам. Но если нет времени и желания, то и так могу сказать, какие индексы нужны: на первые две таблицы — по ID товара и сайта, на третьей — первичный ключ из трех столбцов вида (ID_товара, ID_сайта, дата) и еще пара индексов — (ID_сайта, дата), (ID_товара, дата).

[John Smith]

4X_Pro: Отлично, спасибо!

[heducose]

John Smith: я правильно вас понимаю - вы прочитали один коммент в интернете от рандомного человека и это изменило ваш выбор?

4X_Pro: а почему не сделать это на noSQL? Где хоть один довод, кроме "вполне подходят"? Честно, интересно.

[John Smith]

heducose: Нет, я по-прежнему собираюсь делать это на MongoDB либо на RethinkDB. 4X_Pro написал полезный совет касательно индексации. Индексация есть как в SQL, так и в noSQL базах данных, так что противоречия не вижу.

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