He11ion

БД понятие растяжимое.
Варианта 3, в зависимости от критичности данных:
1 - важные данные, вроде транзакций пользователей - БД с ACID - postgre/mysql/etc
2 - умеренно важные - redis/rabbitmq - если у вас отключают свет не раз в день - вполне нормально, обе сохраняют на диск периодически
3 - ну и если какая-то статистика например, где +-1000 записей не критична - вообще наплевал
Ну и сервер в нормальном датацентре не падает от электричества, да.

Elastic выглядит как оверкилл тут, вполне реально обойтись просто mysql, просто не удаля данные/записывая их в таблицу. Ну и "довольно много" это очень разные понятия могут быть.
Скорость обработки elastic и mysql сравнивать не совсем корректно, elasticскорее для (не)четкого поиска по данным - если есть четкое понимание по какому полю будете искать(например по ид товара) - то mysql ничуть не хуже и значительно проще в настройке и эксплуатации

проблема в том, что rest подразумевает http запросы в любом случае, внутри проекта это может давать излишний overhead, однако это позволяет легко организовать микросервисную архитектуру/выдать наружу часть api, так что выбор есть

Традиционный ответ - либо переносите все максимально близко (в идеале 1 ДЦ вообще), либо по-максимуму кэшируйте все, что приходится доставать с удаленной БД, либо поднимайте зеркало на локальной машине с малокритичными данными, уменьшая кол-во передаваемого по сети.
Ну или все это сразу.

https://codility.com/

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

Но имхо - это лишнее. Базу выгоднее/легче продать кому-то, кто работает с ней и в курсе кому из конкурентов эта база будет интересна. Левому фрилансеру фиолетово что у вас там хранится.

Еще NDA можно подписать для собственного успокоения.

Писать, скажем, в сессию, а во втором файле вставлять в input в value. Сохранять значения как угодно - через сабмит формы/аяксом/средствами браузера.

https://dev.mysql.com/doc/refman/5.6/en/load-data.html
Стандартный способ загрузки больших объемов.

"Сервер не справляется" - скорее всего памяти не хватает, разбивайте на куски, влезающие в память/выделяйте больше ее если так необходимо через Yii

Никак, это нормально.

попробуйте nginx -t , возможно через sudo (зависит от настроек доступов к файлам)

Сильно зависит от того, что за приложение, но мое мнение - нет, это "железо" на уровне смартфона старенького.
Как совет - попробуйте задеплоиться в облако и иметь возможность как раз под такие случаи резко увеличивать мощность железа.

supervisord вам в помощь.

Вкратце - исторически/стандарты. Длиннее тут, напрмер - unix.stackexchange.com/questions/18743/whats-the-p...

SIGNAL? Ну и https://github.com/mysqludf/lib_mysqludf_log

Физтех без вариантов, если осилите. Ну и 25 минут до центра - это совсем не много по московским меркам