Share your experience using IBM IMS

My main use case for InfluxDB is that we are an IoT-based company with sensors and hardware, and we store sensor data into InfluxDB for time series purposes.

A specific example of how I use InfluxDB with my sensor data involves a temperature sensor that requires readings every 30 seconds, such as temperature readings of 20 degrees or 40 degrees. We receive a sample every 30 seconds for temperature, and we also have energy data where we get a 30-second sample based on voltage and current measurements. We receive these kinds of data every 30 seconds, which amounts to a large volume of data per minute.

Regarding my main use case, we typically have sensor data, energy data, and HVAC data every 30 seconds. This is time series data, and it is substantial in volume. InfluxDB, being a time series database, is the only database suitable for storing this data. It is not feasible to use any other database for our purposes, so we chose InfluxDB.

we are the startups company but we have too much data we store for 30s interval , managing our own DB solution is very tough for us, we don't want to manage on premises DB, we choose to influxDB cloud DB. and for monitoring purpose we use free version with docker to publish application metrics.

The best features InfluxDB offers are related to the cloud version, which is very useful because there is no burden at all in maintaining an on-premises server. Everything is handled by InfluxDB, and we also have access to the support team. If we need optimization or help with queries, we ask for guidance and optimization from InfluxDB.

InfluxDB has positively impacted Energy Box by being the best choice for our needs. The cloud version and time series capabilities, along with a task scheduler, allow us to schedule tasks such as converting data from 30 seconds to one hour or one day. We can automate this process, so we do not need to worry about conversion code or scripting. We simply retrieve the data from InfluxDB.

How InfluxDB can be improved is relevant since for Energy Box, we face certain issues. We have customers worldwide, including the United States, United Kingdom, and Europe, but when we expanded to China two years ago, they indicated that they do not support the cloud version there. Our application is built on the cloud, which required us to create a separate application for Azure China, which was painful for us. The second issue involves frequent version changes. For example, we started with version one, transitioned to version two, and I heard they are considering InfluxDB version three, reverting to earlier practices. InfluxDB should improve without completely changing its approach. Now we have to redo our work for InfluxDB version three.

Regarding needed improvements, the documentation is sufficient, but pricing presents a challenge. InfluxDB has standard pricing, which is acceptable for large companies. However, for startups in our position, they should provide special discounts so everyone can utilize it. The pricing should adapt as companies grow, which is a reasonable expectation.

I have been using InfluxDB at this company for the last four years with Energy Box.

Regarding features and performance, we sometimes face outages. One of the biggest outages occurred when AWS experienced downtime, and we suffered considerably because InfluxDB cloud is hosted on AWS. We endured this for almost the entire day. Apart from that, we regularly encounter query issues. Additionally, we have another environment for Azure China, where unfortunately, the InfluxDB team does not support the China region. They indicate that we can use the licenses, but they do not provide the cloud version there. This is a significant challenge for us as we must maintain the on-premises servers that we installed with InfluxDB. Performance is generally good, and with the help of the InfluxDB support team, we handle both Azure China and AWS day-to-day problems such as buffering data. For example, some devices being offline leads to missed data, which we address directly with the manager and technical support. They also helped us by establishing monitoring on Azure China since it is our on-premises server, managing and monitoring our database performance.

InfluxDB's stability is generally good, being stable 99 percent of the time.

Regarding scalability, since we use the cloud version, we do not need to scale at all.

The customer support is good, and they typically respond within 8 to 10 hours.

My experience with the cloud version is that for reporting purposes, we need to retrieve a lot of data to create reports on our platform. These reports can include substantial amounts of data, such as one year or one month of energy, sensor, and other device data. Obtaining that quantity of data directly from InfluxDB is quite challenging, and that is why we ask for help from the InfluxDB team to retrieve the data to avoid timeouts and those kinds of issues.

Before InfluxDB, we used MongoDB for storing time series data. We switched to InfluxDB due to its superior performance, as it was difficult to maintain data in MongoDB for our time series needs. We were also encouraged to make the switch due to better pricing, especially when we had a good budget.

I have seen a return on investment, as it is good for the company. It simplifies processes and reduces the need for additional employees. We invest in InfluxDB instead of spending time on workforce management.

I find the cloud version pricing of InfluxDB reasonable, and for the on-premises solution we use in our service, we need to purchase licenses. The price seems fair enough as per our organizational needs since we have a substantial amount of data that we are storing.

