Storage solutions for sensor data

In a world where individuals and their grandparents are showcasing graphs depicting their daily step count, the current electricity output from their solar panels, and the trajectory of their child moving from point A to point B at velocity X, the pervasiveness of data is undeniable. Moreover, the seamless transition of data from user production to near real-time user consumption has become increasingly common. This is made possible by the widespread integration of interconnected devices, commonly referred to as the Internet of Things (IoT), along with reduced costs for data storage and processing, and enhanced means of accessing data from virtually anywhere. Diverse devices, ranging from manufacturing machinery to smart thermostats, are equipped with connected sensors that generate substantial data volumes (refer to this insightful report on the State of IoT). The insights derived from these devices have the potential to transform business operations, foster innovation, and elevate customer experiences.

Nevertheless, as data volumes escalate and the number of data-intensive companies grows, a crucial question emerges: how can one efficiently store, manage, and process the copious amounts of sensor-generated data? There is no one-size-fits-all solution; each problem has given rise to multiple solutions, spanning from traditional relational databases to cutting-edge technologies such as time-series databases, NoSQL, and data lakes. Furthermore, the method of data storage can significantly impact the speed at which insights are obtained, the costliness of data querying and storage, and the ease of data exploration.

This blog post delves into the realm of sensor data storage solutions, examining the strengths, weaknesses, and practical implications of each approach to provide valuable insights for businesses in the artificial intelligence sector.

Challenges in Sensor Data Storage

Effectively managing sensor data presents several challenges for businesses, particularly in the realm of artificial intelligence:

Data Volume and Velocity: Coping with the sheer volume and velocity of data streaming from sensors can strain conventional storage systems. Real-time processing, analysis, and serving are essential for decision-making, whether automated or manual. Recent initiatives aim to enhance established database solutions by introducing innovative approaches to data storage and organization, tailored to the demands of sensor-generated data. The shift in data usage patterns, where analysts and scientists often require full or partial snapshots for analysis, can overwhelm traditional row-based storage systems.

Data Variety and Complexity: Sensor data typically arrives in structured or semi-structured formats, but varying levels of nesting pose challenges for storage and analysis using conventional databases. Additionally, querying with certain NoSQL or Data lake solutions may encounter issues due to the data volume.

Scalability and Performance: With business growth, the volume of sensor data escalates, necessitating storage solutions that can handle increased data volumes without compromising performance. Horizontal or vertical scaling and strategic data organization, such as partitioning or data structures, become crucial considerations.

Data Integrity and Timeliness: Ensuring data integrity and timeliness is paramount in specific industries. However, coupled with high volume and velocity, maintaining these aspects can be challenging for data systems. It’s important to note that not all industries demand the same level of consistency, as it often comes at a higher cost.

Choosing a storage solution involves trade-offs in addressing the mentioned challenges effectively. Often, compromises are necessary, such as adjusting data frequency to capture essential information comprehensively.

Types of Sensor Data Storage Solutions

Modern data landscape has become really diverse, enabling the businesses to pick and choose solutions that best fit their needs. Each storage type offers distinct capabilities, tailored to accommodate specific data formats, scalability needs, budget options, and real-time processing requirements.

1. Relational Databases

Traditionally, relational databases such as MySQL, PostgreSQL, and SQL Server have been the bedrock of data storage. They organize data into structured tables with predefined schemas, excelling at handling structured data. However, when faced with unstructured or semi-structured sensor data, their rigidity becomes apparent. Despite their ACID compliance, ensuring data consistency and integrity, these databases may struggle to meet the scalability demands posed by large volumes of sensor data.

