unless we missed it, there is no special optimization for spatial searc=
hes, will need to look into that
plan: evaluate for few weeks (mostly John, with help from Brian from th=
e Fermi team)
need to consider L3 use cases
how to handle virtual files? Register and keep information in the catal=
og, generation data on the fly as needed
format of generated fits headers?
Simon Krughoff and Frossie Economou are working on defining stan=
dardizing LSST fits header structure, they will come up with a template
Naming
"global catalog"? NO! The worst choice
"metadata store". Yes, it is ok, at least for now
List-bases service
belongs to Data Access more than SUI, Data Access knows better how to o=
ptimize
tentative decision: don't keep as a standalone service, push into Qserv=
and Image Service
example for qserv: user uploads a list of (ra, decl, distance) points t=
o a table, writes a joins with that table
worry: most obvious way for user to write this query will be very slow.=
There are ways to optimize it internally under the hood, Serge knows how. =
Not obvious how much complexity it will bring. Will discuss at Qserv meetin=
g tomorrow
Security
every science user should have mysql credentials
yes, we can still do single sign on: web api will wrap it and upon succ=
essful authentication (through a cookie or whatever) it will find and use m=
ysql-credentials associated with that user
Location of metadata
central store better than kept near the data
file systems are bad with searching
we can always use distributed key-value store if needed to scale
Future meetings
weekly, Mondays at 11:00 am pacific, starting this coming Monday Nov 24=
, via standard database hangout (nwb)