Amazon re:Invent is a major technology event every year. At this year’s re:Invent, the keynote by AWS CEO Adam Selipsky made a concerted effort to draw connections between technology and some of the key challenges that people around the world, and in some cases beyond the terra firma of Earth, face. While the presentation touched on a wide range of topics, one overarching theme was the intersection of the physical and digital worlds, and the role technology plays in bridging that divide.

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.

Mean time to resolution (MTTR) is a metric that transcends industry and technology. It’s a measure of how quickly, on average, support teams identify, act, and resolve IT issues and incidents. Because MTTR directly relates to service quality, maintaining a low MTTR is a critical goal for DevOps and SRE teams. These teams have a vested interest in resolving issues quickly because escalating incidents to higher levels of the support team increases response and resolution times.

Fluentd is an open source data collector capable of retrieving and receiving event data from several sources and then filtering, buffering, and routing data to different compatible destinations. It utilizes a plug-in system to help you quickly set up specific inputs, apply any required filtering, and send data to your preferred data ingestion platform. Fluentd supports multiple sources and destinations, and it can be deployed to multiple operating systems, including Windows, Linux, and macOS.

Time series databases can help telecommunications companies become more reliable, efficient and productive. The telecommunications industry is undergoing rapid change as a handful of new technologies and government actions change the underlying business landscape and create space for new companies to innovate and disrupt the established players.

Time series data (also known as time-stamped data) refers to a collection of observations (data points) measured over time. When plotted on a graph, one of the axes for this type of data will always be time. Because time is part of every observable entity, time series data can be used in all kinds of industries, like the stock market, weather data, logs, and traces.

Is Telegraf too big for your device? Too many plugins in one binary getting you down? Let me introduce you to the Telegraf custom builder – the new tool for reducing Telegraf’s overall memory and disk footprint. In this blog, we will discuss the “what, why, when” and also how to use the new custom builder.

According to the old adage, life’s a journey not a destination. The same can be said for software. It’s unlikely that any developer would ever say that something they built was truly done. There are always bugs to squash, features to add, and updates to implement. As a company intensely focused on time and the context of time, it comes as little surprise that these themes played a significant role in Paul Dix’s presentation for InfluxDays.

This week at InfluxDays we announced that Flux 1.0 is coming soon. Version 1.0 of Flux lang is a commitment to no longer make breaking changes to the Flux language. Importantly, today’s Flux scripts will work on Flux 1.0, and no breaking changes will be introduced between now and the release of Flux 1.0. Along with version 1.0, we have some features we are also releasing soon. Here are the features we have coming and a short explanation of why you might want to leverage them.

Last week InfluxData announced IOx, the new time series engine for InfluxDB. We’ve revisited the core of our database to achieve big things with the underlying technology. Users can expect higher performance and more options for querying data. Here’s a quick intro to some of the most exciting things coming with InfluxDB IOx.

SAN FRANCISCO, November 2, 2022 – Today, InfluxData, creator of the leading time series platform InfluxDB, announced significant product enhancements at InfluxDays 2022, its annual developer and community event. New features including InfluxDB Script Editor, Telegraf Custom Builder, and Flux 1.0 support developers working with time series data, allowing them to do more with less code.

The InfluxDB platform has evolved a lot over the past decade. But with every innovation we’ve added to the platform, the focus behind our efforts has remained the same: Build cool stuff for people who build cool stuff. What we mean by this is we want to make it incredibly easy for users to build valuable applications with their time series data. We do that by offering a wide range of tools, features, and resources that meet builders on their terms.

We love to write and ship code to help developers bring their ideas and projects to life. That’s why we’re constantly working on improving our product in sync with developer needs to ensure their happiness and accelerate Time To Awesome. This month is very special. We now have a new engine that significantly increases the “horsepower and torque” for InfluxDB.

Native MQTT eliminates the need to write custom code, orchestrate additional technology layers or incorporate additional hosting services. MQTT is a powerhouse within the Internet of Things (IoT) space. Its pub/sub model and lack of defined payload structure make it infinitely adaptable to the needs of modern sensors, devices and systems. IoT data is also time-series data.