Code10x

Ek open-source enterprise search platform hai, Apache Lucene par bana — full-text search, faceting, highlighting aur distributed indexing provide karta hai.

CNET Networks ne 2004 mein apni website search ke liye banaya tha — 2006 mein Apache Software Foundation ko donate kar diya gaya.

Dono Apache Lucene par bane hain, isliye core text search capabilities (tokenizing, scoring, indexing) largely similar hain.

Jab existing infrastructure mein already deep integration ho (jaise e-commerce platforms), ya rich faceting/highlighting features out-of-the-box chahiye hon.

Lucene ek low-level Java library hai jo indexing/search ke core algorithms deti hai. Solr us library ke upar ek full server hai jo HTTP APIs aur admin tools add karta hai.

Ek data structure jahan har word ke saath ye list hoti hai ki wo word kaunse documents mein aata hai — Lucene ke search ka core concept hai.

Core/Collection (data ka logical index), Schema (fields kaise define hote hain), solrconfig.xml (behavior configure karta hai), aur Request Handlers.

SolrCloud mode mein isi concept ko "Collection" kehte hain, jo multiple servers mein distributed ho sakta hai.

Client HTTP request bhejta hai -> Request Handler receive karta hai -> Query Parser parse karta hai -> Lucene index se matching documents dhoonde jaate hain -> Response wapas jaata hai.

Ek compatible JDK installed hona zaroori hai, kyunki Solr ek Java application hai.

"bin/solr start" command se, jo default port 8983 par background daemon ki tarah start hota hai. "bin/solr stop" se stop kiya ja sakta hai.

Do most important files: "managed-schema" (ya "schema.xml") aur "solrconfig.xml" — ye dono milkar decide karte hain ki data kaise index/query hoga.

