Attendees:
Serge, Emmanuel, Fabrice, KT, Daniel, Douglas, Jacek,
(and Jeff listening)
Serge
- partitioner: final testing, will push to master
this Friday, ready for integration w/qserv
- duplicator: will be done end of next week
--> make sample refmatch partitioned data available
to Daniel for testing
- integrate with new parser, integrating with old code
would be a waste of ~2 weeks
- side mtg Serge/Daniel re refmatch integration with
new parser APIs
Daniel
- parser: lots of real work done, building in flexibility
for different partitioning schemes
- useful, eg with htm, might want to build overlaps
on the fly
- testable in a few weeks, tbd if will be ready
for large scale tests late June
- shared scans: test it independently from the large
scale test
- shouldn't have any scalability issues, it is per node
Douglas
- setup for testing concurrency on yillis - still debugging
- working on node mgmt tool
- suggestion: look at paramiko, scidb uses it
Fabrice/Emmanuel
- automatic loader for pt 1.1 and unit testing done,
adding more queries and plugging W13
Jacek
- metadata: all prep work done, transient cache etc,
now doing the core work on changing qserv to
integrate it with metadata
- tested pipeQA on W13 data set
- 2 columns with same name issue --> try aliasing
- new parser should fix that
Exposing qserv to few selected users
- perhaps do it now if there is interest,
just explain the limitations
- better version (partitioned RefMatch, new parser and more)
will not be available for at least another month or two
- refmatch integration depends on new parser now
- polygon based searches:
- implementing through qserv non trivial (query composed
on 3 queries), probably a month of work to implement
code in qserv to support it correctly
- can be rewritten as one query with join, but complex
- might introduce special sql syntax and hide complexity
under the hood of qserv
-- maybe look at adql and adopt
- short term solution: get rid of @poly, use hardcoded value,
just to run pipeQA demonstration
--> Serge will document the example
SHOW command
- could use faked schema in short term
- long term: proxy should query metadata
tool for generating empty chunks
- easy to put together based on existing scripts
- would be good to implement solid version, need short
design discussion Douglas/Daniel
ingest
- code written by KT is only for mysql, qserv should
use something different (new)
- better to use fits tables, not csv
- pipelines will be delivering data in chunks as
produced by individual pipeline processes,
- qserv should ingest whole chunk or nothing.
- implement loading plugin that depends on afw
(because of fits tables) and on qserv loader API
- this is long term, short term just
write design doc
Design documentation
- need to write or improve documentation for many things
prior to the July review
- data distribution
- data ingest
- schema evolution
- provenance
- fault tolerance
- and more...
--> work in smaller groups over the next few weeks/months
on all of these
Views
- only power users get to define views
- should be doable if views used only for very well defined
isolated cases, such as
- hiding columns
- joining similarly partitioned tables (eg source x object)
- joining small dimensions tables (star schema)
- join table that has been split into several tables,
eg Object_core, Object_extras, Object_photoZ etc
Next larger qserv meetings 3rd Thursday of next month.
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
|