qovalenko

www.letmegooglethat.com/?q=%D0%A7%D0%B5%D0%BC+%D0%...

Низзя так.
Вы поступаете как поступали бы с реляционной СУБД типа MySQL и т.п.
Там связи между таблицами - это норма.

А Mongo их очень плохо обрабатывает.
В ней делают денормализацию.

Тут я присоединяюсь к grinat
Если уж вы методами предназначенными для реляционных СУБД работаете, то:

Правильно будет удалить mongo и поставить mysql/posgres

UPDATED:
qovalenko,

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

Это нормально.
Это следствие денормализации.
Это такая плата за плюсы Mongo.

Если хотите пользоваться нормальной формой, без дублей - то вам прямой путь к реляционным СУБД: PostgreSQL/MySQL/MS-SQL/Oracle и т.п.

Ведь NoSQL не просто так быстры и не просто так хорошо масштабируются.
Неужели вы думаете, что разработчики реляционных СУБД более 40 лет их создают и не могут добиться таких впечатляющих результатов, как за смешные 10 лет достигли NoSQL?

В Mongo и прочих NoSQL много чего урезанно по сравнению со строгими СУБД каковыми являются реляционными. И только это и позволяет им работать быстро и масштабироваться просто.

Но за все нужно платить.

Ну например, чего только стоит, что данные на серверах Mongo при репликации станут верными "когда-нибудь потом, но когда точно мы не знаем" Согласованные в конечном счете (Eventually Consistent)

Или же упомянутая вами проблема с тем, что необходимо отслеживать дубли при денормализации.

Я вам больше скажу - если вы не хотите чтобы производительность вашей системы проседала - то эти дубли вам придется устранять не сразу при изменении, а какой-то отдельной процедурой синхронизации, запускаемой, к примеру, раз в час. А в течении этого часа в одном части вашей Mongo будут одни данные, а в другой части - другие данные.

То, как вы хотите сделать - с нормализаций - в Mongo делать нельзя из соображений производительности и корректности работы транзакций.

Ну не предназначена она для этого. Именно это в Mongo и вырезано (точнее изначально не реализовано) по сравнению с реляционными СУБД.

Только в реляционных СУБД как раз всё можно сделать именно так, как вы и хотите (но там вы заплатите ограничениями при масштабировании).

Если проект не очень большой (скажем так: размеры данных на несколько терабайтов или меньше, что позволяет использовать 1 сервер для всех данных; и максимальное число серверов при репликации 2-3) - тогда реляционные СУБД будут весьма производительны и смысла в Mongo нет.

Вот здесь на видео все доходчиво объяснено - где у кого какие преимущества и какие недостатки:
Postgres vs Mongo / Олег Бартунов

Если же вам нравится Mongo, потому что она schemaless, то подобное уже есть и в PostgreSQL
"Умное" индексирование jsonb | Олег Бартунов, Ники...
Отныне вам необязательно все поля прописывать отдельно в CREATE TABLE (но желательно все же отдельно прописывать, через которые осуществляются связи между таблицами - то есть всяческие ID - чтобы оптимизатор запросов лучше работал)

Внимание, для этого в PostgreSQL используется тип данных JSONB, не путать с просто JSON

Если же вы хотите оставаться с Mongo, то делать нужно так, чтобы 1 запрос пользователя в вашем интернет-магазине (или что там у вас) в конечном итоге сводился к 1 запросу на извлечение данных из одной-единственной коллекции Mongo.

А это значит, что будет нужна денормализация, которая и означает дублирование данных. Что ведет к необходимости синхронизации дублей.

При этом, если изменение данных интенсивное, то синхронизацию дублей придется делать отложенную (по cron и т.п.), а не сразу в момент записи.

Это нормально в Mongo. Разработчики Mongo сами так и рекомендуют делать.

Возможно, но судя по вопросам вам еще во многом предстоит разобраться. Вряд ли вам кто-то будет тут писать конфиги nginx и вебпака.
Гуглите react/vue production build.
и скорее всего еще пригодится роутинг в аппах, history api и как настроить nginx чтобы он по всем роутам которые есть в приложении отдавал нужный js, а при обращении к css/картинкам - отдавал их.
еще есть codesplitting, чтобы грузились только нужные части приложения но для начала сделайте все одним js файлом, чтобы понять как оно все работает.

