Yes, using watch function of register center has the minimal side effects to current architecture. Metadata in local memory will refresh according to the refresh event.
------------------ Zhao Jun (cherrylzhao) Apache ShardingSphere & ServiceComb > On Jan 20, 2020, at 10:11 PM, guangyuan wang <[email protected]> wrote: > > For byte[] value, I think we could find a way to resolve. > But refresh metadata without affecting running instance, I am not sure. > Registry Center provides a watching function, does it could be used to > refresh metadata? > > zhaojun <[email protected]> 于2020年1月20日周一 下午5:23写道： > >> If we store raw column metadata into orchestration, byte[] value should be >> supported in orchestration. >> metaData could be serialized into byte array using kryo framework etc >> >> Also we should consider about refresh metadata without affecting running >> instance. >> >> ------------------ >> Zhao Jun (cherrylzhao) >> Apache ShardingSphere & ServiceComb >> >>> On Jan 20, 2020, at 5:02 PM, guangyuan wang <[email protected]> >> wrote: >>> >>> What kind of help do you need in the orchestration module? The >>> orchestration module provides functions: writing and reading key-value >> pair. >>> >>> Nicholas <[email protected]> 于2020年1月17日周五 下午4:02写道： >>> >>>> Hi zhaojun, >>>> About ColumnMeta storage, we need ShardingSphere's orchestration >> module >>>> to help register column metadata. And at best establish metadata module >> to >>>> manage metadata of table, column etc. Field property like primary key >> etc >>>> should be put into ColumnMeta to maintain. At last, could you please >>>> provide the design document of MetaData Model & MetaData service, and >> take >>>> distributed scenario into consideration. >>>> >>>> Thanks, >>>> Nicholas >>>> >>>> On 2020/01/15 04:26:48, zhaojun <[email protected]> wrote: >>>>> Hi, all >>>>> >>>>> I have created a issue[1] for discussing about optimizing metadata >> model. >>>>> >>>>> Currently ShardingSphere metadata was only used by sharding & encrypt >>>> scenario, >>>>> master-slave case have to get them from underlying ResultSet meta in >>>> sharding-proxy. >>>>> It is better to establish an global MetaData mechanism which provide >>>>> uniform interface for initialization, read, refreshing instead of >>>> distinguish with usage scenario >>>>> >>>>> I think it would be a big refactor for sharding-jdbc & sharding-proxy. >>>>> assume that task list is as below >>>>> >>>>> 1. investigate the usage of current metadata, clarify the function list >>>> of metadata (SQLParse, Route,Rewrite etc) >>>>> 2. design a MetaData Model & MetaData service, at first only consider >>>> about storing in memory >>>>> 3. then consider about migrating to zookeeper or other registration >>>>> >>>>> [1]: https://github.com/apache/incubator-shardingsphere/issues/3922 < >>>> https://github.com/apache/incubator-shardingsphere/issues/3922> >>>>> >>>>> Any thought? >>>>> >>>>> ------------------ >>>>> Zhao Jun (cherrylzhao) >>>>> Apache ShardingSphere & ServiceComb >>>>> >>>>> >>>> >> >>
