Amazon OpenSearch Service is not providing the processing feature directly. From Amazon OpenSearch Service, we are actually maintaining the AWS SQS, the queue service, which is responsible for providing information about what data has to be modified. So using that SQS, we're actually providing it, but we're not directly using Amazon OpenSearch Service for keeping data to other data pipeline thing. So far we didn't use it for any machine learning purposes, but in future, we have plans to extend or implement this feature. Since AWS itself is secure and Amazon OpenSearch Service is a part of this entire ecosystem, it becomes much easier for security purposes. From the validation point of view, Amazon OpenSearch Service itself provides easy to communicate APIs and up-to-date documents, which is much beneficial. For example, if I'm missing anything, I can directly go and check the documentation. That is actually much easier. I would rate it as really good so far. It's much faster. For our local machine, we can also use a kind of replica of Amazon OpenSearch Service just for development purposes. That is another good feature. I would say for the encryption thing and also the user access control management, it's much faster. For some of these hashing algorithms, it also worked really well so far. To be honest, I didn't find any places where it can be improved. However, I think they could provide more abstraction. For example, still for searching, we have to write down the queries in a specific manner, such as for a specific JSON structure or in a specific way. Otherwise, they don't provide us the actual results. For at least this purpose, I think abstraction could be a bit easier or a bit improved. Other than that, right now there is the age of AI, so some kind of prompting could also work, but I'm not sure how it could be integrated. As a user, lower prices or reasonable pricing is always better. Those can be improved as well. However, it is good that most of the services including Amazon OpenSearch Service actually provide pay as you go pricing. So if there were a bit lower version or a bit less payment methodology, it might be much better.
In terms of data handling capabilities with Amazon OpenSearch Service, they can be complex and managing data in comparison to other SIM solutions is a major drawback, as it is very hard to handle the data. We definitely want Amazon to optimize the data handling aspect, as ElasticSearch is the parent of OpenSearch. If Amazon makes changes in OpenSearch, it would be very useful for us, making it more user-friendly with simple buttons to perform tasks.
I did not delve deeply into Amazon OpenSearch Service, so I am unable to suggest specific improvements. However, we faced documentation challenges during integration after migrating from Elasticsearch to Amazon OpenSearch Service. Better documentation on integration, query handling, and a more user-friendly UI could enhance the product. I am aware that a separate team handles the deployment and setup, so my knowledge is limited.
One improvement I would like to see is support for auto-scaling. The current configuration does not support automatic scaling based on server load, requiring us to manage the scaling manually. Additionally, during snapshot processes and upgrades to servers, indexing and data copying take too much time.
The pricing aspect is a concern. The service is way too costly. For the past month, I used only 30 to 40 MB of data, and the cost was $500. AWS could improve pricing. Even being serverless, it incurs charges during idle times. For just holding data, you need to create a list. AWS should add an option to make data idle, so it won't include computing charges. They charge for OCU units based on the time the serverless solution is up, not on indexing or retrieval speed. Once the service starts, it starts getting billed. It would help if there were an option to limit computing. When using it as a database, storing data without frequent fetching would save computing costs.
Some configurations or settings are not accessible to end users, as OpenSearch Service is a managed service. It would be beneficial to have some level of customization available in the managed service, tailored to the specific use cases of the end users. Currently, there are strict controls. For instance, if you wish to adjust cluster settings or other parameters, it's challenging for AWS to modify them. The real-time analytics provided by Amazon OpenSearch Service can significantly improve your decision-making processes. Initially, we struggled to determine the correct cluster size and monitor various metrics. You can easily observe metrics like JVM and CPU usage on the monitoring dashboard. This information helps choose the appropriate tool and understand its support and extension capabilities. It would be even better if the service included built-in alerting based on these metrics. If an issue arises, you must manually check the cluster's status. Implementing preconfigured alerts for critical metrics like JVM and CPU usage would significantly enhance the service's usability.
Amazon OpenSearch Service provides scalable and reliable search capabilities with efficient data processing, supporting easy domain configuration and integration with numerous systems for enhanced performance.Amazon OpenSearch Service offers advanced features for handling JSON, diverse search grammars, quick historical data retrieval, and ultra-warm storage. It also includes customizable dashboards and seamless tool integration for large enterprises. With its managed infrastructure,...
Amazon OpenSearch Service is not providing the processing feature directly. From Amazon OpenSearch Service, we are actually maintaining the AWS SQS, the queue service, which is responsible for providing information about what data has to be modified. So using that SQS, we're actually providing it, but we're not directly using Amazon OpenSearch Service for keeping data to other data pipeline thing. So far we didn't use it for any machine learning purposes, but in future, we have plans to extend or implement this feature. Since AWS itself is secure and Amazon OpenSearch Service is a part of this entire ecosystem, it becomes much easier for security purposes. From the validation point of view, Amazon OpenSearch Service itself provides easy to communicate APIs and up-to-date documents, which is much beneficial. For example, if I'm missing anything, I can directly go and check the documentation. That is actually much easier. I would rate it as really good so far. It's much faster. For our local machine, we can also use a kind of replica of Amazon OpenSearch Service just for development purposes. That is another good feature. I would say for the encryption thing and also the user access control management, it's much faster. For some of these hashing algorithms, it also worked really well so far. To be honest, I didn't find any places where it can be improved. However, I think they could provide more abstraction. For example, still for searching, we have to write down the queries in a specific manner, such as for a specific JSON structure or in a specific way. Otherwise, they don't provide us the actual results. For at least this purpose, I think abstraction could be a bit easier or a bit improved. Other than that, right now there is the age of AI, so some kind of prompting could also work, but I'm not sure how it could be integrated. As a user, lower prices or reasonable pricing is always better. Those can be improved as well. However, it is good that most of the services including Amazon OpenSearch Service actually provide pay as you go pricing. So if there were a bit lower version or a bit less payment methodology, it might be much better.
In terms of data handling capabilities with Amazon OpenSearch Service, they can be complex and managing data in comparison to other SIM solutions is a major drawback, as it is very hard to handle the data. We definitely want Amazon to optimize the data handling aspect, as ElasticSearch is the parent of OpenSearch. If Amazon makes changes in OpenSearch, it would be very useful for us, making it more user-friendly with simple buttons to perform tasks.
I did not delve deeply into Amazon OpenSearch Service, so I am unable to suggest specific improvements. However, we faced documentation challenges during integration after migrating from Elasticsearch to Amazon OpenSearch Service. Better documentation on integration, query handling, and a more user-friendly UI could enhance the product. I am aware that a separate team handles the deployment and setup, so my knowledge is limited.
One improvement I would like to see is support for auto-scaling. The current configuration does not support automatic scaling based on server load, requiring us to manage the scaling manually. Additionally, during snapshot processes and upgrades to servers, indexing and data copying take too much time.
The pricing aspect is a concern. The service is way too costly. For the past month, I used only 30 to 40 MB of data, and the cost was $500. AWS could improve pricing. Even being serverless, it incurs charges during idle times. For just holding data, you need to create a list. AWS should add an option to make data idle, so it won't include computing charges. They charge for OCU units based on the time the serverless solution is up, not on indexing or retrieval speed. Once the service starts, it starts getting billed. It would help if there were an option to limit computing. When using it as a database, storing data without frequent fetching would save computing costs.
Some configurations or settings are not accessible to end users, as OpenSearch Service is a managed service. It would be beneficial to have some level of customization available in the managed service, tailored to the specific use cases of the end users. Currently, there are strict controls. For instance, if you wish to adjust cluster settings or other parameters, it's challenging for AWS to modify them. The real-time analytics provided by Amazon OpenSearch Service can significantly improve your decision-making processes. Initially, we struggled to determine the correct cluster size and monitor various metrics. You can easily observe metrics like JVM and CPU usage on the monitoring dashboard. This information helps choose the appropriate tool and understand its support and extension capabilities. It would be even better if the service included built-in alerting based on these metrics. If an issue arises, you must manually check the cluster's status. Implementing preconfigured alerts for critical metrics like JVM and CPU usage would significantly enhance the service's usability.