Являются ли заявления об обновлении MySQL слишком дорогими? - PullRequest
Новая
       23

Являются ли заявления об обновлении MySQL слишком дорогими?

1 голос
/ 12 марта 2011

Я много читал о том, как написать масштабируемую схему MySQL, но я все еще не уверен, хорошая ли это идея.

Для чего бы то ни было, я веду этот проект на EC2 с RDS.

В моей базе данных есть основная таблица, в которой будет больше записей, чем операций чтения (примерно 70% операций записи и 30% операций чтения, я думаю).

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

Исходя из того, что я читал, в MySQL есть нечто, называемое блокировкой таблиц, которое происходит при записи в таблицу? Поскольку эта таблица также будет значительно читаться, не вызовет ли она слишком много накладных расходов / блокировок для использования операторов UPDATE в строках?

Мои варианты (насколько я знаю):

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

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

Есть еще идеи? Предложения? * * 1023

Спасибо!

Ответы [ 2 ]

2 голосов
/ 12 марта 2011

Будет ли применена блокировка таблицы или нет, зависит от механизма хранения.MyISAM выполняет блокировки таблиц, InnoDB выполняет блокировки строк.

Поскольку вы хотите читать и записи строк, вам придется использовать InnoDB, поскольку он разрешит одновременный доступ к каждой строке (читатели не• блокирующие средства записи, записывающие устройства не блокируют устройства чтения)

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

0 голосов
/ 12 марта 2011

Независимо от того, являются ли операторы Update дорогими, похоже, что вам все равно придется их выполнять. Если бы у вас была возможность не обновлять таблицу, очевидно, что это было бы более производительным, но я предполагаю, что это не так.

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

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

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

...