Tracing has always been a key use case for time series data. But admittedly, it’s also one that past versions of InfluxDB could not handle as well as we wanted. One of the roadblocks was the cardinality issue. Tracing data is, almost by definition, high cardinality data and prior to InfluxDB IOx, high cardinality data could affect query performance.
Time series data is a sequence of data points generated through repeated measurements indexed over time. The data points originate from the same source and track changes at different points in time. Times series data includes data like stock exchange data, monthly inflation data, quarterly gross domestic product (GDP) data, and logs from IoT sensors.
A look at what Parquet is, how it works and some of the companies using its optimization techniques as a critical component in their architecture. As the amount of data being generated and stored for analysis grows at an increasing rate, developers are looking to optimize performance and reduce costs at every angle possible. At the petabyte scale, even marginal gains and optimizations can save companies millions of dollars in hardware costs when it comes to storing and processing their data.
Devices, developers, applications, and services produce and utilize enormous amounts of JSON data every day. A portion of this data consists of time-stamped events or metrics that are a perfect match for storing and analyzing in InfluxDB. To help developers build the applications of the future, InfluxDB provides several ways to get JSON data into InfluxDB easily.
Gathering data to explore a problem with power outages creating connectivity issues and ultimately draining a laptop battery. Monitoring locations that have intermittent power and/or connectivity outages can be challenging. In this article, I’ll show how to use InfluxDB, an open source time series database, InfluxDB Cloud and Edge Data Replication to store data locally and send it to a central location whenever possible.
People often ask us, “What is the best query language to use with InfluxDB?” The answer to this question has evolved a bit over the years – and the current answer might surprise you.
Partitioning can provide a number of benefits to a sharding system, including faster query execution. Let’s see how it works. In a previous post, I described a sharding system to scale throughput and performance for query and ingest workloads. In this post, I will introduce another common technique, partitioning, that provides further advantages in performance and management for a sharding database.
At InfluxData, one of the common questions we regularly get asked by developers and architects alike the last few months is, “How does InfluxDB compare to MongoDB for time series workloads?” This question might be prompted for a few reasons. First, if they’re starting a brand new project and doing the due diligence of evaluating a few solutions head-to-head, it can be helpful in creating their comparison grid.
This article would not be possible without the contribution of Lars Stegman. The OPC UA Client Listener Plugin was his own contribution to a long-standing issue. Telegraf now includes a new plugin highly anticipated by the community. The OPC UA Client Listener Plugin. So you might be asking yourself: what is the big deal? There was already an OPC UA Plugin — how is this different?
Understand the two dimensions of scaling for database query and ingest workloads, and how sharding can make scaling elastic — or not. Scaling throughput and performance are critical design topics for all distributed databases, and sharding is usually a part of the solution. However, a design that increases throughput does not always help with performance and vice versa. Even when a design supports both, scaling them up and down at the same time is not always easy.
