Андрей Павленко

А вот и вопрос: а нужно ли вообще настраивать кластер Clickhouse между собой, если сервера должны, как я понимаю, синхронизироваться между собой с помощью ZooKeeper?

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

Если шардирование не используется, то в конфигурационный файл ничего прописывать не нужно - только конфигурацию zookeeper. Друг друга они себя через него найдут.

Дальнейшая конфигурация репликации конфигурируется на уровне движков баз данных

1) никак, да и незачем. файлы жс уже находятся на клиенте, так что все что вы можете - обфусцировать код, но кому надо и так разберется, а кому не надо пофиг в любом виде. Относительно пхп файлов - иx и так никто не увидит с клиента, они исполняются на сервере, и клиенту доходит только результат выполнения скрипта.
2) Никак. Если у вас передаются через запросы какие-либо данные которые не должен видеть пользователь, значит что-то пошло не так.
3) По вкусу, безопасность это никак не гарантирует.
4) Странный вопрос, суть которого вообще не ясна.
5) Выдает с головой полное непонимание что и как устроено и что за что отвечает.
6) Куки не страшные, опасаться не стоит, еще не зарегистрировано ни одного случая нападения куки на человека. Пишите туда данные необходимые для работы приложения. Обычно пароль или другую секретную информацию записывать туда не рекомендуется.

может кто-то пользуется какими-то лайфхаками)

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

Короткий ответ - забейте, вы не тем занимаетесь, всё описанное мало относится к безопасности вашего приложения.

А для длинного ответа эти поля слишком малы.

Современные бд (и вообще концепция бд как хранилища данных) как раз про "перебрать большое количество информации" быстро, наиболее оптимальным образом. Для этого создаются правильные структуры хранения, индексы и много еще чего. Так что не надо заморачиваться надуманными проблемами, пока вы с ними не столкнулись. Ответ чисто теоретический без кода.

как и любая другая директория, .git хранит то что вы туда когда-либо положили. Не напрямую, конечно, а посредством утилиты git.

если удалить эту папку, вы потеряете: 1) локальную историю коммитов, бранчей, сташи и тд - всё что связано с разработкой и гитом, если коротко. 2) потеряете origin, если он не указан в гите глобально или в конфигах в ide. Т.е. будет непонятно какой удалённый репозиторий у этого проекта.
Проект будет работать, но переключиться на другую ветку будет нельзя (тоже думаю очевидно), да и не будет никаких других веток.

Это просто идеальная иллюстрация к известному высказыванию Дональда Кнута "Преждевременная оптимизация - корень всех зол".

Сначала высасываем из пальца проблему: "тратится время на обращение к бд". Сколько там его тратится, тратится ли вообще, замедляет ли это систему, является ли вообще это проблемой - все эти вопросы нам неинтересны. Мы хотим грудью на амбразуру, стать героем и получить медальку.

После этого начинаем проблему решать.
Значит, чтобы сэкономить время на запросе к базе, которая обычно лежит локально и обычное обращение занимает микросекуны, мы решаем закэшировать данные на клиенте. Который может быть в тысяче километров, а пинг в сотни миллисекунд - не редкость. И вот мы решаем что клиент будет с каждым запросом отправлять массив данных. Причем таких данных, которые на сервере и так. есть. Гениально!

Стоит ли так делать и почему;
не стоит потому что не надо высасывать проблемы из пальца.
Какой будет прирост производительности
Отрицательный
Как Вы решаете подобные вопросы.
МЫ ИХ НЕ РЕШАЕМ.
Мы решаем реальные проблемы, объективно существующие.
А воображаемые проблемы высосанные из пальца решать не следует.

1) с помощью JavaScript после первой отправки можно сделать кнопку отправки disabled
2) можно саму форму убрать вообще, после перегрузки страницы
3) можно куку ставить после отправки, если она есть - значит обработчик на серваке получаемые данные с формы игнорит

Потому что глобальные состояния.
В объекте состояние не меняется между тестами

Как лечить.

• Set Up в методах (например метод _before() или кастомные методы, на которые ссылается аннотация @before) помогут вам привести тест к исходному состоянию -- обнуляйте артефакты прошлых тестов.
  
• Пишите изначально код, который не завязан на глобальное состояние
  

При запуске с параметром -vvv, всё идет к тому что есть проблемы с загрузкой фикстур.

Если из-за них, то возможно легко излечить -- делайте cleanup перед каждым тестом и populate, то есть предзагрузка фикстур заново
https://codeception.com/docs/modules/Db#Populator
Или каждому тесту создавайте свой уникальный набор фикстур (я выбрал этот вариант), он быстрый, немного гемморный

Нет. Вам в любом случае надо им говорить что бы открыли файл, так вот и укажите что открыть надо index.html

не value а val

sudo add-apt-repository ppa:ondrej/php
sudo apt-get update

и ставьте

Наладить работу с обоих с синхронизацией внесенных изменений.

GIT не рассматриваю ввиду разработки в одиночку

Вам система контроля версий нужна. Кто сказал что гит только для командной разработки? Гит подойдёт как нельзя лучше. И изменения удобно смотреть и не надо кучи плагинов для размещения и заливания файла на удаленный сервер. Запушили ветку, на сервере подтянули, конфликты решили, если потребуется, вот и всё. Не хотите свой гит поднимать? Возьмите битбакет или гитхаб. Для одного человека все бесплатно.

В PhpStorm есть возможность синхронизации на сервер рабочей директории через sftp или ftp (секция deployment в настройках).

2. Частая ли вообще это практика? т.е. с чего вдруг его захотели взломать - конкуренция или кому-то просто делать нечего?

Боты просто лупят по площадям. В зависимости от результатов лупления - они либо уходят дальше, либо лупят и лупят.

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