The cost of storing time series data at scale - and in Uber’s case, this meant roughly 8.5 billion data points per second in 2018 - can be a business killer. M3DB is M3’s native distributed time series database, written in Go. M3 Aggregator is designed to be highly available, supporting clustering and replication. The M3 Coordinator sends its data to M3 Aggregator, which handles stream-based downsampling of data, before passing it on to M3DB for storage.
Though the M3 Coordinator can handle aggregation as it processes data on the way to M3DB, M3 also has a dedicated metrics aggregator: M3 Aggregator. Early on though, the M3 Coordinator can work alongside Prometheus to ease the transition to the M3 platform. In a sense, the M3 Coordinator is a collection agent: it can collect, process, aggregate, and down-sample data, and then send that data to M3DB for ingestion. M3 lowered the bar of entry for those using Prometheus as a collection agent by building the M3 Coordinator as a Prometheus sidecar. For users familiar with Prometheus, remote and scalable storage of collected data was a hurdle.
The M3 Coordinator functions as a bridge between the collection agent and storage in the M3DB. M3's main components include the M3 Coordinator, the M3DB (which contains the native TSDB), and the M3 Query Engine. More than just being a standalone TSDB, it is a time series platform that includes a distributed TSDB. M3, birthed from the massive metrics scalability needs at Uber, bills itself as a metrics engine. And if you're interested in using M3 as part of an observability solution, go ahead and read our case study about how Aiven did it internally. Let's start things off with a tip: if you're new to time series databases, you might want to start with our blog post An introduction to time series databases or An introduction to M3.
0 kommentar(er)
