Лучший движок таблиц для массово обновленной таблицы MySQL.MyISAM или HEAP?

Question

Я создаю приложение, которое будет хранить (полу) ленту в реальном времени нескольких различных масштабов вокруг определенного местоположения. Веса каждой шкалы будут помещены в таблицу, содержащую столько строк, сколько весов. Приложение масштабирования подает базу данных MySQL каждую секунду новый вес, который веб-приложение PHP читает каждые 3 секунды. Не похоже, чтобы трафик занимал много места на жестком диске, или если бы разница была незначительной, но мне интересно, будет ли это более эффективным или имеет больше смысла использовать таблицу Memory / HEAP по сравнению с обычная таблица MyISAM.

Answer 1

При любых одновременных запросах на чтение / запись (от 100 до 1000) (например, при обычном использовании OLTP) innodb не справится с задачей myisam.

Речь идет не о наблюдениях других людей, не о транзакционной / кислотной поддержке, а об архитектуре innodb, которая намного превосходит архитектуру устаревшего движка myisam.

Например, innodb поддерживает кластерные индексы первичного ключа http://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.html.

Кроме того, innodb имеет блокировку на уровне строк, которая гораздо более эффективна при одновременной нагрузке, чем блокировка на уровне таблицы myisam.

Я мог бы продолжать, но Somone уже предоставил действительно хорошее резюме того, почему innodb является лучшим выбором для OLTP: http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

Answer 2

Ну, если вы ожидаете большой объем данных, я думаю, вам почти нужно идти MyISAM. Скорее всего, вам не хватит памяти, если вы сохраните все это в таблице памяти. Не говоря уже о том, что вы потеряете все свои данные при отключении питания с помощью механизма HEAP (имейте в виду, вы можете захотеть это в зависимости от вашего варианта использования) ...

Answer 3

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