When large volumes are involved in modern relational database like PostgreSQL, the answer is usually partitioning. See the post Postgres Partitioning: When to Consider It (https://www.timescale.com/learn/when-to-consider-postgres-partitioning) for a write-up on the topic. Using partitions, data can be divided into smaller and more managable sub-tables known as partitions. When writing or querying data, each partition behaves as a separate table, which can drastically improve writes and reads. However, there are drawbacks of increased data management (there is pg_partman – to help you with that) and even the possibility to worsen the performance, if the partitions are not designed with the access pattern in mind. E.g., we are managing a data source where data is constantly queried by:

  1. ID – and all the data for that ID is returned.
  2. Time – all data for all IDs for a given time range is returned.
  3. Combination of ID and time – all data for the given ID and time range is returned.

No matter what partitioning we employ, there exists a query pattern that does not perform well.

Recent years have witnessed the emergence of solutions like Timescale that extend the scalability of time-series data within relational databases. These extensions facilitate the easy management of time-based partitions. However, it’s important to note that, despite these advancements, challenges persist, and certain access patterns may lead to poorly performing queries.

Mitigating some of these issues can be achieved through the use of more performant IO and powerful compute instances. Improved IO enhances reads and writes, especially during batch operations involving substantial data read or overwrites. Memory-optimized compute instances, by keeping data in RAM, significantly reduce read times. Nevertheless, this performance boost often comes with a higher price tag, particularly for burst-like access patterns, where specific IDs’ data is read sporadically.

Pros:

– ACID compliant

– Battle-proof

– Performant when using partitioning and access patterns can be addressed by partitioning

– Developers are usually familiar with technology

– SQL

Cons:

– Not batch-operations friendly

– May get expensive

– May perform badly in case of conflicting access patterns

 

2. NoSQL Databases

NoSQL databases comprise different models, including document-based (MongoDB ), key-value stores (Redis ), column-oriented (Cassandra), and graph databases (Neo4j). These databases provide flexibility in managing various data formats, scalability for handling substantial data volumes, and the capability to accommodate semi-structured and unstructured sensor data. However, it’s essential to be mindful of potential consistency trade-offs associated with specific NoSQL models. Additionally, thoughtful design of data layout is crucial to enable efficient and cost-effective querying.

Pros:

– Scalability, especially horizontal scalability can increase data volume ingestion and querying.

– May support different data models.

– Sometimes, the storage may be more cost-effective than relational database

Cons:

– Querying may get complex and expensive.

– Lack of strong consistency in some cases.

– Maturity, in comparison to relational databases, some NoSQL database may lack a mature ecosystem with established tooling and community support.

– No standard query language.

3. Time-Series Databases

Specialized for timestamped data, time-series databases like InfluxDB and Prometheus stand out in the storage and analysis of time-stamped sensor data. They enhance storage and retrieval processes for time-series information, offering effective query capabilities for historical analysis and trend identification. These databases frequently incorporate built-in support for time-series functions. Another noteworthy entry in the realm of time-series databases is TimescaleDB , which, despite using relational data models, also aligns with the unique requirements of timestamped data.

Pros:

– Optimized for time-series data, which is exactly the case with IoT data.

– High performance with efficient ingestion and retrieval.

– May allow horizontal scaling for increased scalability.

– Specialized querying and aggregation with focus on time-based operations.

– Retention policies built in – some solutions may allow for retention policies specification, allowing automatic cleaning of “old” data.

Cons:

– May be too specialized – additional technologies may be required which increases the cost and maintenance overhead.

– Querying capabilities may be limited, compared to the general-purpose databases.

– Some databases may have unique query languages.

4. Data Lakes and Lakehouses

In the realm of data lakes, the separation of storage, exemplified by Amazon S3 and Azure Data Lake Storage, and compute, embodied by Hadoop, Spark, and Trino, facilitates expansive storage capacity for structured, semi-structured, and unstructured data, including sensor data. This architectural division allows for cost-effective, massively parallel data serving. The compute aspect simply needs to implement interfaces to the storage, enabling seamless querying and data writing within the data lake.

In recent years, three prominent data lakehouse data formats—Delta Lake, Hudi, and Iceberg—have emerged for effective cloud-based data management. A comprehensive comparison of these options is available in a blog post by Onehouse. These data lake formats elevate storage from a mere collection of files to a well-organized object structure, enhancing query speed and update efficiency.

A critical design consideration when working with data lakes is the selection of the file format (refer to https://towardsdatascience.com/big-data-file-formats-explained-275876dc1fc9 for a detailed comparison of different file formats). While binary formats like Avro and Parquet offer superior performance in terms of read times, partial reads, and file size, text files such as CSV and JSON provide interoperability and human readability, aiding in debugging. Leveraging partitioning in cleverly designed setups, binary formats like Parquet, with features like partial reads and columnar storage, offer distinct advantages for handling sensor data, delivering excellent read performance for specific devices and measurement metrics even in massive datasets.

Pros:

– Scalability and flexiblility. Since this is effectively just object storage one can ingest large volumes of structured, semistructured or unstructed data. Horizontal scaling helps with scalability.

– Cost efficiency even for long term storage.

– Multiple analytical workloads – one can bring their own compute.

– Schema-on-Read – this allows for delaying the schema definitions.

– Big data technologies integration.

Cons:

– Complexity in data management. Large volumes of diverse data may quickly get out of hand. Without proper governance and metadata management this can lead to data silos, inconsistent data quality, data duplication, difficulty in data discovery, potential issues in data governance and security challenges.

– Querying latency – due to schema-on-read and raw data storage, one can encounter latency in data querying.

– Skill set requirements – usually one needs to set-up data pipelines to process and transform the data and sometimes load it into system that enable quick and efficient querying while taking into account all of the issues mentioned above. This requires staff with wide skill set.

5. Edge Computing and Edge Storage

Edge computing is on the rise, and there’s a growing interest in storing sensor data closer to where it originates. Solutions like RedisEdge allow sensor data to be stored locally on the edge devices themselves. This approach reduces delays in getting and accessing data, making real-time analysis and decision-making possible in distributed setups. It’s worth mentioning that having enough computing power and storage at the edge also lets you use self-hosted SQL, NoSQL, and Time Series options, improving data ingestion capabilities compared to relying on cloud-based solutions. But keep in mind that handling data this way can be costly and resource-intensive.

Pros:

– Reduced latency, bandwidth optimization, and improved reliability, since storage is close to the data producers.

– Enhanced data privacy and security, since data movement across networs and systems is limited.

– Support for offline operations, data collection proceeds even in cases of network outages.

Cons:

– Limited storage capacity – edge devices tipically have limited storage available, compared to centralized servers or cloud.

– Management complexity with potential higher costs – ensuring consistency and query availability on such distributed system that is often geographically dispersed might contribute to high operational costs.

– Data loss risk – only localized storage might pose a data loss risk in case of device failure or physical damage. Efficient backup mechanism has to be put in-place which increases management complexity.

Each of these storage solutions presents its unique strengths and trade-offs, catering to different business needs and use cases. The choice of a storage solution significantly impacts data accessibility, processing speed, scalability, and cost-effectiveness.

Considerations for Choosing the Right Solution

Choosing the ideal sensor data storage solution requires a thorough evaluation of various factors, including business requirements, costs, technical specifications, and future scalability. If you are an AWS Cloud user, their post titled “7 patterns for IoT data ingestion and visualization – How to decide what works best for your use case” can serve as a valuable resource for insights on how to efficiently ingest and visualize IoT data on AWS.

Here are a few considerations to keep in mind when selecting the most suitable solution:

1. Scalability and Performance Requirements

Assess the scalability needs concerning both data volume and the rate of data ingestion. Consider anticipated growth and ensure the chosen solution can seamlessly accommodate expanding data without compromising performance. This evaluation is vital, especially in industries where real-time processing and quick access to data are imperative.

Consider NoSQL, dedicated Time Series or Data Lakes technologies, where scalability and performance are important.

2. Data Consistency and Reliability

Different storage solutions offer varying degrees of data consistency guarantees. For mission-critical applications where accuracy is paramount, ensuring strong consistency might be crucial. Evaluate the solution’s mechanisms for maintaining data integrity and handling potential failures or inconsistencies.

Consider ACID-compliant solutions for such cases, natively supported by relational databases and sometimes also supported by other technologies, albeit with the drawbacks like limiting the scalability in transactional mode. Note, though, that there are cases where storing all of the data is not of utmost importance and real-time data is not really needed. Data lakes and NoSQL may be an option there.

3. Cost-effectiveness and Scalability

Balance the features and performance of the storage solution with its associated costs. Some solutions might be more cost-effective initially but could incur higher expenses as data volumes grow. Understand the pricing models, including storage costs, data transfer fees, and any additional services required for analysis or retrieval. Know that usually real-time processing comes with a higher price tag and more complicated flows, compared to the batch processing. Consider your business goals when batch is OK.

Consider data lakes for cost-effective storage and scalability.

4. Integration Capabilities

Consider how the chosen storage solution integrates with existing infrastructure, applications, and analytics tools. Compatibility and ease of integration play a significant role in streamlining data workflows and ensuring seamless operations. Think on who will use the data (data scientists, data engineers, dashboards, decision makers). While there is always an option to import and export data, extensive use of transformations may require additional tooling, such as data catalogs, data lineage etc. Consider how the user can access the data in efficient and cost-effective way (will these be files on S3, SQL table, or something else) with the data resembling the production as close as possible but not hindering the production operations when querying. If you are a cloud user, consider the integrations supported by the cloud services, e.g., consider Kinesis Data Firehose to compact smaller files before writing the down to S3 to reduce the number of relatively costly PUT events.

Each technology uses it’s own means to connect to the data, but SQL query language and database connections may be the easiest to start with.

5. Compliance and Security Measures

Evaluate the solution’s compliance with industry standards and regulations governing data privacy and security. Robust security measures, encryption capabilities, access controls, and compliance certifications are essential, particularly in industries like healthcare, finance, and IoT-enabled devices handling sensitive information.

Consider SQL and certain Time Series or NoSQL solutions for such cases. Be careful with Data Lakes as data management can be complicated there. Using engines such as Data Lake, Hudi, and Iceberg may help, although it is not that straightforward at the time of writing.

6. Support and Maintenance

Consider the level of support available for the chosen storage solution. Assess factors such as documentation quality, community support, vendor-provided assistance, and maintenance requirements. Reliable support can be critical in resolving issues and ensuring smooth operations. Consider that “boring” technology that has been around for decades is usually the one that is most stable and battle proof. Managed solutions are likely a good option when one does not have a dedicated database personnel. Consider how migrations will be done and streamline migrations process early on. Having the critical steps of database set-up automated or at least carefully documented will save you a lot of headaches.

Consider managed solutions with reliable and tested migrations options. This may, however, be a double-edged sword. Managed solutions usually provide less configuration options as a self-hosted instance.

7. Future Expansion and Adaptability

Anticipate future needs and technological advancements. Choose a solution that not only meets current requirements but also offers flexibility and adaptability to accommodate evolving data formats, analytics needs, and emerging technologies. Be prepared for trade-offs, e.g., do you really need additional storage solution if you are currently using PostgreSQL and your developers are familiar with it and it’s quirks. These days, majority of database projects are open-sourced. However, the licenses, which dictate how you can use the software, differ greatly. Choosing a solution that is backed by one company with few or even no outside contributors may be OK for experimental work, however, think carefully before deploying it to production.

Consider established projects with known road maps and healthy project governance.

Conclusion

We are currently in an era dominated by data. Navigating the dynamic landscape of contemporary businesses, driven by IoT and sensor-generated data, can pose challenges when selecting the most suitable solution. In this blog post, we delve into various options and highlight associated trade-offs.

Efficient storage of sensor data goes beyond mere information housing; it involves converting raw data into actionable insights that fuel innovation, enhance operational efficiency, and inform strategic decision-making. The significance of this decision cannot be emphasized enough, especially given the exponential growth of data and its potential impact on businesses across diverse industries.

Through our exploration, we’ve identified:

– Challenges specific to sensor data storage and querying.

– Different categories of data storage solutions, along with their respective advantages and disadvantages.

– Key considerations to factor in before committing to a data storage solution.

Every business comes with unique requirements, and the optimal choice depends on aligning these needs with the strengths and trade-offs of available solutions. Frequently, a blend of technologies is necessary to provide the best data experience.

Let this comprehensive exploration serve as a valuable guide for businesses navigating the complex realm of sensor data storage solutions. Our aim is to empower them to make informed, strategic choices that leverage the vast potential of data to drive business success and foster innovation.