ПАМЯТЬ (HEAP) против InnoDB в среде чтения и записи

Question

Я хочу запрограммировать приложение в реальном времени, используя MySQL.

Требуется небольшая таблица (менее 10000 строк), которая будет находиться под большой нагрузкой чтения (сканирования) и записи (обновления и некоторых операций вставки / удаления). Я действительно говорю о 10000 обновлений или выборок в секунду. Эти операторы будут выполняться только для нескольких (менее 10) открытых подключений mysql.

Таблица небольшая и не содержит никаких данных, которые необходимо хранить на диске. Поэтому я спрашиваю, что быстрее: InnoDB или MEMORY (HEAP)?

Мои мысли:

1. Оба механизма, вероятно, будут обслуживать SELECT непосредственно из памяти, поскольку даже InnoDB будет кэшировать всю таблицу. Как насчет ОБНОВЛЕНИЙ? (Innodb_flush_log_at_trx_commit?)

2. Моя главная проблема - это поведение блокировки: блокировка строки InnoDB против блокировки таблицы MEMORY. Представит ли это узкое место в реализации MEMORY?

Спасибо за ваши мысли!

Answer 1

Если вам действительно нужно иметь столько одновременных обновлений, то почти наверняка Innodb будет работать лучше, поскольку таблицы HEAP имеют только блокировки на уровне таблицы, а не блокировки на уровне строк, как Innodb.

Если вы начинаете с нуля, я бы исследовал использование MySQL 5.5 или Pertraa XtraDB, поскольку они оба содержат множество улучшений масштабируемости по сравнению с исходным MySQL 5.1.

Answer 2

Это не просто вопрос блокировки строк - InnoDB также имеет MVCC http://en.wikipedia.org/wiki/Multiversion_concurrency_control, поэтому читатели даже не будут блокировать писателей.

Но я думаю, что в вашем вопросе отсутствуют все важные детали - какие данные вы храните? Если вам необходимо восстановить после аварии ПАМЯТЬ не вариант.

Если вам не нужно восстанавливать данные после сбоя, тогда зачем вы используете базу данных? Почему бы не использовать что-то вроде memcached или redis?