Потому что консьюмеры нужно запускать в режиме демона чтобы он постоянно слушал очередь и при поступлении задачи выполнял её, а если вы запускаете скрипт из веба, то веб сервер будет ждать ответ, и если не получит то сам принудительно завершит соединение. Это базовые вещи и я даже не понимаю почему мне приходится это объяснять.
Если вы запускаете задачу прямо из того же места где и ставите эту задачу в очередь, то значит где то в архитектуре приложения вы свернули не туда
while ($this->channel->is_consuming()) {
$this->channel->wait();
}Но для логгирования событий ПРИЛОЖЕНИЯ типа нужно их писать не очень часто но с гарантией что sync на диск сработал.
как организовать UI в Grafana, есть ли какие то готовые решения что бы не пилить с нуля "интерфейс".
Вставка по 1 строке например раз в несколько секунд с фиксацией - будет не благоприятным режимом работы для кликхауса
Я даже попытался сравнить через Git, создал проект с моей папкой плагина, затем заменил все на плагин из GitHub. Сначала гит показал что изменено более 300 файлов, но при попытке закоммитить выдал ошибку - нет изменений.
Это как?
1 индекс на таблицу обязательно. Даже если в запросе нет условия по индексу, план выполнения строится оптимальнее, запросы работают быстрее.
А вот в PG можно кластеризовать в моменте таблицу по любому индексу, но он не станет из-за этого кластерным. Поэтому в PG партиционирование приходилось делать на относительно небольших таблицах, в несколько млн., которые MS или oracle переваривают без проблем.
понимание. Список улиц будет сильно меньше, а выбор улицы по индексу - логичнее
Второй вариант хрестоматийной задачи. Тоже телефонный справочник: телефон, ФИО, адрес.
Рассмотри размер БД в таком случае и в случае, когда список улиц вынесен в отдельную таблицу.