Elastic Search

Three core strengths are particularly compelling: * the technical depth of Elasticsearch: this empowers our team experts to build highly precise search engine recipes that incorporate the specific nuances of our business domain, with functions like aggregations, percolators, indexing tricks at token level, customize analyzers, override bm25 parameters... It gives us the flexibility needed to truly customize our search experience that satisfies both our customers and our merchandisers. * The high stability and performance of the Elastic Cloud Enterprise infrastructure: running our operations on ECE ensures a remarkably stable environment. The performance of the search engine delivers incredibly fast response times, which is crucial for our users and consistently positions us at the top of performance metrics. * Continuous innovation, especially with new features relevant to generative AI: Elastic is at the forefront of integrating intelligent and high performing tools in this rapidly evolving field. This includes capabilities like feature extraction via Large Language Models, advanced hybrid search with various retrievers, ML inference endpoints and powerful rerankers, all of which keep our solutions ready to build new search experiences.

It can aggregate logs, and it has a lot of flexibility in sorting and visibility.

What we like most about Elasticsearch is its incredible speed and scalability. Its distributed architecture allows us to handle petabytes of data and perform complex queries in milliseconds, which is absolutely critical for the real-time needs of our marketing orchestration product. The powerful aggregation framework is another favorite, as it enables our engineers to build highly analytical features and dashboards with relative ease.

While the product is generally easy to learn and powerful, we have identified a few areas for improvement: * Lack of native SQL support: despite the product's overall ease of learning, the absence of direct, native SQL support is perceived as a significant barrier to adoption of Elasticsearch, especially for Data Analyst and Data Scientist profiles accustomed to SQL-based tools (like BigQuery). While the newly introduced ES|QL offers a potential solution, it still represents a learning curve for these users compared to a traditional SQL approach. * Response time for complex support issues: while the support team is competent, we have observed that response time can be slow when dealing with highly complex or deeply technical problems. This can occasionally impact our ability to resolve critical issues quickly. Nevertheless, every problem has been solved within the next release. * Learning curve for advanced search engine features: mastering the most advanced elements required for a highly optimized engine (on relevancy and response time) necessitates a lot training or extensive experience. This advanced skill requirement can be a bottleneck when recruiting new talent, as finding profiles with this specific expertise can be challenging. On the other end, the certification process helps us identify relevant profiles.

We use the endpoint for AV on servers, and it can be a bit of a pain managing what it is doing. The clients we use for log aggregation alone on user devices are pretty heavy. We are literally seeing battery life cut by 1/3 to 1/2 on mobile devices with the client installed. I can use the product for log searching, but it is very manual (I am a sys admin). I honestly usually just pull logs locally. The security team picked the product, and they are not much better at using it than me. I have seen one ticket generated due to the output of elastic, and it was because the server AV had latched onto the build process we were using to compile our product. It took almost a week before they either got around to fixing it or figured out how to fix it (they are pretty closed-door, so I am never sure what is going on.) Also it is VERY expensive, especially if you use their cloud services. On top of that, the security team is looking at more products to tie into Elastic to make it easier to use. This will of course cost more money.

Version Upgrades: We've found that upgrading to new major versions can be a painful process. It often involves schema changes or breaking API changes that require significant refactoring and testing, consuming valuable development time. Resource Intensity: Elasticsearch is resource-hungry. To achieve the low latency and high throughput our product demands, we have to allocate a large amount of memory and CPU, which drives up our cloud infrastructure costs. Complex Performance Tuning: It can be difficult to diagnose the root cause of performance issues. We've spent considerable time fine-tuning settings and re-indexing data to address specific query performance problems, which highlights the complexity behind its seemingly simple interface.