по поводу кеша mysql

[UnO]

Привет, сразу несколько вопросов интересует:

1) Есть ли лимит какой-то у кеша?
2) Сколько примерно памяти(как я понимаю оперативной) занимает сохраненный кеш(cache_save()) таблицы, скажем, на 800 строк и 6 полей?
3) Если можно как-то посчитать это дело - не откажусь, если кто-то подскажет как (:
4) Стоит ли работать с кешем вместо постоянных запросов?

[x86]

Лимит только один - для каждого запроса только один кеш. А вообще кеш потребляет всегда разное количество памяти, то есть он может выделить еще, если ему не хватает (ествественно в пределах одного процесса). Плагин считает общую длину всех стобцов, поэтому точно сказать сколько будет выделенно - невозможно. Код подсчетка расположен тут (https://github.com/pBlueG/SA-MP-MySQL/blob/252976351b0b3fe5fff52914c254018f263d7412/src/CResult.cpp#L117-L160).


размер шапки = sizeof(char**) * кол-во строк
размер строки = sizeof(char*) * (кол-во стобцов + 1) + (длина строки * sizeof(char))
размер строки += 8 - (размер строки % 8)

размер данных = размер шапки + кол-во строк * размер строки

[DeimoS]

Стоит ли работать с кешем вместо постоянных запросов?

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

В общем, однозначный ответ тут дать не получится.

[UnO]

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

В общем, однозначный ответ тут дать не получится.

В бд есть поля: номер, название, текст.
В планах сделать диалог, в котором будет список с номерами и названиями. При выборе одного елемента из списка открывается второй диалог с текстом соответствующим выбранному в списке названию(ну и номеру, офк). Во втором диалоге, при нажатии esc(response == 0), возвращаемся к первому(который список). Вот я и думаю, мб лучше вместо отправления select-запроса каждый раз при возвращении в первый диалог, сохранить один раз кэш, глобальный для всех игроков, и доставать данные из него. Тот же прикол и с доставанием текста для второго диалога И при update-запросах от кого-либо просто обновлять кэш.

лол, пока описывал, сам вкурил, что лучше в таком случае будет юзать массив(тогда при обновлении не нужно будет всю инфу перезаписывать, а можно отдельно ячейку массива). А это то, от чего я хотел уйти в угоду экономии памяти, т.к. диалог этот вызывать надо будет не столь часто, чтобы постоянно хранить все 900 строк * 6 полей в памяти.

- - - Добавлено - - -

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

[m1n1vv]

А какую информацию то выводишь? О чем она?

[UnO]

А какую информацию то выводишь? О чем она?

досье на сотрудника гос.фракции

[m1n1vv]

досье на сотрудника гос.фракции

Может первым диалогом делать выбор фракции, а не весь список?

[UnO]

Может первым диалогом делать выбор фракции, а не весь список?

Ну каждый будет видеть только свою фракцию

[DeimoS]

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



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

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


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

[UnO]

В общем, сделаю без списка.
Всем спасибо, кто отписался.

[DeimoS]

Я подобное реализовывал через кэш, не особо беспокоясь об актуальности информации. Просто при определённых действиях сбрасывал кэш и закрывал диалог, чтоб игрок уж совсем с устаревшей информацией не работал.
В моём случае был список игроков + ряд действий, которые можно совершить над аккаунтом игрока. И тут единственным ограничением я делал запрет на работу с одним и тем же аккаунтом несколькими игроками (просто создал двумерный массив [MAX_PLAYERS][MAX_PLAYER_NAME] и когда кто-то открывал аккаунт, проверял массив на наличие соответствующего ника. Если ника в массиве нет - позволял работать с акком и записывал ник в ячейку игрока). Это нужно чтоб изменения одного игрока не перекрыли изменения другого, если что :)
В остальном проблем не было.

Ну раз ответ получен, то тему закрываю. Если вдруг нужна будет ещё - напиши в личку и открою.