Closed Misakami closed 4 months ago
Hi @strongduanmu , Please help with this question, thank you!
Hi @Misakami, can you check your actual tables are all exist?
ds$->{1..4}.ration_trigger_trade_flow_$->{1..8}
Hi @Misakami, can you check your actual tables are all exist?
ds$->{1..4}.ration_trigger_trade_flow_$->{1..8}
Yes, I can guarantee that it all exists。 And I tried to fix it myself
Hi @Misakami, can you check your actual tables are all exist?
ds$->{1..4}.ration_trigger_trade_flow_$->{1..8}
I modified this part of the code,But I can only guarantee that it works for my usage scenario, and I don't have any more time to analyze it
tb_ration_trigger_trade_flow:
actualDataNodes: ds$->{1..4}.ration_trigger_trade_flow_$->{1..8}
keyGenerateStrategy:
column: key_id
keyGeneratorName: snowflake
hint_ration_trigger_trade_flow:
actualDataNodes: ds$->{1..4}.ration_trigger_trade_flow_$->{1..8}
databaseStrategy:
hint:
shardingAlgorithmName: hint
keyGenerateStrategy:
column: key_id
keyGeneratorName: asnowflake
tableStrategy:
hint:
shardingAlgorithmName: hint
@Misakami Why do we need to map multiple logical tables to the same actual table? This may seem unreasonable, because if we modify the table structure with the logical table tb_ration_trigger_trade_flow
, the logical table hint_ration_trigger_trade_flow
is not aware of it. In addition, when we use different sharding algorithms, it will also lead to data confusion.
tb_ration_trigger_trade_flow: actualDataNodes: ds$->{1..4}.ration_trigger_trade_flow_$->{1..8} keyGenerateStrategy: column: key_id keyGeneratorName: snowflake hint_ration_trigger_trade_flow: actualDataNodes: ds$->{1..4}.ration_trigger_trade_flow_$->{1..8} databaseStrategy: hint: shardingAlgorithmName: hint keyGenerateStrategy: column: key_id keyGeneratorName: asnowflake tableStrategy: hint: shardingAlgorithmName: hint
@Misakami Why do we need to map multiple logical tables to the same actual table? This may seem unreasonable, because if we modify the table structure with the logical table
tb_ration_trigger_trade_flow
, the logical tablehint_ration_trigger_trade_flow
is not aware of it. In addition, when we use different sharding algorithms, it will also lead to data confusion.
Because at some point for this table, I need to traverse the whole database to do some statistics,by using HintShardingAlgorithm(The amount of data is huge)
Please look at https://github.com/apache/shardingsphere/issues/8820.
This is not a standard usage. If you need to do some statistical SQL, you can try to synchronize the data to the big data platform through CDC.
This is not a standard usage. If you need to do some statistical SQL, you can try to synchronize the data to the big data platform through CDC.
For a table, there are scenarios where you need to use the user name to find data and specify to obtain all objects in a certain database table for processing。 I think this is normal
Bug Report
I used two sharding strategies for the same table This bug should have been fixed in 5.1, but I still encountered it in 5.3.0 see the issue https://github.com/apache/shardingsphere/issues/14273
Which version of ShardingSphere did you use?
shardingsphere-jdbc-core 5.3.0
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
ShardingSphere-JDBC
Expected behavior
no error
Actual behavior
Reason analyze (If you can)
I used two sharding strategies for the same table but just load the first sharding strategies。
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
see bug report
Example codes for reproduce this issue (such as a github link).
this is part of my strategies