Before deciding on InfluxDB, we evaluated other options, including PostgreSQL time series data, which is quite good and widely used. We opted for InfluxDB because we found it more valuable, requiring less effort with no maintenance on on-premises servers. We simply wanted the cloud version.

On a scale of 1 to 10, I would rate InfluxDB a 7.

I give it a 7 because the support and cloud version are available. I reduced the rating by 3 points due to some shortcomings. One shortcoming is that when we request too much data, it hangs considerably and does not provide results in one instance or experiences delays. However, 7 is an appropriate rating in terms of performance, pricing, support, and the cloud version.

InfluxDB is deployed as we use the InfluxDB cloud version, and in our application, we incorporate that cloud version. Our application is public, but it is specifically designated for customers.

We use two cloud providers for the InfluxDB cloud version, with 90 percent usage on AWS and the secondary being Azure China.

We do not purchase InfluxDB through the AWS Marketplace. Instead, we purchase it directly from InfluxDB and use it in our applications.

Additionally, I have further thoughts about InfluxDB. Sometimes, when we write too much data within a minute, the data count becomes excessive, reaching perhaps 100,000 or 500,000 data points, and InfluxDB gives a timeout exception, which we must handle in our application. Additionally, if the code is not adequate, we need to change it. These challenges also arise during production support. My overall rating for InfluxDB is 7 out of 10.

We are using InfluxDB with Prometheus and Grafana for monitoring the logs that are coming up as well as to create a powerful monitoring and analytics solution, encompassing data collection, metrics, and data storage.

Whenever the number of connections increases or we have our Elasticsearch where we have the logs, InfluxDB gathers them and sends them. We created an analytics on it using the SRE people that are there.

Based on InfluxDB, we have great analytics produced by our SRE team, and with that, we have an alerting and monitoring system in place. Whenever there are a lot of things that are happening, such as the interaction going up and the number of logins increasing, then we get an alert that this is happening and we see that it's genuine or someone is trying to attempt something. This has helped us significantly.

We have our own metrics, as I mentioned from the SRE team, along with those logs. From there, we maintain the number of logins, the number of unique logins, and the number of logins at which period of time. These metrics are there so that we can even think about having an auto-scaler in place so that everything is auto-scaled.

InfluxDB's feature of data series over an extended period of time is valuable. We can watch logs even from the past three years and into a small range. For instance, in the past three years, from this moment till this moment, we can see how many logs are there and everything. We can watch it that way.

Firstly, the query language, as I mentioned, is based on SQL, so we can use SQL. Additionally, there is an open-source solution for it, which we can install on our system and work with those things directly. It is providing our own infrastructure-based solution, and it has a large community around it. That is the primary reason we chose it.

Firstly, it is open-source and has a great community. However, there could be much more improvement on the metric side that I have mentioned.

If it gets a little bit more into the metric side, then it would really be great, similar to Prometheus. However, Grafana handles those things together, so I do not feel that improvement is needed.

Rather than having two data sources, we could have just one data source with InfluxDB, and it could handle those things rather than having Prometheus and InfluxDB in place.

I have been using InfluxDB for the past four years.

InfluxDB is pretty much stable.

In terms of scalability, it is highly scalable, as I mentioned that it has HA and backup plans available for it. It has handled a lot of data.

There is nothing as such that I can complain about. It is pretty much usable and very much intact.

Before InfluxDB, we were using Loki. However, we switched to InfluxDB because it has high availability, scalability is there, and error loggings sometimes perform better on that. For that reason, we moved from Loki and Prometheus to InfluxDB.

The first thing is that it will have a learning curve. You should have a POC or something that takes time because setting it up is somewhat difficult because it is a new thing for us. However, once it is set up, then you do not need to take care of it every time. It is auto-scalable, auto-healable, and all those things. That is the feature that you will always appreciate about InfluxDB. You must have a willingness to learn new things.

InfluxDB is set up in a database setting where we have authentication and it is pretty much easy to use with a query language similar to SQL. That is why it works for us.

Time saved is there, as I mentioned, because we have an analytics system from where we get alerting and monitoring. It is pretty much time-saving and things go right. However, not on the fewer employee side. We need employees because it has a learning curve, but it is definitely time-saving.

We are using an open-source solution, so there is no cost on that. However, on the server side, we needed a few things, such as CPU. We needed a good CPU and everything. This cost a bit for us.

We checked Apache Druid and TimescaleDB.