OK. Particularly with the storage problem that I solved, I have told in my introduction that I've been working since from six months, five months to six months, with the Elasticsearch, setting up Elasticsearch with Kubernetes. So the thing was, we need a local SSD for the faster retrieval of data. Or any EBS volume block or the network storage block would not be here for the faster retrieval of data. So the major challenge was to create a storage class for this, because it was not given in the Kubernetes to get a local storage with whatever the present storage classes. GP3, GP2, all those are for the EBS blocks, and that cannot be used. So basically, what we have to do is we have to go for a third-party solution that will be an open EBS. What it gives, it provisions the local storage. For this, we need that storage to be mounted. So when it comes to a local SSD on a virtual machine, we need to mount it. But you cannot mount SSD for hundreds of machines by just logging to it and checking if the volume is mounted, because that's an auto-scaling cluster, right? It might be possible that some days that 80 machines are required. It might be possible that 100 machines are required. But that will definitely be out of scale. For that, you need to write a script. So I have wrote a script to overcome that challenge, that it will identify on the run. Whenever you spin up the machine, it will identify the storage over there, if SSD storage over there. And it will mount the SSD on that particular node, OK? So that's how we have tackled a storage problem with our Elasticsearch cluster. And that has been tackled easily. OK, coming to the different point of view over here, if the cluster is set up and the transformation is getting surpassed or anything, with the data set, basically the NoSQL, or you can say the Elasticsearch, or any NoSQL or unstructured databases, what happens, right? Basically, in unstructured, anyone can easily put unrequired data over there. Let's say the field name, home address is not over there, OK? And I don't want that in my database, OK? But if anyone tries to put that data, it will for sure store that, because it's unstructured data. For that, what we have done is we have created a template, OK? What is a template? What kind of data should we put into that index? Or it will be defined into that template. And we have mapped it as a strict. Mapping should be strict, OK? Then only, whenever the data being pushed to that index, we will for sure, every time, check that if the data is in correct format or not, OK? That's how we maintain the data integrity in our database and the storage is healthy. So yeah.
