User permission storage problems

The current design mode is to associate roles and menus with users and roles. Operation association means that a field in a role is a pile of numerical IDs. Because it is a large ERP system, there are a lot of menus and operations, so the number of fields stored in the role is very large. The current practice is to save the role id in session... the current design mode is
User and role Association
Associate roles with menus and operations
That is to say, a field in the role is a pile of numerical IDs.
Because it is a large ERP system, there are a lot of menus and operations
Therefore, fields in the role store a large number.

The current practice is to save the role id in the session. The database reads the role id every time it is used. Now I want to save the heap of numbers to the session. I have read about 16 kb, it is afraid that the server load will be too high when stored in the session.

Is there any good solution.

Reply content:

The current design mode is
User and role Association
Associate roles with menus and operations
That is to say, a field in the role is a pile of numerical IDs.
Because it is a large ERP system, there are a lot of menus and operations
Therefore, fields in the role store a large number.

The current practice is to save the role id in the session. The database reads the role id every time it is used. Now I want to save the heap of numbers to the session. I have read about 16 kb, it is afraid that the server load will be too high when stored in the session.

Is there any good solution.

I think this design has to be modified? If 16 K data is of the java long type, 2000 data can be stored. Is this slightly more?

If it cannot be changed for other reasons, if the function id corresponding to the role is relatively fixed, you can cache the data in the application server. In the session, only the user's role id is stored, each request comes over to get the corresponding function id list through the role id, and then perform the remaining judgment.

If I/O is too high on the server, consider memcached or redis to store the session.