Is it ok to have one record per hour with sixty columns for each minute ?
Or is it better to use a non relational database ?
No. That's wasteful and makes many types of queries very hard to write.
A good way of storing the data is only storing change events. So for example, each time a stock ticker changes you store a new row with the timestamp and the new value for the stock. This achieves very high level of "compression" since most stocks values doesn't change every minute. But it depends on what kind of data you have.
Are you serious? Stock data changes every second and sometimes earlier than that.
You can also bulk insert records, rather than 1 at a time.
We have 2k operations per second on our aws rds.
I was paying around recently with Amazon's Kinesis for this, but if you don't want the vendor lock-in you could easily roll your own system that bundles up events and stores a bunch at once.
open database connection
do one insert
close database connection
That adds up fast.
At work, I've been very disappointed in the performance of their Amazon RDS. They had unexplained master/slave replication issues.
You also can put a memcached in front of the database.
https://engineering.linkedin.com/distributed-systems/log-wha...
Further, you didnt mention at all your read requirements. Without that any recommendation you could possibly get would be useless.
That said, any decently tuned RDBMS/sql app can easily handle thousands of writes a second, especially if you are just dumping them into giant buckets of resolution.