Abdon Pijpelink
45f19f30ee
* Add new Scaling landing page under Operations Introduces a Scaling section with vertical vs. horizontal scaling guidance and failover best practices, linking out to detail pages. * Add new Vertical Scaling page Dedicated how-to guidance for resizing existing nodes: when to scale vertically, RAM sizing formulas, and Cloud/self-hosted resize steps. * Add new Horizontal Scaling and Resilience page Covers Raft consensus, the replication model, consistency guarantees, Multi-AZ, and the resilience terminology used elsewhere in the docs. * Move Distributed Deployment under Scaling and update all incoming links Moves distributed_deployment.md into the new scaling/ section, trims its Raft/Replication/Consistency intros into cross-links to the new Horizontal Scaling and Resilience page, adds Multi-AZ and single-replica cross-link callouts in the Cloud docs, rewrites all internal references across ~30 files to the new canonical path instead of relying on aliases, and applies Title Case to Distributed Deployment's headers. * Split Resilience out of Horizontal Scaling and Resilience Adds a dedicated Resilience page covering fault tolerance, Multi-AZ, resilience terminology, and failover best practices (moved from the Scaling landing page). Horizontal Scaling is retitled and scoped to the underlying mechanics: Raft consensus, replication, and consistency. * Reorganize Horizontal Scaling's structure Moves "How Many Qdrant Nodes Should I Run?" from Distributed Deployment into Horizontal Scaling, adds a conceptual Sharding section, and reorders Sharding/Replication/Raft Consensus/Consistency. Moves the remaining conceptual content out of Distributed Deployment: Temporary Node Failure to Resilience, Error Handling folded into Replication, sharding heuristics folded into Sharding, and the Consensus Checkpointing explanation folded into Raft Consensus. * Rename Scaling section to Scaling & Resilience Renames the section and restructures the landing page: the vertical- vs-horizontal decision is now purely about scaling, with a dedicated Resilience section covering fault tolerance through sharding and multi-node deployments. * Polish Vertical Scaling and Resilience page content Reframes Vertical Scaling's "What Not to Do" as positive "Best Practices". Reworks Resilience's structure: moves the uptime/data- integrity terminology into the intro as three distinct aspects of resilience, and renames "How Resilience Works" to "Setting Up a Resilient Qdrant Cluster". * Add diagrams illustrating sharding and replication Adds cluster diagrams to the Sharding and Replication sections on Horizontal Scaling to make the shard/replica layout easier to follow. * Add new Node Failure Recovery page Extracts the node failure recovery scenarios out of Distributed Deployment into their own page, with each bolded sub-header converted to a proper heading, and links updated across Resilience and the Scaling landing page. * Add new Consistency Guarantees page Extracts write consistency factor, read consistency, and write ordering out of Distributed Deployment into their own page, positioned after Distributed Deployment. * Add new "Deploy Behind a Load Balancer" section Explains why a load balancer is needed in front of a multi-node Qdrant cluster: avoiding a single point of failure at the entry point and making sure replicas on every node actually serve reads. * Add new "Rebalancing" section Documents how Qdrant Cloud automatically rebalances shards across nodes, as its own subsection under Sharding. * Rewrite Multi-AZ vs. Replication Factor as Multi-AZ Deployments Defines an availability zone on first use, explains why multi-AZ deployments guard against a zone going down, clarifies that Qdrant Cloud is zone-aware once enabled, and that self-hosted deployments need to place and move replicas across zones manually. * Restructure node-count guidance into One/Two/Three-or-more Node subsections Splits "How Many Qdrant Nodes Should I Run?" into three subsections and drops the "balanced" framing for two nodes: it states plainly that two nodes give more capacity without true high availability. * Add new "Which Configuration Is Right for You?" section Summarizes the one/two/three-or-more node tradeoffs in one place right after the detailed breakdown. * Add explicit _redirects entry for legacy distributed_deployment URL Closes the redirect chain: the existing /guides/ and /operations/ legacy rules both terminate at /documentation/distributed_deployment/, which previously had no explicit _redirects entry and only resolved via the Hugo alias meta-refresh page. * Fix all incoming links to Distributed Deployment and pages under Scaling Repoints two same-page anchors in distributed_deployment.md that broke when Write Ordering moved to Consistency Guarantees, and one link in cloud/create-cluster.md that broke when a Resilience heading was reworded. * Update time-based sharding diagram and restructure section * Fix a couple of broken links * Move 'Consensus Checkpointing' to 'Node Failure Recovery' page
9.2 KiB
draft, title, short_description, description, preview_image, social_preview_image, date, author, featured, tags, partition
| draft | title | short_description | description | preview_image | social_preview_image | date | author | featured | tags | partition | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| false | Nyris & Qdrant: How Vectors are the Future of Visual Search | Transforming customer service in finance and insurance with vector search-based retrieval. | Revolutionizing customer service in finance and insurance by leveraging vector search for faster responses and improved operational efficiency. | /blog/case-study-nyris/preview.png | /blog/case-study-nyris/preview.png | 2024-09-10T00:02:00Z | Qdrant | false |
|
case-studies |
About Nyris
Founded in 2015 by CTO Markus Lukasson and his sister Anna Lukasson-Herzig, Nyris offers advanced visual search solutions for companies, positioning itself as the "Google Lens" for corporate data. Their technology powers use cases such as visual search on websites of large retailers and machine manufacturing companies that require visual identification of spare parts. The primary goal is to identify items in a product catalog or spare parts as quickly as possible. With a strong foundation in e-commerce and nearly a decade of experience in vector search, Nyris is at the forefront of visual search innovation.
Beyond visual search, Nyris also provides synthetic data solutions, particularly for manufacturing and engineering sectors. Often, customers in these industries lack sufficient photos of parts to leverage visual search effectively. However, they do possess CAD files for their products. Nyris generates synthetic images from these CAD files, enabling visual search without needing actual product photos in the database.
Prominent clients such as IKEA, Trumpf (a precision laser manufacturer), and DMG Mori rely on Nyris to support their field engineers in maintaining parts.
Overcoming Limitations in Visual Product Search
During his time at Amazon, Lukasson observed that search engines like Google often outperformed Amazon's search capabilities for product searches. Recognizing the need for more precise search solutions in industries like e-commerce and spare part management, he identified a significant gap: Traditional keyword-based searches often fail, especially in situations where field engineers struggle to describe parts accurately with keywords. Visual search offers a solution, providing faster and more accurate results by leveraging images, which carry significantly more information than text-based queries.
In their quest for the perfect visual search provider, Nyris ultimately decided to develop their own solution.
The Path to Vector-Based Visual Search
Initially in 2015, the team explored traditional search algorithms based on key value SIFT (Scale Invariant Feature Transform) features to locate specific elements within images. However, they quickly realized that these methods were imprecise and unreliable. To address this, Nyris began experimenting with the first Convolutional Neural Networks (CNNs) to extract embeddings for vector search.
In the early days of vector search, there were few solutions available. Nyris initially developed their own vector search solution but later transitioned to SingleStore. At that time, SingleStore was the only option that could deliver efficient and fast brute-force vector search at scale. As Nyris's data grew, the need for rapid scaling became evident. They found that many standard database features, such as real-time analytics and atomicity, were unnecessary for their specific needs. Instead, what Nyris required was a solution focused on fast and efficient vector search capabilities, along with features that would enhance the search experience for their customers.
With the emergence of pure-play, native vector search engines, Nyris conducted extensive research and benchmarks. Ultimately, they chose Qdrant as their vector search engine of choice. Qdrant stood out for its accuracy, speed, and the ability to handle large datasets efficiently, meeting all of Nyris's requirements for a robust and scalable vector search solution.
The Selection Process
As part of their selection process, Nyris evaluated several critical factors to ensure they chose the best vector search engine solution:
- Accuracy and Speed: These were primary considerations. Nyris needed to understand the performance differences between the HNSW graph-based approach and brute-force search. In particular, they examined edge cases that required numerous filters, sometimes necessitating a switch to brute-force search. Even in these scenarios, Qdrant demonstrated impressive speed and reliability, meeting Nyris's stringent performance requirements.
- Insert Speed: Nyris assessed how quickly data could be inserted into the database, including the performance during simultaneous data ingests and query requests. Qdrant excelled in this area, providing the necessary efficiency for their operations.
- Total Cost of Ownership: Nyris analyzed the infrastructure costs and licensing fees associated with each solution. Qdrant offered a competitive total cost of ownership, making it an economically viable option.
- Data Sovereignty: The ability to deploy Qdrant in their own clusters was a key aspect for Nyris, ensuring they maintained control over their data and complied with relevant data sovereignty requirements.
- Dedicated Vector Search Engine: One of the key advantages of Qdrant, as Lukasson highlights, is its specialization as a dedicated, native vector search engine. "Qdrant, being purpose-built for vector search, can introduce relevant features much faster, like quantization, integer8 support, and float32 rescoring. These advancements make searches more precise and cost-effective without sacrificing accuracy—exactly what Nyris needs," said Lukasson. "When optimizing for search accuracy and speed, compromises aren't an option. Just as you wouldn't use a truck to race in Formula 1, we needed a solution designed specifically for vector search, not just a general database with vector search tacked on. With every Qdrant release, we gain new, tailored features that directly enhance our use case.”
Key Benefits of Qdrant in Production
Nyris has found several aspects of Qdrant particularly beneficial in their production environment:
- Enhanced Security with JWT: JSON Web Tokens provide enhanced security and performance, critical for safeguarding their data.
- Seamless Scalability: Qdrant's ability to scale effortlessly across nodes ensures consistent high performance, even as Nyris's data volume grows.
- Flexible Search Options: The availability of both graph-based and brute-force search methods offers Nyris the flexibility to tailor the search approach to specific use case requirements.
- Versatile Data Handling: Qdrant imposes almost no restrictions on data types and vector sizes, allowing Nyris to manage diverse and complex datasets effectively.
- Built with Rust: The use of Rust ensures superior performance and future-proofing, while its open-source nature allows Nyris to inspect and customize the code as necessary.
- Cost-Effective High Performance Search: Qdrant’s efficient search capabilities ensure that Nyris can maintain high performance at a reasonable cost. With Qdrant, Nyris can search through extensive datasets efficiently, making it a crucial part of their technology stack.
By hosting Qdrant on Google Cloud within their Kubernetes Cluster, Nyris benefits from the scalability and reliability essential for their demanding operations, ensuring a robust and efficient visual search solution.
Why Pure-Vector Search is the Future for Product Search
Nyris’s vision is to identify every single product and spare part within milliseconds, and Qdrant plays an integral role in this. When envisioning the future of product search, Lukasson is convinced that vector representations will be the key to advancing search capabilities. Unlike keyword searches, vector search can seamlessly integrate various modalities, such as text, images, as well as depth or audio. This holistic approach will transform product and spare part searches, allowing for a single vector representation that encompasses a product’s text, visual and geometric descriptions.
“While traditional algorithms like BM25 are fast and cheap and still have a place in the search stack, vectors will replace them in the coming years," says Lukasson. "Today, we have separate spaces for text search, visual search, and other modalities, but we envision a future with a unified vector representation that encompasses all relevant item data. No matter what input you use for your query, the search results will be accurate. The days of scrolling through thousands of results or encountering 'no results' pages will soon be over. Every search request will deliver the right product or spare part in milliseconds.”