Maxxdev

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.

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

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Попробуйте следовать https://www.atlassian.com/ru/git/tutorials/compari...

К проблеме которую вы описали:

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

Не сливайте feature-ветку пока она не будет полностью протестирована и code-rewiew'ирована.
Склеивайте комиты в feature-ветке, чтобы их в итоге было не больше 1-3.

Из собственного опыта могу сказать, что чем крупнее и неспешнее проект - тем проще следовать git-flow.
А вот когда 1-2 разработчика и нужно вот сейчас ещё вчера запилить 10 фич... бывает сложновато.

Это вопрос дисциплины и организованности. Как ставятся задачи, как вы фокусируетесь на текущей фиче (нельзя носиться по всему проекту и фиксить по пути всё что под руку попалось). Организации самого проекта в конце концов - как изолированы компоненты и т.д.

https://git-scm.com/book/en/v2

По этому вопросу очень долго искал ответа))
Вам уже скинули статью по независимым модулям, но этого мало. Что вам нужно:

1. Независимый слой MODEL.
В этой папке находятся Use Case (Service), Сама сущность Entity (AR), Желательно иметь репозитории для изоляции от базы данных ну и другой доменный слой логики, который не зависит ни от чего. Ни от фреймворка, ни от других модулей и пакетов. Ваша задача написать код в этой части так, чтобы его можно было скопировать в любую папку, настроить зависимости и чтобы этот код заработал хоть на чистом PHP. Если не планируете менять фреймворк, то можно зависить от фреймворка.

2. Зависимости
Все зависимости модуля реализовать либо через Interface либо через события, но события лучше. А дальше уже синхронизируйте через приложение или отдельный модуль. Можно и по api.

3. UI (пользовательский интерфейс)
Он может быть зависимым от других модулей. В него входят: контроллеры, view, формы, vue.js и так далее. В общем то, с чем взаимодействует пользователь.

Тем самым получается такая система если опираться на MVC:
VC - могут быть зависимы от других модулей
M - не может быть зависима ни от чего, кроме PHP. Желательно и отделять слой базы данных с помощью Repository. Тогда ваш пакет будет очень сильно независим даже от базы. И вам вообще будет без разницы куда вы это храните в user или employee.

Если будет такой слой, то можно спокойно переносить хоть на будущий Yii3. Однако На Yii1 и Yii2 такое сделать сложно. Надо изворачиваться и займет это больше времени. Так как сам Фреймворк вставляет нам палки и приходится делать костыли из-за его монолитности. К такому подходу не привыкли Yii1 и Yii2 разработчики. Обычно на Yii такое понимание «фигак, фигак и в продакшн».

Такую архитектуру удобно будет строить на Symfony ну и будущем Yii3.

Рекомендую к прочтению:

• Мастер-класс Интернет-магазин на Yii2
  
• Создание архитектуры программы или как проектирова...
  
• https://www.yiiframework.ru/forum/viewtopic.php?f=...
  
• https://habr.com/ru/post/329286/
  

Есть 3 типа счётчиков:
1. Public
2. ALL Registered Users
3. Current User
Приоритет важности актуализации значения счётчика, соответственно, обратный.

1. Для Public - обычно, суммарный сбор данных по крону (+читает счётчики системного пользователя).
2. Для ALL Registered Users - обновляет системный пользователь по своим событиям (+читает счётчики пользователей).
3. Для Current User - обновляет этот пользователь свои счётчики по своим событиям (+читает только свои счётчики).

Таким образом идёт восходящий подсчёт различных значений счётчиков с разным приоритетом и размеренной нагрузкой.

Обновление своего счётчика по событиям: любое действие, требующее подсчёт - это запрос в БД для самого действия и в этом же запросе - смена значения нужного параметра в таблице счётчиков конкретного типа счётчика (из трёх, выше указанных).

PS: И, Вас, тоже, с наступающим!

картинка в PDF остается картинкой

см. https://wkhtmltopdf.org/ для html в pdf и ее обертки

Уменьшите битрейт и разрешение видео.
Переместите метаданные в начало mp4 контейнера
Установите preload="metadata"
htmlbook.ru/html/video/preload

Чтобы пиксели в глаза не бросались наложите на видео сеточку из маленьких черных точек
https://jsfiddle.net/soumyabg/wefLyrhp/
css background dotted overlay

Пример

Никогда не разрабатывайте в master бранче! Всегда делайте отдельную ветку git checkout -b new_branch_baby

Чтобы сейчас выйти из этой неловкой ситуации вам нужно:
- Скопировать все изменения в отдельный бранч ( git checkout -b my_changes )
- Почистить мастер от своих изменений ( git checkout master ; git rebase -i HEAD~6 )
- обновить мастер бранч ( git pull origin master )
- обновить свой бранч (git checkout my_changes ; git rebase master )

удачи

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).