You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2022/10/10 06:41:26 UTC

[GitHub] [shardingsphere] Glowdable opened a new issue, #16880: why did we need SingleTableRule?

Glowdable opened a new issue, #16880:
URL: https://github.com/apache/shardingsphere/issues/16880

   why did we need SingleTableRule? It's good feature for beginner. But It's too bad for production that people can not  limit its influence.More seriously It‘s too slow when loading the metadata of all my tables.
   The ShardingSphere is a componentized design so I can only use read write spilt functionality, But it still loads the metadata of all my tables.
   
   That's totally unnecessary.This is the case.
   
   First, the application configure the default database where  I can find the none sharding table
   Second , the ShardingSphere only load the configured  sharding tables
   Third,  the application sent a sql that did not contain the sharding table
   Forth,the ShardingSphere forward the sql to the default database ,then forward the execution result of the default database to the application.
   
   At last,the ShardingSphere  maybe can provide a way to disable SingleTableRule functionality instead of making it a required option


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] github-actions[bot] commented on issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on issue #16880:
URL: https://github.com/apache/shardingsphere/issues/16880#issuecomment-1272349982

   Hello , this issue has not received a reply for several days.
   This issue is supposed to be closed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] strongduanmu commented on issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
strongduanmu commented on issue #16880:
URL: https://github.com/apache/shardingsphere/issues/16880#issuecomment-1100772013

   @Glowdable Thank you for your feedback. Using default database configuration requires users to be aware of the underlying database, which requires a certain usage cost. ShardingSphere hopes that users can use it like a native database.
   
   For what you said, ShardingSphere only needs to load the sharding table, which is obviously wrong. In different scenarios, we also need the metadata of table to make decisions, such as encrypt rewriting or query optimization.
   
   Finally, if you encounter some performance issues with SingleTableRule, feedback is welcome and we will try to optimize it.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] strongduanmu commented on issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
strongduanmu commented on issue #16880:
URL: https://github.com/apache/shardingsphere/issues/16880#issuecomment-1323374662

   This question has been asked, so I will close it now.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] github-actions[bot] closed issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
github-actions[bot] closed issue #16880: why did we need SingleTableRule?
URL: https://github.com/apache/shardingsphere/issues/16880


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] strongduanmu closed issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
strongduanmu closed issue #16880: why did we need SingleTableRule?
URL: https://github.com/apache/shardingsphere/issues/16880


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [shardingsphere] Glowdable commented on issue #16880: why did we need SingleTableRule?

Posted by GitBox <gi...@apache.org>.
Glowdable commented on issue #16880:
URL: https://github.com/apache/shardingsphere/issues/16880#issuecomment-1100792322

   It's not wrong. I think that Sharding and read-write spilt  are the basic functions of ShardingSphere.
   
   We have to make sure the basic functionality is usable and user-friendly before extending other functionality.
   In other words, we cannot sacrifice the availability or performance of basic functions for some unimportant or infrequently used functions.
   We can do a survey to see how many people use encrypt rewriting or query optimization.
   And how many people are willing to sacrifice the performance and usability of basic functions for these functions.
   
   Moreover,why can't we provide a choice,only want to use the core functions, then we provide a better performance and more user-friendly implementation, and it is also optional to be willing to sacrifice the availability of some core functions for other functions


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org