Jeg bruger alle de databaser du nævnte. Til denne belastning kan jeg anbefale MySQL eller PostgreSQL, fordi jeg allerede har arbejdet med endnu højere belastning på PostgreSQL. Men MySQL vil også gøre det samme arbejde - måske endnu bedre, fordi det fra begyndelsen blev designet til høj skærbelastning.
Løsningen på PostgreSQL, jeg arbejdede med, blev brugt til at gemme systembeskeder fra telekommunikationsnetværket og var i stand til at indsamle ~300GB data pr. dag på én maskine uden problemer. Men du har brug for ordentlig HW-arkitektur.
Du har brug for maskine med mindst 8 CPU, men mere er bedre, og du skal have flere indsættelseskøer. Brug loader i Java eller C eller golang med flere parallelle trusler, og lav masseindsættelser fra hver trussel ved at bruge COPY-kommandoen til ~10.000 poster i én bulk. Du skal bruge forbindelsespuljen, fordi PostgreSQL har højere overhead for at åbne en ny forbindelse.
Det vil også hjælpe dig med at distribuere data over flere tablespaces hver tablespace på separat fysisk disk eller bedre på separat fysisk diskarray. Hvis det er muligt, undlad at bruge indekser på rådata. Adskil dine rådata fra aggregerede resultater.
Vi havde en anden løsning med pl/proxy-udvidelse til PostgreSQL og flere fysiske maskiner til rådata opdelt efter tid. Dette system var i stand til at indsamle mindst 1 TB om dagen, men med en passende mængde af slavedatabaser endnu mere.
Men du er nødt til at forstå, at for virkelig at behandle denne mængde data, har du brug for ordentlig hardware med korrekt konfiguration. Der er ingen magisk database, som vil gøre mirakler på en "notebook-lignende konfiguration"...
InfluxDB er en rigtig god tidsseriedatabase, og vi bruger den til overvågning. Jeg tror, at med nok CPU'er og rigtig meget hukommelse vil du også kunne bruge det. Jeg vurderer, at du skal bruge mindst 64 GB RAM, fordi indsatser er dyrere hukommelse. Så med flere indsættelseskøer vil databasen have brug for meget mere hukommelse, fordi den gemmer alt i hukommelsen og laver automatisk indeksering af tags.