Overview
In addition to time-series data (sensor values), IoT platforms also need to store unstructured data reported by devices such as images, videos, firmware packages, and log files. These data have characteristics such as large volume, rapid growth, and different access patterns (frequently accessed hot data, archived cold data), which traditional file systems or relational databases struggle to handle. Distributed storage systems like MinIO, Ceph, and HDFS provide highly available, scalable object storage capabilities to meet PB-level file storage requirements. Object storage uses S3-compatible APIs, supporting large file multipart upload, resumable uploads, and version management, naturally fitting scenarios such as device file uploads, OTA firmware distribution, and log archiving on IoT platforms.
In IoT scenarios, data volumes from camera snapshots, industrial vision quality inspection images, vehicle videos, and device diagnostic logs are enormous. Distributed storage needs to support partitioning by tenant, product, and time for isolation and lifecycle management. Combining with CDN can accelerate firmware downloads and image access, reducing the load on the origin server.
Core Features
Object Storage S3 Compatibility
S3-compatible API, supporting Put/Get/Delete operations. Large file multipart upload, resumable uploads. Supports metadata, tags, and lifecycle rules. Compatible with APIs like AWS S3, Alibaba Cloud OSS, Tencent Cloud COS, facilitating migration and multi-cloud deployment.
High Availability and Elastic Scalability
Multiple replicas or erasure coding (EC) ensure data is not lost. Automatic recovery in case of node failure. Supports dynamic scaling, simply add nodes to increase capacity and throughput. PB-level capacity, high concurrent access.
CDN and tiered storage
Combine with CDN to accelerate firmware downloads and image access, reducing origin server pressure. Supports tiered storage with SSD for hot data and HDD for cold data, lowering costs. Lifecycle policy: automatically migrate expired data to low-cost storage or delete it.
Typical IoT Applications
Camera snapshots, industrial inspection images, in-vehicle video storage. Firmware package storage and OTA distribution. Device logs and diagnostic file archiving. Data backup and disaster recovery. Integrated with IoT platforms, devices upload files via HTTP/MQTT, after which the platform stores them for querying, downloading, and analysis.
Object key space and persistence policy
Object storage holds files, images, and log bundles
Distributed storage here means objects and files: written once, read many times by key, and rarely changed one byte in the middle. Pictures, short video, firmware images, diagnostic bundles, and export files all fit that shape. An object is a bucket, a key, and bytes, and the storage system does not interpret the business meaning of those bytes. Measurements that must be scanned over a time range and aggregated by window belong in a time-series engine. Saving each sample as its own small object makes the metadata far larger than the data, and listing becomes too slow to use.
The key is the index. Put tenant, product, device identifier, date, and purpose into the key so listing and expiry can run by prefix. If the key uses a display name that can change, renaming a device disconnects every old object. What stays stable is the device identifier and the content digest. The display name goes in object metadata. After versioning is turned on, an overwrite does not drop the old bytes at once, and a delete is often only a delete marker. Space is released when lifecycle rules clear the noncurrent versions.
When erasure coding and multipart upload apply
Several replicas suit a cluster where objects are small, the node count is modest, and the read path should stay simple. Erasure coding splits an object into data blocks and parity blocks. The extra space is smaller, but the number of available nodes must reach the minimum needed to recover, and very small files have the saving cancelled by the overhead of managing blocks. Larger objects such as firmware and video suit erasure coding better. A huge number of status values only a few dozen bytes long should be merged before they are written, or placed in another store.
Multipart upload suits a large image on an unstable network. Each part is acknowledged on its own, a failure retransmits only that part, and the server assembles one object after every part is complete. The client must remember the upload identifier and the part numbers that succeeded, and someone must clean uploads that never finished. When an upgrade task fetches an image from here, the address should be signed for a limited time, and the scope should include only the keys that task needs. How task state lines up with the image key is covered in the OTA Upgrade System.
Lifecycle rules, bucket policy, and unfinished parts
A lifecycle rule with the wrong prefix sends firmware that is still on the release path into expiry deletion, and a field upgrade then asks for a key that is not there. Rehearse the rule on a replica bucket first, and confirm that it matches logs and expired snapshots, not the image currently being distributed. If a bucket policy grants list rights for a whole tenant, one account can scan other customers' key names. Limit the policy to that customer's prefix, and authorize write, read, and delete separately.
Unfinished parts do not appear in an ordinary listing, but they keep occupying capacity, so the bucket looks small while the disk is full. List unfinished uploads on a schedule, and abort sessions past the agreed deadline. When the same key is overwritten, a read that lands on a node whose cache has not expired can briefly return the previous version. A critical image should use a new key, and the task should point at that new key explicitly. Exporting time-series detail into objects as an archive is reasonable. The export must be replayable over a time range, and it must line up with the retention period of the Time Series Database, so a span is not already expired in the database and missing from the objects at the same time.
Look at how objects are read before merging the small ones. If a snapshot needs a download address signed for a single image, merging them into one large bundle makes the signature cover too much. Keep one key per image, and use the prefix and the date to bound the listing. Diagnostic logs are the other way around: one bundle per device per day is easier to put under a lifecycle rule than tens of thousands of fragments. Once the shape is chosen, do not change the key rule halfway. Otherwise the same day's files land in two prefixes, the expiry job clears only one of them, and the other keeps occupying disk.