Как сделать чтобы mysql хранил таблицы в ОЗУ?

Question

[Евгений Лернер]

Здравствуйте! Вероятно надо модуль обращения к диску заменить на такой же, но чтобы писал а ОЗУ. Это возможно? Или есть другой метод?

Comments

[Akina]

Сразу хочется спросить - а что, данные нужны только на время работы сервера? А как сервер стоп или ребут, так ну их нафиг, и накапливаем с нуля?

[Евгений Лернер]

Akina, я на этот вопрос уже отвечал. Вы вообще знаете как работает inmemory db?

[Akina]

Евгений Лернер, Вы пробовали ответить, но попытка откровенно провальная. Попробую помочь.

Вариант 1. При отключении сервера данные пусть пропадают. После запуска накопление начнется заново, с нуля.
Вариант 2. Данные не должны пропасть. Следует обеспечить их сохранение и загрузку при следующем запуске.

Выберите один из двух вариантов.

Вы вообще знаете как работает inmemory db?

Вот не поверите - знаю.
Но InMemory DB и MySQL не соотносятся никак. Вообще никак.

PS. Да, эмуляция возможна. Но производительность будет скорее всего ещё хуже.

[Евгений Лернер]

Akina, так вот и напишите, как из mysql сделать inmemory db
. Соображения есть но я не уверен. А зачем это нужно я сам разберусь

Answer 1

[Дмитрий]

16.3 The MEMORY Storage Engine

З.Ы. Но вы явно чего то не то замыслили.

Comments

[Евгений Лернер]

Замыслил журналируемое хранилище типа redis, но с sql

[Дмитрий]

Евгений Лернер, ну как бы если в редис хранят важные данные - то обычно включают persistence - сброс данных на диск. То есть по факту получается не совсем ОЗУ.
И собственно любая RDBMS не дура - и тоже часто используемые данные запихивает в ОЗУ и старается использовать это ОЗУ по максимуму и на диск лишний раз не лезть. По этому от вашего комментария мне лично понятнее не стало.

[toxa82]

Есть еще настройка, указывающая сколько ОЗУ можно занимать в системе, и таблы будут закешированы в ОЗУ
# Значение ключа innodb_buffer_pool_size стоит устанавливать в 70%...80% доступной памяти.
innodb_buffer_pool_size = 1G

[Евгений Лернер]

Дмитрий, сброс иногда на диск это и есть журнулирование. Я имею в виду не кеш mysql, а его работу с ОЗУ. Точно как redis, только возможности mysql

[Дмитрий]

Евгений Лернер, что значит работу с озу и чем работа с кешом в ОЗУ отличается от просто работы с ОЗУ?

[Евгений Лернер]

Дмитрий, в вопросе написано. Хранить таблицы не на диске а в памяти

[Ипатьев]

Евгений Лернер, а что делать, когда питание выключится?

[Ипатьев]

Но главный, конечно, вопрос - ЗАЧЕМ.
Попробуйте хотя бы себе на него ответить.
Посмеётесь.

[Дмитрий]

Евгений Лернер, и еще раз говорю. Мускул или кто еще по мере сил и возможностей уже создан так что бы хранить максимальное количество данных в памяти. Он не дурак - и понимает что дисковые операции дорого. Проблема в том что данных обычно дохера, а памяти нихрена не хватает. И по этому он старается хранить только часто используемые данные. Но если памяти у него будет больше чем данных - он на диск будет только сбрасывать изменения - без этого никак ибо иначе вы их потеряете, все остальное таскать из ОЗУ. Так что база которая хранит данные в ОЗУ и с SQL уже есть - можете взять что MySQL что PostgreSQL что Oracle что MS SQL.
Соответственно что вы собрались писать?

[Евгений Лернер]

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

[Ипатьев]

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

[Дмитрий]

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

[Евгений Лернер]

Дмитрий, вероятно поэтому редис очень простой. Но я хочу тоже самое на mysql ТК людям не надо его учить. Можно и небольшие таблицы иметь. Это вопрос порога вхождения в технологию, не больше

[Дмитрий]

Евгений Лернер, честно говоря мне кажется вы пишете малосвязанные между собой вещи причем слабо представляя что вы хотите и что вы пишете.

[Евгений Лернер]

Дмитрий, это ваши проблемы

Answer 2

[mayton2019]

Тюнинг БД это процесс бесконечный и интересный. Вот еще брат-близнец (или сестра) под названием Мария тоже имеет двигатель для memory https://mariadb.com/kb/en/memory-storage-engine/

Есть там нюанс связанный с кнопкой Power. Так что будьте готовы к тому что это место - временное. Для кешей подходит разве что. Какую-то ценную информацию о финансовых транзакциях туда кидать нельзя.

Еще если БД стоит на отдельном хосте - то какую-бы быстроту вы ни выжимали из таблицы - перед ней стоит сетевой стек который вносит свои законные милисекунды. Имейте это в виду.

Вообще такая задача лучше ложится на структуры данных самого приложения. Поэтому - комменарий Дмитрия выше. Это звоночек о том что вы что-то не то делаете.

Comments

[Евгений Лернер]

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