Vitsliputsli

У вас здесь 2 вопроса:
1) какую СУБД использовать, это полностью зависит от данных и как к ним планируется обращаться.
2) вы прям сразу хотите запилить шардирование, это вполне возможно на любой СУБД.

В шардировании основная проблема это когда нужно получить данные из многих шардов. Сперва проблема выбрать критерий шардирования, вы вроде бы его выбрали и у вас все легко делится по пользователям. Но остается момент формирования статистики и аналитики: вам нужно будет обращаться ко всем шардам, забирать из них данные и делать map-reduce. Очевидно, что ваше ПО должно позволять параллельно формировать запросы и обрабатывать их. А вот, миграции - это не проблема, наоборот чем меньше шарды, тем проще их делать.
Разумеется, у вас должна быть отлаженная полностью автоматизированная система деплоя, которая позволит накатывать те же миграции параллельно на множество шардов. Вам нужно будет создать систему map-reduce, а здесь уже интереснее, если вы будете оперировать малым кол-вом данных, то нет проблем, в противном случае вам придется подымать отдельную аналитическую СУБД и загружать в нее данные. Таскать по сети миллионы строк между разными машинами будет не весело.
И еще момент, не обязательно создавать на каждого пользователя отдельный шард, вы можете объединять их по какой-либо формуле, тогда не обязательно заводить миллионы шардов. Либо все же сделать миллионы шардов, но располгать скажем на 1 машине 1000 шардов, и вы сможете если понадобится изменять эту цифру.

Как все делают когда не умещаются данные на одном сервере? Применяют горизонтальное масштабирование.
Что если запросов очень много? Добавляют балансировщик.
А что если данных в БД полно? Делают репликацию. И вот тут вопрос.

Нет проблем уместить много данных на одном сервере (есть, конечно, BigData но это совсем про другое), проблема в том что при увеличении кол-ва данных в БД начинается деградация производительности СУБД, и примерно к 1млрд строк она проседает очень сильно (если кончено у вас строка это не 5 integer, а скорость ответа вы считаете в миллисекундах, а не в секундах). И в этом случае мы делим данные на разные СУБД, т.е. шардируемся.
Если очень много запросов чтение, то нет проблем поставить нужное кол-во слейвов и делить нагрузку между ними, т.е. реплицировать master.

Ну и, шардирование не такая простая вещь как кажется. Не стоит прям на старте ее впиливать, а вот подготовить данные для возможного деления на шарды стоит.

Vim - это текстовый редактор в первую очередь. Если же говорить про разработку, то в ней не нужно писать очень быстро очень много текста. А если вдруг, у вас так, то вы делаете что-то не то. Кодинг в разработке только одна из стадий и не самая длительная.
То что vim присутствует практически везде вообще не аргумент, vim без плагинов совсем не ide.
Тем не менее, попробуйте установить его как ide для вашего языка. Тогда выяснится, что нужно повеселиться с плагинами. Что обвес всем этим невелирует маленький быстрый редактор, и что скорость работы плагинов в разы тормознутей специализированного ide. Кто-то напишет, что я не те плагины брал, но устанавливать неофит будет так же, сделать это одной кнопкой не получится. Если цель не работать, а настраивать, то это отличный выбор.
Есть деньги на нормальную ide, то выбор очевиден, если нет, то все равно нужно 10 раз подумать.

У вас и во внешнем и во внутреннем цикле используется одна и та же переменная.

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

Сервисный слой или модели в MVC - это не класс, не объект. Это код отвечающий за доменную логику, там никто Single Responsibility не отменял, делите сущности по их ответственности, и создавайте столько классов, сколько необходимо.

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

Очевидно, что actions - это обычные контроллеры. Вообще, ADR - это тот же MVC, с абсолютно таким же делением на controller-action, model-domain, view-responder. Автор ADR утверждает, что там связи более правильные. Но в отличиях ADR от MVC, автор приписывает MVC какие-то ужасы, типа вьюха при желании лезет в модели что-то там запрашивает и т.п., чего в MVC нет и никогда не было. Такое ощущение, что автор ADR просто открыл для себя как правильно пользоваться MVC.

Это не должно быть проблемой для Mysql, это очень быстрая СУБД. С учётом, что это временные значения, которые не нужно хранить постоянно, то и классическая СУБД не нужна. Поэтому берите Redis. А Clickhouse это аналитическая СУБД, это здесь вообще не причём.

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

array_slice ничего не удаляет, он дает срез массива, поэтому такая формулировка не очень корректна. Исходя из этого, вы не сможете удалить элементы внутри существующего массива, и единственный вариант - это создание нового массива с выбранными значениям.

$numbers = [
    '123',
    '124',
    '125',
    '111',
    '222',
    '566',
    '777',
];

$cleanNumbers = [];
foreach ($numbers as $key=>$number) {
    // не нужно делать универсальным поиск нужных значений, т.к. он слишком специфичен, поэтому так:
    if ($number[0]===$number[1] && $number[1]===$number[2]) {
        // здесь проще было бы написать $cleanNumbers[] = $number;
        $cleanNumbers[] = array_slice($numbers, $key, 1); 
        // а если нужно все таки удаление, то достаточно unset($numbers[$i]) с противоположным условием
    }
}
var_dump($cleanNumbers);

В итоге, на кой здесь array_slice - мне совершенно не понятно.