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,...
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.