Vitaly Karasik

Есть такой код (не мой)

Что я делаю не так?

1. вы не даёте ссылку на источник кода, а это могло бы упростить разбор.
2. вангую, что этому коду лет десять, может быть меньше, может быть больше. Давайте посмотрим, какие версии ядра Linux были поддерживаемыми лет 10 назад; а это были версии 2.6.x и 3.x.x; версия 4.0 впервые появилась в 2015 г., версия 5.0 - в 2019 г. Уже поняли, на что я намекаю? Вы пытаетесь подсунуть компилятору исходники ядра одной из последних версий, на которой этот код, возможно, никто вообще не тестировал. Сколько там изменений было за десяток лет... Короче, пробуйте его скомпилировать вместе с исходниками 3.x. Если ошибок будет хотя бы меньше - уже кое-что.

Смотри в сторону томита парсера, который умеет извлекать семантику из предложения.
Исходный код открыт: https://github.com/yandex/tomita-parser
Пример простой семантики: https://github.com/yandex/tomita-parser/blob/maste...

date-format
The date-format variable followed by a space, specifies the log-format date containing any combination of regular characters and special format specifiers. They all begin with a percentage (%) sign. See `man strftime`.

https://goaccess.io/man#custom-log

%b
The abbreviated month name according to the current
locale. (Calculated from tm_mon.) (The specific names
used in the current locale can be obtained by calling
nl_langinfo(3) with ABMON_{1–12} as an argument.)

https://man7.org/linux/man-pages/man3/strftime.3.html

Весь мир у вас в руках, а вы на Тостере ответы ищете...

1. Есть код, что делает етот код

Собирает контейнер под заданным тегом и с заданными аргументами. Кстати, символ @ лишний.
Всё остаётся локально до тех пор, пока не будет выполнена команда push для заливания на hub.docker.com или другие репозитории.

2. Откдуа ми тянем репозиторий: project_name/php-full:latest ?

ничего не тянем. Это собирается локально. Необходим файл Dockerfile, который обычно располагают в корне проекта.

Всё считающие, что пузырь ИТ сдулся, должны работать ещë усерднее без всяких повышений, а то вдруг зарплату наоборот срежут или вообще сократят.

Всё неправильно, потому что вы видео смотрели на ютубе. А надо было в тиктоке - тогда бы сразу выучились на джуна после просмотра.

>Возможно, не в реальном времени, и вы увидите это на след. день?

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

>я бы обратился в их поддержку с примерами писем и жалоб
Так и попробуем сделать.

>возможно стоит вместо Mautic попробовать какой-то российский сервис

Не очень хотелось бы..но на крайний случай порекомендуем рассмотреть этот вариант.
Спасибо!

По сути три больших направления с кучей мелких ответвлений
1. хранить текстовый лог в отдельном файле/сервисе/логохранилище
2. хранить лог действий юзеров в отдельной таблице (встречал один проект, где лог действий был в десятки раз больше, чем сами данные, ага).
3. хранить в той-же таблице предыдущие записи. То есть при редактировании INSERT, а не UPDATE, при этом автоматически проставляется время и автор, а при выборке просто берете последнюю по времени версию.

Это самый удобный путь, и самый простой для внедрения - очень простой откат, удобное сравнение изменений. Из минусов - раздуваете таблицу с данными, но это не проблема если записей не много или изменения редки.

Особняком стоит упомянуть системы с возможностью одновременного редактирования несколькики пользователями, которые автоматически разруливают коллизии. Самый знакомый всем пример - google docs. Но это довольно сложно в реализации.

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

Как его лучше хранить? Организационная часть. Если вы хотите хранить его так чтобы никто не изменил - то надо строить отдельным сервисом. Иначе те-же люди что и натворили бед смогут зачистить свои следы. Или я не понял корень вашей проблемы.

Техническая часть. Очевидно что нужна еще одна таблица. С датой аудита. С реквизитами пользователя который делал бизнес-операцию. И две версии данных. "До" и "после" изменения. Данные можно хранить в денормализованном формате (XML или Json) для простоты схемы.

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

Испортить это время может сетевой лаг который в данной задаче мы просто не учитываем. Считаем что сеть идеальна.

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

В Linux есть замечательная утилита rename. Ну, точнее, их две: одна входит в пакет util-linux, другая - скрипт на базе perl-модуля File::Rename. В deb-дистрибутивах нужный нам скрипт устанавливается в составе пакета rename и также имеет имя второе file-rename (а версия из util-linux имеет имя rename.ul). В других дистрибутивах может быть иначе, поэтому смотрим внимательнее параметры запуска (можно запустить rename без параметров и убедиться, что это нужный вариант).

Синтаксис предельно простой: rename регулярное_выражение_замены_perl имена_файлов

Синтаксис rename.ul для сравнения: rename что_заменить на_что_заменить имена_файлов

Вот что можно сделать для решения задачи (в предположении, что других точек, кроме как перед расширением, в имени файла нет):

rename 's/-\w+\././' *

Этот скрипт намного удобнее многоэтажных однострочников, да и пригодится в жизни ещё не раз.