http://qs321.pair.com?node_id=1217578


in reply to Re^7: Best way to store/access large dataset?
in thread Best way to store/access large dataset?

I think you're best bet here is to ETL. I have a feeling you're going to want to query this stuff again at some point, and depending on what you're doing you may want to store your calculated results.

The question here will be how these attributes relate to the data. Is it a tree? Is it one to many? Is it many to many? Does each record have a million attributes, or is a group determined by a certain delimiter and that group has a total of a million attributes?

If you're looking at a tree data structure, it's probably best to either use Postgres' JSON options or something like DynamoDB or a database built specifically for handling tree data (Neo4j was the last one I knew of but I'm sure others have come about). If it's one row to a million attributes, you probably want to look into some sort of partitioning. This still probably calls for something like DynamoDB since joining that amount of data is going to be a nightmare. Someone like erix can correct me but my personal experience with large amounts of data that require a lot of assembly/transformation has been to use dynamo/cassandra + storm/EMR+Spark.

I'm not sure if this is all stuff you've considered yet, so please forgive me if I'm just reiterating what's been brought up previously. You might be able to get away with storing this all in an RDBMS and using an EMR cluster to perform the calculations and transformations if you can partition and do everything in memory, but I feel like you're still going to have trouble joining all that data together in a traditional RDBMS without getting clever.

Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

  • Comment on Re^8: Best way to store/access large dataset?

Replies are listed 'Best First'.
Re^9: Best way to store/access large dataset?
by Speed_Freak (Sexton) on Jun 28, 2018 at 19:15 UTC

    ETL? And there are a core group of files that will be repeatedly analyzed. But the overall sets change. So files can be added or removed from the calculations as needed.

    Each record has 3 "columns" of data with a million rows per column. There are a couple other static values that are a single value. I believe that is one to many? And the samples can be grouped by another singular static value stored with the record. (The shape identifier.)

    I'm pretty lost when it comes to the database stuff, so I'm going to point my colleagues here and see what they say honestly!

      ETL is extract/transform/load. So basically you'd be taking your raw data, extracting it out of the files and transforming it into a sensible format or data structure, and loading it up into a persistent data store.

      A million rows per column is much more reasonable than a million columns. That's still a ton of data depending on how many parent rows the associated rows have. I have some ideas but honestly it's probably best to get your co-workers feedback since they know the data and ask whatever other specific questions you have.

      Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past