I don't know enough about the nosql type solutions to help with those, and maybe the full data set is large enough to warrant going that direction.
But if you want to use MySQL or some other relational database, there are lots of examples of databases that store an arbitrary number of attributes about some entity. The structure for this sort of data is a "long, skinny" table- i.e., you have a table with three columns:
ID
Data type
Data value
Then you can easily run your query, although if you want to have both numeric and text values in the same column you'll have to use some conversion tricks. I'd probably try to design that away, perhaps doing something like this:
ID
Data type
Numeric value
Text value
Or better: split the numeric and text data into two different tables.
You can get fancier from there- i.e., make data type into a code and control allowed values with another table, put in some foreign keys to indicate which entities these data apply to, etc.
MySQL is only useful for tables that have a defined number of columns, I think the best idea is to draw up a database schematic, where your database is in 3rd normal form and decide from there.
"however I do not know ahead of time what the columns will be". Exactly, this is a typical scenario where a relational DBMS is not very suitable. This is rather a case for something that can store large matrices or multidimensional arrays of data, e.g. HDF5
You cannot plan, if you dont know what your planning. So I think the best bet is to wait until he/she receives the dataset
@harpalls I have the datasets. There are many. It'd be a waste of time to write schema.