[AMORO-2893] optimize table page loading

[klion26]

Why are the changes needed?

Close #2893 .

Optimize the loading process when user open the optimizer page

Brief change log

-

How was this patch tested?

• [ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

• [ ] Add screenshots for manual tests if appropriate

• [ ] Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[klion26]

Currently, this is a draft version just a better discussion. the open questions are

1. Do we need to include the table format in what we return to the front end, which right now doesn't seem to be using it?
2. If we don't need to need to include the table format, which way do we prefer to add the infor no in table_runtime 2.1. select info from DB for the given tables retrieved in the previous step 2.2. retrieve the info from TableManager(for example add a function TableManager#getTableRuntime(int tableId)), which needs to maintain an tableId to tableRuntime relationship in memory

I'm leaning towards option 2.2 with not returning the table format to the front end because it reduces the number of DB requests by one

Please let me what you think about this, thanks. @zhoujinsong @majin1102

[baiyangtx]

Now that you have queried the TableRuntimeBean object from the database, why not directly perform sorting or paging operations on this object later?

[majin1102]

Currently, this is a draft version just a better discussion. the open questions are

1. Do we need to include the table format in what we return to the front end, which right now doesn't seem to be using it?
2. If we don't need to need to include the table format, which way do we prefer to add the infor no in table_runtime 2.1. select info from DB for the given tables retrieved in the previous step 2.2. retrieve the info from TableManager(for example add a function TableManager#getTableRuntime(int tableId)), which needs to maintain an tableId to tableRuntime relationship in memory

I'm leaning towards option 2.2 with not returning the table format to the front end because it reduces the number of DB requests by one

Please let me what you think about this, thanks. @zhoujinsong @majin1102

I think decoupling from TableService and TableManager is a good idea. We may seperate dashboard server from ams in the future. TableFormat seems unnecessary in this page for now

[klion26]

@baiyangtx thanks for the review, the bottle-neck here is not the cost of the sort, but we retrieved too much data from DB, the solution here wants to limit the row number when retrieved from DB(the sort in SQL is needed because we want to show the 'running' status before the 'idle' status in the frontend)

[klion26]

@majin1102 sorry for the late reply, I've drafted a version such that: TableRuntimeMeta is used for retrieving from db, TableRuntime is used for data transfer object in ams. could you please take a took if this is the right way when you're free? thanks.