Home > database >  GBase 8 a large table level authorization scenario needs a solution
GBase 8 a large table level authorization scenario needs a solution

Time:05-23

Usually project on the warehouse of many authorized you just need to to the level of library, because every day every moment will produce a new table or delete, requires authorization to table level, rarely change unless the name of the table, otherwise it will cause a great deal of management work, but because of security requirements, there is also a table level requirements, at this time if the table is more, such as must level, authorization table query response every time is busy, often cause many users use a database, often encountered caton phenomenon, because each user per do an operation, the database will check the presence of permissions,
We know the library's licensed in gbase. Db, the general project base on the number of only a few dozen, generally not more than thousand level, that is to say gbase. Db level authorization number only one thousand lines, permissions query, response usually get a millisecond level, user permissions will not appear in the process of checking caton perception, and table level authorization is stored in the gbase tables_priv, authorization table too much can cause table when response time is too long, objectively inevitable, such as table of tens of millions of level, regardless of the database, what engine, precise query a time-consuming will not less than a second level, and this is the second level of query response, before each operation, will cause the users will have obvious card perception, that what is the solution? To tell the truth, the method is not very effective, but it can be through the following method to optimize:
Authorized number 1) as far as possible control table level, increase the table after deleting, recycling authority records, try your best to reduce the gbase. Tables_priv rows,
2) by changing the parameters, fill tables_priv table into memory, improve the table query performance, such as modifying gcluster configuration file, add the following configuration
Key_buffer_size=512 m
Table_open_cache=16384
Table_definition_cache=16384
Modify the configuration files of the gnode, increase the following configuration
Key_buffer_size=512 m
Table_open_cache=16384
Table_definition_cache=16384
3) need to research and development of tianjin ntu general optimization gbase tables_priv table engine, to understand the current GsSYS is not good at this scene,
4) provide better performance management host, by updating the hardware conditions, to improve the query efficiency of the table,
  • Related