 |
 |
Yup, I had this impression the new data distribution system will have it's own way of keeping metadata, and that is perfectly fine. I think I'd rather wait few months than develop something zookeeper-based that we know from the start is a very temporary patch. Jacek On 04/10/2015 05:20 PM, Fritz Mueller wrote: > I don't think that we're going to end up maintaining the chunk -> > worker(s) mapping inside zookeeper. It seems likely to me, rather, > that we'll end up maintaining this mapping in something like a DHT. We > could still hide that DHT beneath the CSS API alongside the zookeeper > part, though? > > I think it'd be fine to rough something in via zookeeper for the next > couple months, until we get the replication system in place. > > On 04/10/2015 04:40 PM, Jacek Becla wrote: >> Andy, >> >> We should implement saving the information in CSS about >> chunk locations (which chunk is loaded to which worker), >> something like what we have in: >> >> https://dev.lsstcorp.org/trac/wiki/db/Qserv/CSS: >> >> /DBS/<dbName>/TABLES/<tableName>/CHUNKS >> >> This is starting to touch on data distribution... >> >> Are you planning to implement it as part of DM-2385? >> >> Without that info, checking consistency of tables >> (DM-1898) does not make much sense. >> >> Thanks >> Jacek >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the QSERV-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1