Vitaly Karasik

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

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

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

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

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

>возможно стоит вместо 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+\././' *

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

raid10 на 6 дисков, конечно, если место не поджимает. Быстро, удобно, нет извращений "ой, системный диск пустой и вообще по нулям i/o, вебовый забит под завязку, а диски под базой загружены в потолок".
raid5 под базой зрелище зело печальное в работе.

'ENGINE': 'django.db.backends.sqlite3',

Замените 'ENGINE' c django.db.backends.sqlite3 на django.db.backends.mysql
Сейчас у вас из-за бэкенда БД sqlite просто создается база данных django-app-db1

используйте TPM, шифрование без дополнительного подтверждения (пароль, токен и т.п.), либо при возможности внести изменения в конфигурацию загрузки (которое и блокирует TPM) - не имеет смысла.

Лучше воспользуйтесь специализированной программой monit, её создали как раз для этого.