3 ms·

Unfortunately many tools in genomics (and biotech in general) still depend on local filesystems- and even if they do support S3, performance is far slower than

• seized 3y ago
  The latency is higher so the key is parallelism... Which means you need more cores/hardware/VMs/pick your poison. New but same problem...
  • dekhn 3y ago
    Is single-job performance the only criterion? Or can you just run a bunch of different jobs at the same time (genomics has many embarassingly parallel problems, often per-sample) and use the higher aggregate storage bandwidth of your object store to get "more work done in unit time".
    • seized 3y ago
      I did the latter, across usually about 4000+ CPUs. That got me a peak of 15 or so GB/sec read from one GCS bucket, writing to another. But yeah if it's not something that can be paralleled then it sucks.
• epistasis 3y ago
  Most of these tools treat the "local file" as a stream which can be a pipe to a network stream from the object store. The files that are not streamed and need random access are often better on a local ephemeral SSDs or in RAM after a fetch of the, say, 50GB hash table, or whatever it is. At least, that's my experience: streams and in-RAM pre-processed DBs are >99% of file IO.
  • dekhn 3y ago
    I didn't make my statement out of ignorance. Most of these applications depend on OS optimizations that have been made over the decades; multithreaded readers, readahead, and caching are critically important to read performance. In principle, a remote storage system could be as fast as a local disk. This includes random access. after all, the storage system is just a bunch of drives attached to machines connected by networks. When I worked at Google I wrote a mapreduce that converted BAM files to sstables which are sorted, sharded by key, and sit in an object store like S3. Once the files were in sstables (or columnio) we could do realtime analytics using modern tools.
    • epistasis 3y ago
      Right, most people that try to really optimize these things do not have access to the parallelism tools thay Google has built, and end up doing their own ad-hoc sharding schemes. Things that can be built by 1-3 people over the course of a few weeks tk solve ann immediate scaling problem. And of course BAM itself dates back to before standardized serialization formats were brought out of Google. Even with potential optimizations, initiating a seek on GCS or S3 is far far slower than on a local SSD, so even if Google exposes fast cross-network seeks on objects inside an internal object store system, it is not readily accessible to the plebes like me and 99.9% of genomicists that use cloud systems or their own hardware.
      • withinboredom 3y ago
        Of course it’s slower. Your using https to do something that’s meant to be raw binary. The overhead is killing you. Something like iscsci, is pretty quick compared to https as a storage protocol.
        • epistasis 3y ago
          Which is exactly why using standard Unix/POSIX files makes sense as a universal interface for genomics programs that are run in highly heterogeneous environments across the world, even if it leads to software engineers wishing that their internal custom data storage systems were used instead. If random access is needed in a cloud environment, use either that local ephemeral SSD, or a cloud block device which is probably just an iSCSI implementation underneath, or at least a close equivalent. Operating fleets of compute and IO in cloud environments means that POSIX semantics generally work really well for genomics. Folks that have reimplemented basic genomics algorithms on top of protocol buffers standardized serialization still store them as BLOBs, and have not delivered benefits that can be realized in publicly available compute environments.
          • withinboredom 3y ago
            I’m still waiting for people to realize nvme doesn’t have to be local in newer kernels. That’s when the real fun will begin.