#mysql #logging #data-warehouse #database-administration
Вопрос:
Я разработал таблицу, которая будет использоваться для ведения журнала. Это структура таблицы, и я буду использовать MySQL (движок InnoDB), и она будет размещена в AWS RDS.
| id (primary_key auto_increment) | entity_id (foreign key) | previous_value | current_value | calculation_done_with_this_row (boolean) | created_time |
Эта таблица также будет использоваться для некоторых важных бизнес-расчетов, и как только расчет будет выполнен за определенный день, данные таблицы журналов больше не нужны. Поэтому на данный момент я планировал удалить данные из таблицы журналов, как только будет выполнен расчет для таких строк.
Но меня беспокоит то, что если что-то пойдет не так и мне нужно будет изучить исторические данные, что я тогда буду делать? Поскольку я удаляю записи, у меня не будет ничего, что могло бы меня поддержать в таких ситуациях? С другой стороны, если я не удалю данные из таблицы журнала, она будет полна ненужных данных, которые не будут способствовать бизнес-вычислениям; таким образом, замедляется производительность вычислительного запроса.
Мои требования состоят в том, чтобы уменьшить размер таблицы журналов, а также сохранить ненужные журналы для дальнейшего использования в качестве исторических данных, а также при необходимости импортировать исторические данные обратно в основную базу данных.
Комментарии:
1. Возможности 1) запишите строки в другую таблицу как часть удаления. 2) Создайте резервную копию таблицы перед удалением, дайте ей имя, отражающее дату, для которой были созданы данные. Восстановите его с другим именем таблицы, если вам нужно что-то проверить.
2. Я бы сохранил таблицу только с данными, необходимыми для расчета, и после расчета переместил бы их в таблицу журнала, где они останутся для справки. Эта таблица журнала для того, что вы говорите, никогда (или почти никогда) не будет использоваться, поэтому вам не нужно беспокоиться о производительности (даже если она будет полностью работать в случае необходимости).
3. Вы проверяли разделение ? Это точная концепция, позволяющая сохранять текущие данные небольшими (с обрезкой разделов) и эффективно удалять более старые данные (отбрасывать разделы).
4. @MarmiteBomber Я попытался сделать разделение. Но позже обнаружил, что разбиение на разделы в таблице, которая имеет ограничения по внешнему ключу в движке InnoDB, еще не поддерживается. И в моей таблице журналов есть одна ссылка на внешний ключ.
Ответ №1:
Это один из немногих случаев, когда PARTITIONing это полезно.
Измените таблицу на «быть PARTITION BY RANGE(TO_DAYS(...)) «. Каждый вечер добавляйте новый раздел; отбрасывайте действительно старые разделы, когда вы чувствуете, что они вам больше не понадобятся.
Более подробная информация: http://mysql.rjweb.org/doc.php/partitionmaint . Также вас могут заинтересовать методы подведения итогов: http://mysql.rjweb.org/doc.php/summarytables
Комментарии:
1. Я использую движок InnoDB Для Mysql. И в моей таблице есть одна ссылка на внешний ключ. И, к сожалению, InnoDB не позволяет разбивать таблицу на разделы с ограничением внешнего ключа. 🙁
2. @T4puSD — Вы действительно используете FKs для чего-либо, кроме индекса, который они генерируют? Индексы доступны (но их следует пересмотреть) при добавлении секционирования.
3. Мне не совсем ясно, что вы хотите этим сказать. Но в моей таблице есть один внешний ключ, который ссылается на идентификатор другой таблицы. И в соответствии с документацией, предоставленной MySQL , InnoDB не поддерживает такое разбиение таблиц.
4. @T4puSD — Правильно,
PARTITIONingне допускает FKs в любом направлении. Можете ли вы обойтись без FK? И есть подходящийINDEX, чтобы обеспечить эффективность поиска, которую обеспечивает FK. Вы теряете проверку целостности и способность совершатьCASCADEingдействия.5. Я не могу удалить ограничение внешнего ключа из таблицы. Мне не позволено этого делать. Изначально я также хотел заняться разделением, но из-за проблемы с внешним ключом я пытаюсь найти другие решения.