Timeline for Design Question - Storing timeseries in a key-value store
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25 at 5:56 | answer | added | Rob | timeline score: 1 | |
| Jul 23 at 20:49 | answer | added | JimmyJames | timeline score: 2 | |
| Jul 23 at 15:27 | comment | added | Thibe | Not sure if this really fits as an answer, thus only a comment. It might be worth to take a look into some simple compression techniques, e.g. store one or few base-timestamps and make all other timestamps relative to that and thus are much smaller. Depending on the approach this may or may not affect the time to find the entries. | |
| Jul 23 at 15:16 | comment | added | Thibe | Is there a use case to query a time range for all or multiple job_ids? Even if it is a use case, is it rare enough to justify a more complex storage and handling? Storing one separate time series per job_id would require the job_id only once without any hash values. | |
| Jul 23 at 12:47 | answer | added | Doc Brown | timeline score: 2 | |
| Jul 23 at 11:45 | comment | added | Thomas Koelle | I would try to figure a rough estimate for how much more space per month a readable format would cost, and then talk to some hardware people about the price of that memory/storage. | |
| Jul 23 at 11:43 | history | edited | nz_21 | CC BY-SA 4.0 | deleted 14 characters in body |
| Jul 23 at 11:38 | history | asked | nz_21 | CC BY-SA 4.0 |