таблицы mysql и стратегии удаления

Я работаю в социальной сети, вроде Facebook. Я думаю, это означает, что приложение будет более загруженным для чтения, чем для записи (т.е. больше SELECTS, чем INSERTS, UPDATES или DELETES)

Я планирую использовать MySQL для базы данных, используя MyISAM. Каждая таблица в базе данных будет содержать следующие три поля:

  • CREATED - поле даты, содержащее время создания записи
  • UPDATED - поле даты, содержащее время изменения записи
  • ROWSTATUS - поле CHAR (1), содержащее односимвольный флаг, показывающий, является ли запись активной, неактивной или удаленной (с использованием значений «A», I и D соответственно).

С помощью класса-оболочки PHP мы гарантируем, что все запросы SELECT включают ROWSTATUS, запросы UPDATE также обновляют столбец UPDATED, а запросы INSERT обновляют столбец CREATED.

Я не планирую фактически удалять какие-либо записи, вместо этого я предпочитаю обновить это поле ROWSTATUS записей до D, чтобы показать, что оно удалено (т.е. мягкое удаление).

У нас есть процедура SQL, которая физически удаляет удаленные данные через 10 дней.

Однако я просматривал эту статью, в которой утверждается что нет необходимости удалять физически из-за накладных расходов на блокировку. Скорее автор предложил использовать такую ​​схему:

SELECT e.eventid,e.title
    FROM events e
   WHERE NOT EXISTS
    (SELECT * FROM event_deletes ed WHERE ed.eventid = e.eventid);

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


mysql sql-delete overhead myisam
person Ahmad    schedule 16.12.2010    source источник
comment
Отнеситесь к этому совету с недоверием. За почти 7 лет, прошедших после этой статьи, многое изменилось.   -  person Dan Grossman    schedule 16.12.2010
comment
Есть ли причина, по которой вы планируете использовать MyISAM, а не InnoDB?   -  person AgentConundrum    schedule 16.12.2010
comment
@AgentConundrum ... мы уже используем MyISAM, я думаю о переходе на InnoDB. просто хочу исследовать плюсы и минусы   -  person Ahmad    schedule 16.12.2010
comment
честно говоря, единственное «профи», которое приходит на ум для MyISAM, - это его полнотекстовый поиск. Если вам это не нужно, я бы выбрал InnoDB. Даже если вам это действительно нужно, вам, вероятно, лучше использовать что-то вроде Sphinx для вашей FTS.   -  person AgentConundrum    schedule 16.12.2010
comment
но у нас есть столбцы типа VARCHAR или TEXT, и мы выполняем запросы [имя столбца, например, '% USER_SEARCH_QUERY%']. какова рекомендуемая практика?   -  person Ahmad    schedule 16.12.2010

Ответы (2)


arrow_upward
2
arrow_downward

Как говорит @ Pentium10, в вашем плане нет ничего принципиально неправильного. На самом деле это довольно стандартный подход.

Проблема в том, что если вы используете MyISAM, ваши ОБНОВЛЕНИЯ приведут к блокировке всей таблицы во время выполнения запроса. Это создает узкое место, потому что вы можете обновлять или удалять только одну запись за раз.

Если у вас нет причин для использования MyISAM, я бы рекомендовал переключиться на InnoDB в качестве движка базы данных. InnoDB использует блокировку на уровне строк, поэтому ваши запросы UPDATE не будут блокировать другие UPDATE. Он также имеет некоторые другие полезные функции, такие как поддержка транзакций и ограничения ссылочной целостности.

person AgentConundrum    schedule 16.12.2010
comment
да .. я думаю, это имеет смысл .. я был неправ. мы должны OPT для InnoDB, чтобы полностью использовать наш дизайн БД. ссылаясь на ссылочную целостность. ну, мы вообще не используем внешние ключи. мы пытаемся управлять всем через наш код. - person Ahmad; 16.12.2010

arrow_upward
0
arrow_downward

Единственная проблема, которую я вижу здесь, по сравнению с этой статьей, заключается в том, что вы обрабатываете только блокировки для вызова DELETE.

Вы должны знать, что операторы UPDATE и DELETE всегда должны устанавливать монопольную блокировку для таблицы MyISAM.

Вот почему в статье рекомендуется использовать INSERT вместо UPDATE rowstatus. Вам следует пойти, как написано в статье. Создайте специальную таблицу для хранения удаленных идентификаторов и используйте рекомендованное соединение для выбранных элементов, чтобы получить не удаленные записи. Таким образом, при удалении конечного пользователя вы просто вставите в таблицу, и вы не вызовете блокировку UPDATE для таблицы. Если вы добавите правильные ключи к обеим таблицам, соединение будет выполнено только по индексам, то есть оно будет быстрым по SELECT.

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

person Pentium10    schedule 16.12.2010
comment
Ага. Спасибо за ответ. в основном я ошибался. ссылаясь на столбец ОБНОВЛЕНО. на самом деле мы также используем его, чтобы найти некоторую информацию; специально в модулях отчетности - person Ahmad; 16.12.2010