[Bioc-devel] range-directed metadata management
Steve Lianoglou
lianoglou.steve at gene.com
Thu Jul 10 23:16:55 CEST 2014
Hi,
On Thu, Jul 10, 2014 at 1:52 PM, Vincent Carey
<stvjc at channing.harvard.edu> wrote:
> a new, more inclusive GWAS catalog is available (GRASP, from Andrew Johnson
> at NHLBI), with 6 million records and voluminous metadata (though it seems
> sparse and perhaps can be trimmed/reshaped)
>
> i made a GRanges and it takes 3 minutes to load. even after stripping all
> the
> metadata, a GRanges with 6 million records takes 20 seconds to load.
> that's probably acceptable, but a managed chromosome-specific distribution
> might
> be closer to interactive availability.
>
> the metadata probably would be best kept in SQLite. it occurred to me to
> consider an arrangement in which we have the GRanges managing the ranges
> and a key to the database. range operations can engender queries to
> retrieve metadata, metadata queries in the db can generate indices to
> retrieve matching ranges.
>
> is anyone doing something along these lines?
You might consider just stuffing it all in the database.
SQLite supports RTrees, which is a spatial index, so you could in
theory get the fast overlap stuff baked in w/o a need to have a
parallel GRanges object to index into the database:
http://www.sqlite.org/rtree.html
Before the reboot of the GenomicFeatures package (we're talking around
2008/2009?) I was doing something like that for genomic annotations.
The way that Hadley has abstracted db access in dplyr to make a
database look like a data.frame and respond to all the "data
manipulation verbs" in the same way gives me inspiration to believe
that we can do the same and make the database look essentially like a
GRanges / VRanges object and get cooking that way.
Hopefully this answer was at least minimally aligned in the direction
of what you were asking ;-)
-steve
--
Steve Lianoglou
Computational Biologist
Genentech
More information about the Bioc-devel
mailing list