Кеширование данных

Здравствуйте,
Стоит задача проверки IP пользователя на уникальность за текущие сутки. Самый простым способом есть хранение данных в таблицы MySQL и выборка данных с нее. Но нашел я такой тип таблиц как MEMORY таблицы. И это было то что мне нужно. Таблицу я сделал самой простой, один столбец в котором был IP преобразованный при помощи INET_ATON().
Скорость проверки наличия адреса в этой таблице была ровно в два раза больше чем в аналогичной таблице при использовании MyISAM. А размер со 100 000 тысячами записей всего 2мб. И все казалось хорошо, но была прочитана мной одна особенность. Данные могут попасть в СВОП что в данном случае сыграет против меня.
Думал попробовать хранить данные при помощи memcached но там тоже оказались минусы. В случае нехватки выделенной памяти старые данные будут удалены что никак не позволительно в данной ситуации так как список IP мне нужен за последние 24 часа. Есть ли какой то способ сделать так чтобы данные гарантировано находились в ОЗУ и к ним был быстрый доступ но в тоже время они никуда не пропадали в случае если память закончилась. (можно выделить для memcached много памяти, но это все равно не гарантирует сохранность данных).
Или может у меня не правильный подход к этому?

Вы сами уже ответили на свой вопрос:

или

- собственно, два подхода к решению ситуации с нехваткой памяти. Резюмируя: Вы никак не можете хранить данные в некотором хранилище (в данном случае - ОЗУ), если их размер превосходит размер хранилища.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Это понятно. Но выше я привел размер таблицы со 100 000 тысячами записей в MYSQL. Их размер по сравнению с общим количеством ОЗУ очень мал.
Опишу как я понял работу memcached: выделено место (например 250мб) и кеш их будет занимать потихоньку, со временем когда кеш будет заполнен он начнет удалять старые данные.
Мне было бы удобно выделить 20Мб памяти под таблицу и чтобы они все время были зарезервированы для нее. Благо 20 Мб памяти это совсем не много. Но чтобы ни при каких обстоятельствах они не попали в СВОП. Или все равно, если для других процессов не будет хватать памяти то они этот контейнер размером 20Мб вытеснят в СВОП? Хотя он активно используется (данные с контейнера).

(Отредактировано автором: 22 Сентября, 2013 - 18:42:02)

полагаю мемкеш не работает с ОЗУ напрямую
посему в своп запросто может попасть

но наиболее часто используемые данные все таки будут в физическом ОЗУ.
А нечасто используемым в мемкеше делать нечего

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

А под задачу:

Ни memory ни memcache не подходят по условию. Рестарт машины - и данных нет.
Смотрите в сторону redis, mongoDB, postgresql.

-----
PostgreSQL DBA

caballero
Мемкеш я не могу использовать потому что он не дает гарантии сохранения данных. В то время как MySQL будет их хранить до перезагрузки сервера или удаления запросами.
Мелкий,
Спасибо.
Я не гуру в администрировании и не знал что "хорошие" сервера своп не используют (хотя у себя на 3 серверах я ни разу не видел использования свопа). Но думал что это штатная ситуация.
О том что данные после рестарта пропадут мне известно.
Но в данный момент меня это не сильно беспокоит (Сервер MySQL работает 88 дней, 11 часов, 0 минут и 19 секунд.).
Я сравнил операцию вставки в таблицу MyISAM и операцию выборки. Вставка была равна 8Е-5 в то время как выборки с этой же таблицы 0.025460679789652 (это MyISAM).
По этому я решил так - данные одновременно будут записываться в две таблицы. На диск и в память.
В случае рестарта сервера запуск MYSQL будет происходить через скрипт который сначала запустит MySQL а потом скопирует в MEMORY таблицу данные с той таблицы которая на диске.

Как я понял. Сервер не должен использовать СВОП. И если он это сделает то просто нужно добавить памяти. То есть я могу не переживать о том что данные MySQL попадут в файл подкачки.

(Отредактировано автором: 22 Сентября, 2013 - 22:21:34)

PlayTime Фигней ты страдаешь. Лучше озаботься правильной настройкой дискового кэша.

Зачем в решении данной задачи использовать дисковый кеш если таблицы и так на диске могут быть?

PlayTime Читай внимательней. И чутка матчасть подучи, тогда ответ станет очевидным. Судя по твоему вопросу, становится очевидным, что с матчастью ты не знаком вообще.

потому и надо.
Сервер БД сам закеширует в памяти часто используемые данные.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Я не очень корректно написал название темы, но описание корректное.
Я с вами согласен но вы не до конца поняли именно эту задачу.
MySQL кеширует данные. Но если таблица была изменена то данные уже не будут браться с кеша а опять сделают выборку с диска.
Таблица состоит из строк в котором один столбец типа INT(4). (если использовать MYSQL).
Выборка почти никогда не попадет в кеш так как данные часто изменяются, по этой причине даже отключено кеширование данного MySQL запроса.
По этому нужно хранилище к которому есть быстрый доступ но запросы к нему не будут помещены в кеш а данные удалены пока сервер не будет перезагружен или не будет произведен запрос на удаление.

будем дальше гадать))
скролл на пункт 16[dot] Вертикальное разделение

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

(Отредактировано автором: 23 Сентября, 2013 - 16:15:04)

Мда? Вот потому, что ты такой бред пишешь, тебя и отправляют учить мат часть.
Прежде чем выборка будет произведена, сначала ОС загрузит все данные в дисковый кэшь, если их там нет. А запрошены с диска будут только те данные, которых нет в кэше самого сервера. Прежде всего, стоит помнить, что БД MySQL, это всего лишь обычный файл.
Если не путаю, то MySQL имеет собственные кеши для хранения данных, (а не только запросов!), а уж ОС будет кешировать их обязательно. По этому рациональнее отдать память под ДИНАМИЧЕСКОЕ хранилище, которыми по факту и являются кеши. Очень редкие задачи требуют RAM дисков, и твоя, не из их числа. Кста, память занимаемая RAM диском в своп не вытесняется. Если писатель не рукожоп конечно, или специально не предусмотрел такой возможности.


Да нифига подобного. Данные останутся в КЭШе, читай в памяти, и только в случае длительного простая, и при условии нехватки памяти другим задачам, твои данные будут удалены из кэша физически.
И еще одно. Если данные попали в своп, это еще не означает, что они физически удалены их памяти. Данные могу находится одновременно и в свопе на диске, и кеше. И только при нехватке ресурсов они будут удалены из ОЗУ физически.

Гуру об этом то же не знают, так что не переживай.

(Отредактировано автором: 23 Сентября, 2013 - 18:14:16)

Ты это имеешь в виду?



В дисковом кеше останутся? Я имел ввиду кеш MySQL.



Я не отрицаю того что есть то чего я не знаю.
Но я сравнил один и тот же запрос к таблице типа MyISAM и MEMORY без использование кеширования MySQL. С таблицы типа MEMORY выборка была сделана в два раза быстрее. Проходов было сделано 2000 на каждый тип таблицы.
Я понял что данные с файла будут помещены в дисковый кеш и если к ним будет частое обращение то они там будут долго. Наверно это связано с самим механизмом работы с таблицами MyISAM и MEMORY.

(Отредактировано автором: 23 Сентября, 2013 - 20:02:55)