AstonMartin

Linux всегда стремится занять свободную RAM чем-нибудь полезным. Приложениями, кешами, dirty-pages-ами.
В конкретно вашем случае можно покрутить настройки php-fpm-пула:
pm = dynamic
pm.max_children = 5 # максимальное количество воркеров вообще
pm.start_servers = 3 # количество воркеров при старте fpm
pm.min_spare_servers = 2 # минимальное количество неактивных воркеров
pm.max_spare_servers = 4 # максимальное количество воркеров
pm.max_requests = 200 # через сколько запросов перезагружать каждый воркер

Можно поставить spare поменьше, если к вам не приходит внезапная нагрузка - тогда память будет освобождаться.

Ничего из CMS, вообще. Для крутых проектов, больших, не используй cms, тем более бесплатные.

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

Уверен, что с этим справится любой фреймворк symfony/laravel/django и еще кучу других проверенных временем фреймворков.
Фреймворки это гибкость, тем более если есть "капуста"......

Имхо, тут нужна именно студия, а не какие-то отдельные спецы.
Потому что такому сайту нужен в первую очередь сильный фронт. Бэк-то у него простой, как табуретка, его кто угодно напишет на той же Ларе. А вот вылизанный интерфейс, удобный для пользователя и при этом не укладывающий бэк запросами - это задача. Да вы же еще дизайн захотите фильдеперсовый, узнаваемый, и нужно будет как-то совмещать красоты с функционалом. И если впрягать в это дело трех фрилансеров (дизайнера, фронтендера и бэкендера) - скорее всего, закончится по басне Крылова или по монологу Райкина.

без проблем
Если боитесь нагрузки то сделайте эти редиректы в 404.php
собственно в таком случае они будут срабатывать только когда к ним будут обращаться в остальных случаях они вообще не будут грузить систему. да и при переезде не нужно будет думать о них.
Ну и писать их в нем легче ;)

300 гб не очень маленькая, но и совсем не большая база. Вам нужно бы снять статистику по чтению/записи, посмотреть самые тяжелые запросы (такой функционал средствами mysql можно получить habrahabr.ru/post/31072/).
Выяснить чего именно не хватает - проца, оперативки, диска на запись, диска на чтение?
От этого уже и танцевать. может просто парочку ssd в рейд и хватит?

Если бы данные не нужно было обновлять - всё было бы очевидно, но ведь BigQuery не рассчитан на обновление данных - таких запросов (UPDATE) можно сделать всего 1000 в сутки, а это довольно мало, ведь если хоть раз у нас обновится больше тысячи строк из миллиона (а это 0.1%), смысла так работать с данными уже нет.

смотрите: если где-то сделано что-то именно ТАК, всегда думайте - а ПОЧЕМУ так?
и как только поймете - горизонты сознания расширятся и мир заиграет новыми красками

Бигквери не предназначен для Update - ну был курс доллара на сейчас 65,25 , а через секудну 65,26 - что вы обновлять тут собрались? фины позавчера стали чемпионами мира, тут что менять? пришел посетитель- вписался лог, потом еще один - а тут что обновлять? или он не пришел?

в BigQuery тупо складываете сырые данные, и обрабатываете их аггрегацией, оконными функциями и всем таким - вот так работу и постройте , не нужно копировать SQL базу

Можно использовать что-то наподобие перцептивного хэша, а для определения схожести между документом и набором других использовать поиск по СУБД при помощи расстояния Хэмминга.

По описанию задачи перекликается с вопросом Как сравниваются перцептивные хэши?

с точностью совпадения, допустим в 99%.

Вот посмотрите Как сравнить два текста в JS? . https://stackoverflow.com/questions/5042873/javasc...

Проверку на хеш в вашем случае тоже можно делать, т.к. pdf довольно редко редактируют и все передают одну и ту же книгу.

Есть несколько сотен тысяч PDF файлов.

Это реальная проблема или просто от нечего делать придумали? Слишком мало информации по самим документам. в некоторых сферах, где много типовых отчетов это обычное дело когда документ на 95% похож на другой, поменяться может например только одна цифра в дате, и такой документ нельзя будет отбраковывать. И из пдфа вы не всегда можете извлечь текст для сравнения. В общем довольно много подводных камней. Поэтому стоит более конкретно определиться с задачей.

upd: в общем есть еще такая особенность, что нужно правильно выбрать средство для извлечения текста, т.к. многие средства извлекают не всегда весь текст. Ну и еще интересно как быстро вы сравните 1 pdf со 200-300к других pdf, как по мне затраты на этот процесс будут слишком большими. Можно конечно сравнить только часть текста. Да кстати, извлечение текста из pdf медленный процесс, текст из некоторых страниц может извлекаться больше секунды на обычных процах (тестил на документах в 600-700 страниц), я пользовался только некоммерческими решениями, возможно вы найдете что-то быстрее, но парсить pdf вам придется явно не на ноде, т.к. это слишком медленно будет.

Хороший вопрос от автора.
Правильный ответ примерно такой:

Работать над оптимизацией внешних подключений важно. Асинхронность по умолчанию должна быть, но она не спасает от перегрузки основного потока.
У нас на проекте стоит не только Яндекс Метрика, Гугл Аналитика, пиксель ФБ, пиксель ВК, но и Hotjar и utmstat и они совершенно не мешают ничему. Подключать всё надо грамотно, откладывая по времени и по событиям. Если событие наступило, то счетчик времени отключается. Важно найти то время, на которое откладывать скрипт. Чтобы не поехали цели в метрике или в GA. Следите за приоритезацией загрузки, чтобы всё осталось в рабочем состоянии, но не влияло на скорость загрузки.

Подробно, как правильно подключать внешку, мы показывали с этой минуты: https://youtu.be/_3c0aPSkNdc?t=1480.
Там же есть пример скрипта обработчика.

Алексей из loading.express

Больно много текста, а надо лишь:
Не работать с мудаками, срок умножать на 3, деньги на 2.
Иногда ставить себя на место клиента.

Юзаю GitLab, потому что автоматический деплой и запуск тестов при пуше в ту или иную ветку делать удобней всего. Также удобно, что есть Registry, в котором можно хранить собранные Docker-образы. То есть Dockerhub не нужен. При том, что на Dockerhub можно, если не ошибаюсь, хранить только один приватный образ, а в GitLab-registry - сколько хочешь. Делать сборку образов можно тоже прямо в GitLab.

Upd: "делать удобней всего" - ЛИЧНО МНЕ (я не devops, а просто backend-разраб).

А в чём заключается прикладной результат описанной вами атаки? Нгинкс даже на минимальном железе может отдавать 404 ошибки гораздо с большей скоростью, чем 50 rps. Отключите логирование 404 ответов и, как советовали выше, включите fail2ban.

Имхо, это и атакой-то назвать нельзя - так, баловство...

Обычно камеры с солнечной батареей чисто облачные и RTSP у них нет. Так что надо собирать по частям. Модем + роутер + камера + солнечная батарея с АКБ и контроллером.

К камере пауэрбанк, далее колхозите солнечные банели.
Либо камеру питаем от ИБП, далее колхозите солнечные панели)

Может. Но с настройкой придётся повозиться, если вы хотите использовать wi-fi и как CPE и как AP. Например по 5Ghz получать сигнал, а по 2.4 раздавать на свои устройства. Надо ещё убедиться что там действительно 2 wi-fi модуля, а не 1 работающий либо так либо так.

https://fengyuanchen.github.io/cropperjs/