Masahiro Tanaka, Yuji Shirasaki, Masatoshi Ohishi, Yoshihiko Mizumoto (National Astronomical Observatory of Japan) , Yasuhide Ishihara, Jumpei Tsutsumi, Yoshihiro Machida (Fujitsu Ltd.), Hiroyuki Nakamoto, Yuusuke Kobayashi, Michito Sakamoto (SEC Ltd.) URL: http://jvo.nao.ac.jp/index-e.html
Introduction and Motivation
In a case where a VO user collects all the available information about an astronomical object, it is necessary to send queries to all the VO services. However, this would be inefficient since most services tend not to have data on the target object.  We thus developed a new query system for users to efficiently find all the available information from multiple catalogs.
Design of Table Partitioning
The design of this database is one of key issues; an efficient query mechanism for more than billions of objects is required.  We employed the Table-Partitioning technique and developed a method to build queries for the partitioned tables. Table design: Partitioning with HTM (Hierarchical Triangular Mesh) Upper level : level 6 : 8 × 4 6 = 32768 segments Tables are partitioned by Upper HTM level : 32768 tables psc_32768 | table public .22769 public public A Region Query: select ra, dec, 1 m where Region("Circle 0 0 10"); is converted to the following SQL: from ( zelect ) from pac_63488 where htm_id_batween_0_and_4194303 zelect * from pac_63488 where htm_id_between_12631488 micm select * from pac_47104 where htm_id_between_0_and_4194303 from pac_47104 where htm_id_between_13631488_and_16777215
Performance of Table Partitioning
Comparison with PostgreSQL’s partitioning function PostgreSQL is equipped with Table Partitioning function after the version 8.1.  We compare the performance of our method with PostgreSQL's partitioning function. For this test, we used 2MASS All Sky Catalog including 4.7 billion objects. Note: PostgreSQL cannot handle 32768 tables at once since it consume too much shared memory.  Therefore, we define the partitioning level as 2048 tables. Measured elapsed time: We found our method is 6-150 times faster.  This result shows that the partitioning with HTM is quite useful for searching a large database for some celestial object.
Design of Multiple Catalog DB
For the multiple catalog DB we employed a simple FLUX- Table design of Multiple Catalog st information based format  shown in the right. Object ID It is another key issue to store catalogs of various data Object narra format into a table of single format.  In this format, each on information Right Ascenald record has  only one FLUX column, which is different from Dedration the conventional  OBJECT-based format where object Position essen HTM Index records commonly have multiple-band flux data. In our ich informato tand name multiple catalog DB, these flux data are decomposed and band unit. stored in separated records.  Multi-wavelength information  of information objects such as the SED (Spectral Energy Distribution) is flux_et obtained by  grouping  the flux records in terms of position. thex unit flax in Jy x_arch Further information about the object can be obtained by 98 informat accessing the original catalog shown  in the "link_ref" column. Link to reference Ink_ref D in original cal ore  19 at_id
New User Interface of JVO Portal
URL: http://jvo.nao.ac.jp/dev/portal/