Ek web-based dashboard (http://localhost:8983/solr) jahan se cores ki stats dekhi ja sakti hain, queries run ki ja sakti hain, aur schema visually explore kiya ja sakta hai.

Directly browser se hi test queries chalayi ja sakti hain — development ke daurान sabse useful tool hai.

Ye batata hai ki kaunse endpoints (jaise "/select") kaise behave karenge — default parameters jaise "rows" ya "df" yahan set kiye ja sakte hain.

Ye define karte hain ki kitne time ya documents ke baad automatically changes commit honge — indexing performance aur search freshness ke beech ek trade-off hai.

"solr:9" jaisi official Docker image se Solr jaldi se spin up kiya ja sakta hai — local development ke liye popular tareeka hai.

Solr ka Jetty web server aur actual runtime files — ye Solr ka actual execution environment hai.

Managed Schema mode mein Schema API ke zariye fields add/modify kiye jaate hain aur Solr khud file update karta hai. schema.xml manual editing hai, purana tareeka.

Unhe re-index karna padta hai — Solr retroactively purani documents ko naye field definitions ke hisaab se re-process nahi karta.

text_general analysis (tokenizing, lowercase, stemming) se guzarti hai. string raw value ko exact match ke liye store karti hai, bina processing ke.

"string" field type — kyunki ye raw exact value store karti hai, "text" jaisi analysis se guzre bina.

Point-based numeric types (pint, pfloat, plong, pdouble) — range queries aur sorting ke liye optimized hain, purane trie-based (tint/tfloat) types se better.

Wildcard patterns (jaise "*_s" ya "*_i") jo naye fields ko automatically match karte hain, bina unhe pehle se schema mein explicitly define kiye.

Ye schema ko "implicit" aur hard-to-understand bana sakta hai — production mein explicit fields define karna better hota hai, predictability ke liye.

Ek ya more source fields ke content ko ek destination field mein copy kar deta hai — multiple fields ko ek "text" field mein merge karke ek hi search box se search karne ke liye use hota hai.

Kyunki ye index size ko bina vajah badhata hai — storage optimize karne ke liye sirf zaroori destination fields ko stored rakho.

JSON, XML, ya CSV — "/update" endpoint par post kiye jaate hain. JSON sabse common format hai modern applications mein.

Kyunki multiple documents ek hi request mein batch karke bhejne se network round-trips kam hote hain.

Add, delete aur commit operations — ye multiple formats (JSON, XML, CSV) accept kar sakta hai, content-type header par depend karke.

ID se, ya ek query se — query-based delete se multiple matching documents ek saath remove ho sakte hain.

Ek Solr contrib module hai jo directly databases (jaise MySQL, PostgreSQL) se data pull karke automatically index kar deta hai, bina custom script likhe.

Newer Solr versions mein DIH deprecated ho raha hai — modern pipelines custom scripts ya tools jaise Apache NiFi use karte hain jo database se data pull karke Solr's JSON API se post karte hain.

Ek existing document ke sirf ek ya kuch fields ko update karti hain, bina poore document ko dobara bheje — "set", "add", "inc" jaise operations available hain.

Saare fields "stored=true" hone chahiye — Solr ko existing document ke saare values ko re-index karne ke liye retrieve karna padta hai.

Uska data atomic update ke daurान kho jaayega — ye ek common gotcha hai jo developers ko surprise karta hai.

"field:value" syntax — jaise "title:laptop". Boolean operators (AND, OR, NOT) aur wildcards ("*", "?") support kiye jaate hain.

Kyunki special characters (jaise + - && || ! ( ) { } [ ] ^ " ~ * ? : \ /) query parsing error de sakte hain agar escape na kiya jaaye.

User-typed queries (jaise Google-style search box) ke special characters ke problem ko largely bachata hai aur multiple fields par ek saath search kar sakta hai.

eDisMax DisMax ke saare fayde ke saath Lucene ki full boolean/field-specific query syntax bhi support karta hai — production applications ka default choice hai.

Query fields parameter se different fields ko different weight/boost diya ja sakta hai — jaise "title" ko "description" se zyaada important banana.

"[start TO end]" syntax — numeric, date aur string fields par kaam karti hai. "*" use karke ek end ko unbounded bhi rakha ja sakta hai.

Specific terms ko boost karta hai — jaise "title:laptop^3" se "title" field mein "laptop" word ka match zyaada relevant maana jaayega.

Search results mein matching terms ko HTML tags (jaise "<em>") mein wrap karta hai — bold keywords waali UI banane ke liye use hota hai.

Field "stored=true" honi chahiye — Solr ko original text ki zaroorat padti hai snippet generate karne ke liye.

Ek field ke saare unique values aur har value ke documents ka count — "Category", "Brand" jaisi sidebar filters banane ke liye use hota hai.

Field "indexed=true" honi chahiye — faceting aksar "string" type fields par ki jaati hai, analyzed "text" fields par nahi.

Kyunki isse har word ek alag facet value ban jaata hai — jo useful facet counts nahi dete, isliye string fields prefer ki jaati hain.

Numeric/date fields ko buckets mein group karte hain — jaise "price" ko "0-100", "100-500" jaisi ranges mein divide karna, e-commerce price filters ke liye.

Multiple fields ko hierarchically nest karte hain — jaise "category then brand" — Excel ke pivot table jaisa hierarchical breakdown dete hain.

Similar documents ko ek saath group karne ke liye — jaise ek product ke multiple variants ko results mein duplicate hone se rokna.

Collapse/Expand ek group ke sirf best document ko main results mein dikhata hai aur performance mein traditional Grouping se behtar hota hai.

Ek numeric field ke min, max, sum, mean aur count jaisi statistics ek hi query mein — jaise "price" field ki average value dhoondna.

Analytics Component complex expressions aur multi-level aggregations support karta hai — SQL ke GROUP BY + aggregate functions jaisa powerful hai.

SolrCloud mode mein data aur traffic ko multiple servers ke beech distribute kiya ja sakta hai, scalability aur fault-tolerance ke liye.

"Collection" — ek Collection logically ek hi index hai lekin physically multiple servers mein shards ke taur par spread ho sakti hai.

Cluster configuration, cluster state (kaunse nodes up/down hain), aur leader election manage karta hai — SolrCloud ka central nervous system hai.

Odd number (3 ya 5) — taaki majority-based decisions (quorum) ho sakein agar kuch nodes down ho jaayein.

Ek Collection ka ek hissa — data ko multiple shards mein split karne se indexing aur search load multiple servers mein spread ho jaata hai.

Ek shard ki ek copy, ek different node par — agar ek replica ka node crash ho jaaye to doosri replicas traffic handle karti rehti hain.

HTTP calls ke zariye collections create, delete, reload aur modify kiye jaate hain — SolrCloud mein administrative tasks ke liye main interface hai.

Haan, Collections API se, bina downtime ke — jab traffic badhta hai to existing collection ko more replicas se scale kiya ja sakta hai.

Ek existing shard ko do mein split karta hai — resharding without full reindex ke, jab ek shard bahut bada ho jaaye.

Filter Cache (fq parameter ke results), Query Result Cache (poori query ke top results), aur Document Cache (individual stored fields).

Common filters (jaise "category:electronics") repeatedly use hote hain aur cache hone se expensive re-computation se bacha ja sakta hai.

Har commit par caches invalidate hote hain — Cache Warming se purane cache ke top entries ko naye cache mein pre-populate kiya jaata hai, taaki pehla query slow na ho.

Hard Commit data ko disk par permanently write karta hai (slow). Soft Commit data ko immediately searchable banata hai lekin disk par permanently write nahi karta (fast, lekin data-loss risk).

Frequent soft commits (jaise har 1 second) aur less frequent hard commits (jaise har 60 seconds) ka combination.

Kyunki "fq" results cache ho sakte hain, "q" ke unlike jisme scoring hamesha recalculate hoti hai — agar relevance scoring ki zaroorat nahi hai.

Sirf zaroori fields hi return karwata hai — poore document ko return karwana (especially large text fields) network aur processing time waste karta hai.

Bahut chota heap se OutOfMemoryError aata hai, bahut bada heap se garbage collection pauses lambe ho jaate hain.

General rule hai — machine ki total RAM ka aadha JVM heap ko do, baaki aadha OS file cache ke liye chhod do (Lucene index files ke liye).

BasicAuthPlugin username/password based authentication add karta hai — ye "security.json" file se configure hota hai.

Different users/roles ko different permissions (jaise "read-only" vs "admin") deta hai, specific collections ya actions par granular control ke saath.

Nahi — production deployments mein security.json configure karna absolutely zaroori hai.

Ek poori collection ki snapshot ek shared location (jaise network drive) par save kar sakta hai — disaster recovery ke liye essential hai.

JVM memory usage, cache hit rates, query latency aur indexing rates jaisi detailed metrics.

Solr metrics ko Prometheus format mein convert karta hai — Grafana dashboards se real-time visualize kiya ja sakta hai.

Log4j2 — "log4j2.xml" file se log levels aur different components ke liye alag loggers configure kiye ja sakte hain.

Wo queries log karta hai jo default threshold (2 seconds) se zyaada time leti hain — performance problems debug karne ka first step hota hai.

Kyunki ek time par ek node upgrade hota hai, jabki replicas traffic handle karti rehti hain — large production clusters ke liye standard practice hai.