Как я могу решить эту проблему масштабирования с помощью обратимого удаления элементов?

Question

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

Что меня беспокоит, так это то, что через несколько лет, когда таблицы станут намного больше, общая скорость системы снизится.

Что я могу сделать, чтобы противодействовать таким последствиям?

• Индексировать ли мне поле удаления?
• Перемещаю ли я удаленные данные в идентичную таблицу удаления и обратно после восстановления?
• Распределяю ли я данные по нескольким серверам MySQL с течением времени?(в зависимости от роста)

Буду признателен за любые предложения и истории.

ОБНОВЛЯТЬ:

Таким образом, разделение, по-видимому, является ключом к этому.Но не было бы разделения просто создать две «таблицы», одну с удаленными элементами и одну без удаленных элементов.

Таким образом, со временем удаленный раздел станет большим, и периодические выборки из него будут медленными (и со временем все медленнее).

Стоит ли мне беспокоиться о разнице в скорости?Поскольку я получаю большую часть (если не все) данных по некоторому значению ключа (некоторые из них являются поисковыми, но для этой настройки они могут быть медленными)

Answer 1

Я бы разделил таблицу на DELETE флаг.

Удаленные строки будут физически сохраняться в другом месте, но из SQLС точки зрения автора таблица остается прежней.

Answer 2

О, черт возьми, да, проиндексируйте поле удаления.Вы будете все время спрашивать об этом, верно?Составные индексы с другими полями, к которым вы часто запрашиваете данные, например, с родительскими идентификаторами, также могут быть хорошей идеей.

Answer 3

Возможно, это решение можно будет принять позже, если и только если действительно возникнут проблемы с производительностью.Это во многом зависит от того, сколько строк добавляется и с какой скоростью, характеристик вашего блока и т. д.Очевидно, уровень абстракции вашего приложения (и ограничения любых используемых вами библиотек) помогут определить, насколько трудным будет такое изменение.

Если это становится проблемой или вы уверены, что это произойдет, начните с разделения флага удаленного между двумя таблицами: одна, которая содержит текущие данные, и другая, которая содержит исторические/удаленные данные.ЕСЛИ, как вы сказали, «удаленные» данные будут доступны только администраторам, разумно предположить, что (в большинстве приложений) общее количество пользователей (в данном случае ограничено только администраторами) будет недостаточным, чтобы вызвать проблему.Это означает, что вашим администраторам, возможно, придется подождать немного дольше при поиске в этой конкретной таблице, но ваша пользовательская база (возможно, более важная в большинстве приложений) будет испытывать гораздо меньшую задержку.Если производительность становится неприемлемой для администраторов, вы, вероятно, захотите проиндексировать поле user_id (или идентификатор транзакции или что-то еще), с помощью которого вы получаете доступ к удаленным записям (обычно я индексирую каждое поле, с помощью которого я получаю доступ к таблице, но в определенном масштабе может происходить обмен). -офф относительно того, какие индексы наиболее ценны).

В зависимости от того, как осуществляется доступ к данным, вы можете использовать и другие простые приемы.Если администратор большую часть времени ищет конкретную запись (в отличие, скажем, от чтения «истории» или «журнала» активности пользователя), часто можно предположить, что более свежие записи будут просматриваться чаще, чем старые. записи.Некоторые базы данных включают параметры настройки, позволяющие упростить поиск последних записей по сравнению с более старыми, но вам придется искать их для вашей конкретной базы данных.В противном случае вы можете сделать это вручную.Самый простой способ — создать таблицу Ancient_history, содержащую все записи старше н дней, недель или месяцев, в зависимости от ваших ограничений и предполагаемых моделей использования.Новые данные затем помещаются в таблицу гораздо меньшего размера.Даже если админ собирается "просматривать" все записи, а не искать какую-то конкретную, можно начать с показа первой н дней и иметь ссылку для просмотра всех дней, если они не найдут то, что ищут (например, большинство приложений онлайн-банкинга, которые позволяют просматривать транзакции, но показывают только первые 30 дней истории, если вы не запросите иное).

Надеюсь, вам удастся избежать необходимости идти дальше и сегментировать user_id или какую-то подобную схему.В зависимости от масштаба остальной части вашего приложения вам, возможно, придется это сделать в любом случае.Если вы не уверены, что вам это понадобится, я настоятельно рекомендую сначала использовать вертикальное секционирование (например, хранить сообщения forum_posts на отдельном компьютере, а не sales_records), поскольку его НАМНОГО проще настроить и поддерживать.Если вам в конечном итоге понадобится сегментировать user_id, я предлагаю использовать Google ;-]

Удачи.Кстати, я не администратор баз данных, так что отнеситесь к этому с недоверием.