Просто я думаю если выполнить npm старт и скопировать build.js который вернется в index.html и запустить это в том же nginx с переадресацией маршрутов в index.html - то не получится то, что я планирую?

Вам надо настроить nginx чтобы он отдавал статику(шрифты, картинки, стили и прочее) и по всем не статическим маршрутам отдавал html с приложением.

db.collection.find({
  "data.param": {
       $gte: 1999,
       $lte: 2005
   }
})

const result = await db.collection("collection").findOne({colID: 1});
const res = await db.collection('collectiontwo').insertOne({title: result.title}); 
client.close();

https://www.youtube.com/watch?v=TkJzImzb3gM

Близкое.

Первый вопрос который меня интересует это PSR-0 или PSR-4. На сколько я понял по состоянию на 21 октября 2014 года PSR-0 был помечен как устаревший.

PSR-4 не замена PSR-0, а дополнением к нему.
github.com/php-fig/fig-standards/blob/master/accep...

про PSR-3 я вообще как-то не нашел русскоязычной информации, словно такого стандарта нет

Видать, не перевели. Читайте в оригинале:
github.com/php-fig/fig-standards/blob/master/accep...

/path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

Да, это пусть к PHP файлам проекта. Но index.php обычно выносят в отдельный каталог (например, /public), а все классы проекта хранятся, например, в /src (или /lib или ещё как угодно). В конфигурации веб-сервера запрещают отправлять запросы к любым файлам, не лежащим в /public, благодаря этому /public/index.php является единственной точкой входа для внешних запросов.

./vendor это папка назначение которой я не понимаю

Это папка для сторонних библиотек, используемых в вашем проекте. Используется composer'ом. Внутрь лезть особо причин нет, composer сам решит как ему там всё разложить. Свои классы вы туда тоже не должны писать.

в итоге честно говоря я запутался в том как правильно надо строить свои каталоги, какие папки обязательные какие нет, когда использовать src, когда lib, когда tests, почему в некоторых структурах приходится дважды указывать имя поставщика и имя пкета и т.д.

src и lib - скажем так, синонимы. Кому как больше нравится. Главное, что внутри лежат сами PHP файлы проекта, следующие стандарту PSR-4. Лежат там только файлы, написанные авторами проекта. Поэтому нет смысла класть vendor внутрь src (или lib).
test - каталог для тестов проекта.
В папке vendor имя поставщика и имя проекта могут совпадать, вот они и дублируются.

Так как вы изобретаете свой велосипед, то и структуру каталогов делайте свою, или посмотрите на популярные CMS/фреймворки, но везде будет по-разному. Joomla, WordPress, Yii, Zend Framework, Symfony.

Я придерживаюсь такой структуры:

/config                     Глобальные настройки проекта.
/data                       Временные файлы. Например:
/data/cache	            Файлы кеша.
/data/logs	            Логи.
/data/tmp	            Прочие временные файлы.
/module                     Модули проекта. Например:
/module/Backend	        
/module/Backend/config      Настройки модуля.
/module/Backend/src	    Файлы PHP модуля. Например:
/module/Backend/src/Backend/Path/To/ExampleClass.php
/module/Backend/test	    Unit-тесты модуля.
/module/Backend/view	    Шаблоны модуля.
/module/Frontend/...
/public/index.php
/public/css
/public/font
/public/img
/public/js
/vendor

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

На данный момент нашел для себя более удобный и просто вариант:

Docker Swarm + Traefik.

В существующих docker-compose.yml всего-навсего пришлось изменить build на image, прописать команды для предварительного сбора образов и добавить метки для traefik.

Через Swarm могу развернуть масштабиремые контейнеры на нескольких машинах, на которые (в нужный микросервис) будет перенаправлять Traefik согласно поддомену (метка traefik.frontend.rule=Host:...)

Вам нужен X-Forwarded-For: Traefik раз
Traefik два

Там же есть файл udc_predict.py с примером использования обученной модели для предсказаний