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

I wish I knew more on this subject. If it makes a difference, there wont be any writing going on to the database during all of this. It is purely read. And from what little I've read, Postgres isn't recommended when you're looking for speed in purely read operations?.
The database doesn't exist outside of its current test iteration, so there is still time to change it. But I wouldn't know what would be a better option.

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

Replies are listed 'Best First'.
Re^4: Best way to store/access large dataset?
by stonecolddevin (Parson) on Jun 22, 2018 at 19:44 UTC

    I'd be curious to see what you read that said Postgres wasn't recommended for lots of read operations. I don't think I've ever heard that before.

    If you're deeply invested in mariadb, it's probably fine. mysql has a lot of pitfalls, but people use it in large scale cases all the time.

    Regardless, my personal preference is Postgres. I don't think there would be an issues using it for high read volume or processing a large number of calculations, but it depends on what kind of traffic it's going to be taking. If it's a really specialized case, it's probably worth looking into some ETL (extract/transform/load) on AWS using EMR (Elastic MapReduce) and/or Athena.

    The key things here are how much data you're dealing with, how many calculations you need to perform, and how resource intensive those calculations are. I think Postgres will be just fine up to several million rows but if you're doing a ton of joining it might get hairy and be better to spread the work out a bit.

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

[reply]

      I did a quick google on Postgres pro's and cons. I did just read further in the comments that it's solvable by "adding connection pooling on front."

      I'm open to anything really. The boss didn't wanna pony up the cash to get someone in here that could make solid reccomendations....so we're just winging it! One of my colleagues is familiar with Mariadb, so we went with it.

      The database holds environmental sample data. Each sample contains just over three million data points. For what I'm describing here, I have to pull just under three million of those points for around 200 samples worth of data. (200-300 should be the normal data load.) That initial pull of data will be around 1.8 billion calculations if the qualifiers are relatively simple. The qualifiers are user definable, so they could range from simple greater than/less than, to various combinations of percentages of different values from the database. Following that comes this script which will ultimately perform an additional ~49 million calculations on the summary table to find the unique attributes.(A chain of greater than less than qualifiers based on attribute count and category count for each attribute in each category.)

[reply]

        So when you say "pull calculations", are you talking about performing calculations in the script or pulling data from the database? If you're doing several million/billion calculations against a datasource, it's probably better to try to do some map reducing in a parallel fashion using something like dynamodb and spark/emr. Pulling the rows won't be so hard but having the database crunch a bunch of numbers gets hairy if it's not optimized as such.

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

[reply]

In Section Seekers of Perl Wisdom