Data volume and reference frequency

[ishanijerin1]

The amount of data stored in Amazon Timestream and the frequency of access to it are as follows:

Amount of data generated
: Several hundred MB per day per metal 3D printer
Total amount of data stored:
hundreds of GB as of October 2024
Data reference frequency
: Approximately once per hour per user.
*The main use case is expected to be checking organize your finances with mint the status of a metal 3D printer while it is in operation, as well as the expected completion time of metal additive manufacturing.
Query response:
It takes about 2 seconds for Grafana to query Timestream and display one graph.
What I liked about Amazon Timestream
First, regarding the storage of time series data, the use of multi-measure records was useful as it allowed us to intuitively understand the stored data. In addition, it was also useful that the two storage tiers, memory store and magnetic store, which have different performance and costs, are automatically used without any special consideration. On the other hand, regarding the utilization of time series data, we appreciate that the full range of SQL functions, such as date and time conversion functions and window functions, are available, and by using familiar SQL, we can process the acquired data in various ways and display it in Grafana. We also appreciate the fact that SQL can be easily issued from the AWS Management Console. Furthermore, we have not experienced any performance issues at this time, and we have been able to maintain stable response.

Initiatives to complete development
Development of One Board began with about five developers. At the time, my department had developers of embedded software for metal 3D printers, but no knowledge of cloud development. Therefore, in order to complete development within the scheduled time frame, we implemented the following initiatives. As a result, we were able to release it to an external customer in just 10 months:

We consulted with other departments that already had experience developing on AWS and asked for their cooperation.
We adopted the lean startup methodology and repeated the cycle of setting a hypothesis → prototyping the minimum functionality → verifying the hypothesis.
AWS technical support was used appropriately.
In particular, the third point posed a challenge for the company in terms of how to strictly manage access rights to records, given the need to realize multi-tenancy in the system design. As a result, the company decided to adopt a silo model in which a separate database was created for each record owner, and IAM users with limited access rights were prepared for each database. By utilizing AWS support as needed during this process, the company was able to quickly resolve the issue.