Indeed, the challenges around data when designing the products are of different nature, making sure data are collected (choice of sensors) and possibly also processed locally (Edge AI), like the case of CERN I mentioned where Blue Yonder's detectors were used to filter out 100k events out of the 600M received by the detectors' CMOS arrays.
We are working on making WarpScript (http://www.warp10.io) able to fetch data from M3, so you can benefit from 850+ functions for analyzing your time series data.
The problem is the definition of high cardinality, the Gorilla paper talks about 2B metrics at FB but the hardware sizing page for influx shows a scary graph which basically kills any series cardinality above a million
Performance usually varies greatly with your set up. I have not tried the 1.1 release but earlier relases suffered very badly when authentication was turned on and when data came out of order. Nobody cares about the ideal case, it's never encountered.
What kind of project is that? Is it a side project or one that will give birth to a company? Requirements are rather different depending on importance you give to your (or your customers') data.
TempoDB has renamed itself into TempoIQ and no longer offer their storage service. I've heard some angry comments from customers who recently received an email telling them the storage service they were using was to be shutdown at the end of october!
Does treasure data have a dedicated storage engine for time series? This kind of data has specific needs which are not met by general purpose storage layers.
When it comes to time series, reasoning in terms of byte size does not really make sense, it's better to state how many datapoints you need to handle and in how many distinct time series they are distributed.