{"id":109,"date":"2024-04-29T18:31:16","date_gmt":"2024-04-29T18:31:16","guid":{"rendered":"https:\/\/www.rajeshkumar.xyz\/blog\/?p=109"},"modified":"2024-05-01T20:27:09","modified_gmt":"2024-05-01T20:27:09","slug":"terminology-used-in-apache-solr","status":"publish","type":"post","link":"https:\/\/www.rajeshkumar.xyz\/blog\/terminology-used-in-apache-solr\/","title":{"rendered":"Terminology used in Apache Solr"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"458\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/04\/image-15-1024x458.png\" alt=\"\" class=\"wp-image-110\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/04\/image-15-1024x458.png 1024w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/04\/image-15-300x134.png 300w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/04\/image-15-768x344.png 768w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/04\/image-15.png 1281w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p><strong>General Solr Terminology:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Core:<\/strong> A core is a fundamental unit in Solr that represents a single logical index. It holds the schema (field definitions), configuration, and the actual indexed data. You can have multiple cores running on a single Solr instance.<\/li>\n\n\n\n<li><strong>Schema:<\/strong> The schema defines the structure of your data within a core. It specifies the fields you want to index, their data types (text, integers, etc.), and any special handling they require.<\/li>\n\n\n\n<li><strong>Document:<\/strong> An individual piece of data you want to store and search within Solr. It consists of various fields with corresponding values.<\/li>\n\n\n\n<li><strong>Commit:<\/strong> The process of making changes to the index permanent. After a commit, new data becomes searchable.<\/li>\n\n\n\n<li><strong>$SOLR_HOME:<\/strong> This environment variable points to the directory containing all Solr cores, their configurations, schema, and dependencies.<\/li>\n\n\n\n<li><strong>Document<\/strong>: The basic unit of information in Solr, which is indexed and searched. A document is a collection of fields.<\/li>\n\n\n\n<li><strong>Field<\/strong>: A piece of information in a document. Each field has a defined data type and can be configured to have various properties in terms of indexing and searchability.<\/li>\n\n\n\n<li><strong>Schema<\/strong>: Defines the fields and field types for documents in an index. The schema specifies the fields that can exist in a document and how those fields should be processed and queried.<\/li>\n\n\n\n<li><strong>Index<\/strong>: The physical representation of a Solr data structure built using the Apache Lucene library. The index stores searchable tokens generated from the data sent to Solr.<\/li>\n\n\n\n<li><strong>Tokenization<\/strong>: The process of breaking text down into smaller parts, called tokens, which are then indexed. This is part of the text analysis process.<\/li>\n\n\n\n<li><strong>Analyzer<\/strong>: A component used during indexing and querying that applies a series of tokenizers and filters to transform field data into a format that enhances search effectiveness.<\/li>\n\n\n\n<li><strong>Filter<\/strong>: In the context of an analyzer, a filter modifies the tokens generated by a tokenizer. Examples include lowercase filters, stop word filters, and synonym filters.<\/li>\n\n\n\n<li><strong>Query Parser<\/strong>: Interprets the query string from the user and transforms it into a form that Solr can understand. Solr supports several query parsers, each designed for different types of search needs.<\/li>\n\n\n\n<li><strong>Faceting<\/strong>: A feature that allows users to explore data by aggregating and counting occurrences of each unique value of a field.<\/li>\n\n\n\n<li><strong>Boosting<\/strong>: A technique to increase or decrease the relevance of certain documents based on specific criteria during search queries.<\/li>\n<\/ul>\n\n\n\n<p><strong>SolrCloud Terminology (for distributed deployments):<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Node:<\/strong> An individual Solr server instance participating in a SolrCloud cluster.<\/li>\n\n\n\n<li><strong>Cluster:<\/strong> A group of Solr nodes working together to manage a distributed index. They coordinate through a central service like Zookeeper.<\/li>\n\n\n\n<li><strong>Collection:<\/strong> A logical view of an index in SolrCloud. It can be further divided into shards for scalability.<\/li>\n\n\n\n<li><strong>Shard:<\/strong> A horizontal partition of a collection spread across multiple Solr nodes. Each shard holds a subset of the entire data.<\/li>\n\n\n\n<li><strong>Replica:<\/strong> A copy of a shard running on a different Solr node within the cluster. This ensures redundancy and fault tolerance.<\/li>\n\n\n\n<li><strong>Leader:<\/strong> A designated replica responsible for handling read\/write requests for a particular shard and coordinating with other replicas.<\/li>\n\n\n\n<li><strong>Zookeeper:<\/strong> An external service used by SolrCloud for centralized configuration management, cluster coordination, and leader election.<\/li>\n\n\n\n<li><strong>Solr Instance (Solr Server)<\/strong>: A running instance of Solr. This can refer to a single Solr server or a node in a SolrCloud cluster.<\/li>\n<\/ul>\n\n\n\n<p><strong>In Solr terminology, there is a sharp distinction between the&nbsp;<em>logical<\/em>&nbsp;parts of an index (collections, shards) and the&nbsp;<em>physical<\/em>&nbsp;manifestations of those parts (cores, replicas). In this diagram, the \u201clogical\u201d concepts are dashed\/transparent, while the \u201cphysical\u201d items are solid.<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"933\" height=\"717\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-5.png\" alt=\"\" class=\"wp-image-140\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-5.png 933w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-5-300x231.png 300w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-5-768x590.png 768w\" sizes=\"auto, (max-width: 933px) 100vw, 933px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Element<\/strong><\/td><td><strong>Description<\/strong><\/td><\/tr><tr><td><strong>Node<\/strong><\/td><td>\u2022 one Solr node corresponds to one physical server.<br>\u2022 Single-node systems are for testing and development. They do not provide the&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/solr-collection-core-shard-replica\/#HA\">high-availability\/fault-tolerant (HA\/FT)<\/a>&nbsp;behavior needed by production systems.<br>\u2022 A single-node deployment uses an Nginx load-balancer. The log files are not available to the user.<br>\u2022 The node hosts a single Zookeeper instance on the same server as Solr.<br>\u2022 If Solr stops, query service stops.<br>\u2022 A single-node system can be upgraded to increase memory, CPUs, and disk space. It cannot be expanded to create a cluster.<\/td><\/tr><tr><td><strong>Cluster<\/strong><\/td><td>\u2022 <a href=\"https:\/\/www.searchstax.com\/blog\/apache-solr-architectures-for-cloud\/\">cluster<\/a>&nbsp;has at least two Solr nodes to provide high-availability\/fault-tolerant behavior. If a Solr issue degrades or stops one node, query traffic automatically continues on the other node(s).<br>\u2022 A cluster has a dedicated Load Balancer. It stores a week of log files.<br>\u2022 The cluster includes a three-node Zookeeper ensemble. The Zookeeper and Solr instances are not co-resident on the same servers.<br>\u2022 There is no upper limit on the number of Solr nodes in a cluster.<\/td><\/tr><tr><td><strong>Zookeeper Ensemble<\/strong><\/td><td>\u2022 Zookeeper ensures that changes to config files and updates to index segments are automatically distributed across the nodes of the cluster.<br>\u2022 It also determines which Solr server is the \u201cleader\u201d node for each of the collections.<\/td><\/tr><tr><td><strong>Collection<\/strong><\/td><td>\u2022 A \u201ccollection\u201d is a single&nbsp;<strong><em>logical index<\/em>&nbsp;<\/strong>in its entirety, regardless of how many replicas or shards it has.<br>\u2022 One Solr node can host multiple collections. (A single Sitecore site typically generates over a dozen Solr collections.)<\/td><\/tr><tr><td><strong>Shard<\/strong><\/td><td>\u2022 A \u201cshard\u201d is a&nbsp;<em>logical subset<\/em>&nbsp;of the documents in a collection. Shards let us split a massive index across multiple servers. &nbsp;<br>\u2022 SearchStax clients don\u2019t usually subdivide their collections, so for our purposes a \u201cshard\u201d and a \u201ccollection\u201d are the same thing. We rarely speak of shards.<br>\u2022 Sharding multiplies the number of servers required to achieve high-availability\/fault-tolerant behavior.<br>\u2022 Sharding greatly complicates&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/backups-fail\/\">backup and restore<\/a>&nbsp;operations.<br>\u2022&nbsp;<em>If your index can fit comfortably on one server, then use one shard.<\/em>&nbsp;This is Solr\u2019s default behavior.<\/td><\/tr><tr><td><strong>Core<\/strong>&nbsp;and&nbsp;<strong>Replica<\/strong><\/td><td>\u2022 A \u201ccore\u201d is a complete&nbsp;<em>physical index<\/em>&nbsp;on a Solr node. a \u201ccore\u201d is&nbsp;<em>replicated<\/em>&nbsp;to multiple nodes. Therefore, \u201creplicas\u201d are cores.<br>\u2022 Due to the details of index segment processing, replicas of an index are&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/nodes-use-different-disk-space\/\">not all the same physical size.<\/a><br>\u2022 To achieve high-availability\/fault-tolerant (HA\/FT) behavior, every node of the cluster must have a replica of every collection.<br>\u2022 When you create a collection, set&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/fixing-solr-replicationfactor-error\/\">replicationFactor<\/a>&nbsp;equal to the number of nodes in the cluster. Replication is automatic after that step.<br>\u2022 It is a SearchStax convention to speak of replicas rather than cores, hopefully avoiding confusion.<\/td><\/tr><tr><td><a><\/a><strong>High-Availability<\/strong><\/td><td>\u2022 \u201cHigh-availability (HA)\u201d refers to a cluster of redundant Solr nodes, all of which can respond to queries. If one node goes down, the other nodes can temporarily take up the query load.<\/td><\/tr><tr><td><strong>Fault-Tolerant<\/strong><\/td><td>\u2022 \u201cFault-tolerance (FT)\u201d enables Solr to continue to serve queries, possibly at a reduced level, rather than failing completely when a component of Solr gets into difficulty.<br>\u2022 Solr\/Zookeeper has fault-tolerant strategies such as automatically rebuilding a replica that has become unresponsive. These features handle mild issues if given enough time, but can become overwhelmed.<\/td><\/tr><tr><td><a><\/a><strong>Rolling Restart<\/strong><\/td><td>\u2022 When a Solr system has been severely stressed, its fault-tolerant features can get stuck in a degraded state. There are many possible ways for this to happen, frustrating a direct link from cause to result.<br>\u2022 The \u201croot cause\u201d of this situation is usually that the client sent too many&nbsp;<strong>\/update<\/strong>&nbsp;requests in too short a time, or that the&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/taming-commits\/\">updates were inefficient<\/a>.&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/hc\/searchstax-cpu-level\/\">CPU and memory<\/a>&nbsp;became overloaded, and unneeded subsystems were shut down (but were not automatically restarted).<br>\u2022 A \u201crolling restart\u201d shuts down each Solr node in the cluster and restarts it. This returns Solr to a known state. Due to the cluster\u2019s High Availability, this does not interrupt query service.<br>\u2022 SearchStax provides a button on the Deployment Details screen to let you do a rolling restart at any time.<\/td><\/tr><tr><td><strong>Disaster Recovery<\/strong><\/td><td>\u2022&nbsp;<a href=\"https:\/\/www.searchstax.com\/docs\/searchstax-cloud-solr-disaster-recovery\/\">Disaster Recovery<\/a>&nbsp;refers to:\u25e6 A full duplicate production deployment (\u201cHot\u201d DR) that can take over the query load at a moment\u2019s notice.\u25e6 A reduced-size production deployment than can be rapidly expanded (\u201cWarm\u201d DR).\u25e6 Or a remotely-stored recent backup (\u201cCold\u201d DR).\u2022 DR failover occurs automatically when High-Availability fails (all nodes have been&nbsp;<em>unresponsive for five minutes<\/em>&nbsp;).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Documents<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"482\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-9-1024x482.png\" alt=\"\" class=\"wp-image-154\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-9-1024x482.png 1024w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-9-300x141.png 300w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-9-768x361.png 768w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-9.png 1110w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Solr Core<\/strong> (similar to index)<\/h2>\n\n\n\n<p>A Solr Core is essentially a single index managed by Solr. It includes the configuration files necessary for Solr to understand how to index and search the data, the data itself, and the Solr software that processes requests and manages the index. A core is a fundamental unit of Solr capable of handling search requests independently.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Key Aspects<\/strong>:\n<ul class=\"wp-block-list\">\n<li>Contains its own set of configuration files, such as <code>solrconfig.xml<\/code> and <code>schema.xml<\/code>.<\/li>\n\n\n\n<li>Manages a single index.<\/li>\n\n\n\n<li>Operates independently but can exist alongside other cores within a single Solr instance (server).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Solr Collection<\/strong> (similar to index)<\/h2>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"501\" height=\"622\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-6.png\" alt=\"\" class=\"wp-image-148\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-6.png 501w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-6-242x300.png 242w\" sizes=\"auto, (max-width: 501px) 100vw, 501px\" \/><\/figure>\n\n\n\n<p>When Solr operates in a distributed mode (using SolrCloud), the concept of a Collection becomes relevant. A collection is a logical index that spans multiple Solr instances (Solr servers). Collections are split into multiple shards, with each shard hosting a subset of the collection&#8217;s data.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Key Aspects<\/strong>:\n<ul class=\"wp-block-list\">\n<li>A collection is equivalent to a complete index but distributed across multiple servers.<\/li>\n\n\n\n<li>Supports horizontal scaling because data can be divided into multiple shards.<\/li>\n\n\n\n<li>Useful for achieving high availability and balancing load across servers.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Solr Shard<\/strong><\/h2>\n\n\n\n<p>A <strong>Shard<\/strong> is a subset of a collection&#8217;s data. It is a partition of the entire collection\u2019s dataset, enabling the distribution of the collection across multiple nodes. Each shard is, in itself, a complete Solr index.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Key Aspects<\/strong>:\n<ul class=\"wp-block-list\">\n<li>Holds a part of the collection&#8217;s data.<\/li>\n\n\n\n<li>Each shard can be hosted on a different Solr node.<\/li>\n\n\n\n<li>Shards are essential for scaling large datasets across multiple nodes.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Solr Replica<\/strong><\/h2>\n\n\n\n<p>Within each shard of a collection, there can be multiple replicas. These replicas are copies of the shard that exist to provide redundancy, failover, load balancing, and improved query performance. Solr uses ZooKeeper to manage the state of replicas across the cluster, and to balance queries and updates across them.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Key Aspects<\/strong>:\n<ul class=\"wp-block-list\">\n<li>Each replica holds a copy of a shard\u2019s data.<\/li>\n\n\n\n<li>Helps in providing high availability and fault tolerance.<\/li>\n\n\n\n<li>Used for distributing query load and handling failover in case a server goes down.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p>In a SolrCloud environment, these concepts interlink to provide a robust, scalable search architecture:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Core<\/strong>: A single Solr instance managing a single index.<\/li>\n\n\n\n<li><strong>Collection<\/strong>: A distributed index across multiple Solr instances, logically viewed as a single index.<\/li>\n\n\n\n<li><strong>Shard<\/strong>: A partition of a collection&#8217;s data, each shard being a full index.<\/li>\n\n\n\n<li><strong>Replica<\/strong>: Copies of a shard&#8217;s data, providing redundancy and load balancing.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Difference between Solr Collection and Replica and Core and Shards<\/h2>\n\n\n\n<p>Here&#8217;s a tabular comparison of the key Solr concepts: <strong>Core<\/strong>, <strong>Collection<\/strong>, <strong>Shard<\/strong>, and <strong>Replica<\/strong>. This format should help clarify the distinctions and roles of each in the context of Solr and SolrCloud.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Concept<\/strong><\/th><th><strong>Definition<\/strong><\/th><th><strong>Role<\/strong><\/th><th><strong>Use in Solr\/SolrCloud<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>Core<\/strong><\/td><td>A single Solr instance managing one index. Includes its own configuration and index files.<\/td><td>Manages a single, complete index. Can handle queries and indexing operations independently.<\/td><td>Used in both standalone Solr setups and within each node in SolrCloud as part of collections.<\/td><\/tr><tr><td><strong>Collection<\/strong><\/td><td>A logical index spread across multiple Solr nodes or instances in SolrCloud. It is split into multiple shards.<\/td><td>Represents a complete index distributed across multiple servers. Enables horizontal scaling and load balancing.<\/td><td>Specific to SolrCloud, facilitating scalability and fault tolerance across multiple nodes.<\/td><\/tr><tr><td><strong>Shard<\/strong><\/td><td>A partition of a collection&#8217;s data. Each shard is a subset that holds a portion of the collection\u2019s data and is a complete index on its own.<\/td><td>Allows distribution of the collection\u2019s data across multiple nodes. Each shard can be hosted on a different node.<\/td><td>Essential in SolrCloud for distributing large datasets and enhancing search performance and scalability.<\/td><\/tr><tr><td><strong>Replica<\/strong><\/td><td>Copies of a shard&#8217;s data located on different or the same Solr nodes. Each replica is a full index.<\/td><td>Provides redundancy for high availability and load balancing of queries and updates.<\/td><td>Used in SolrCloud to ensure data availability and to improve query response times by distributing the load.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"826\" height=\"303\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-17.png\" alt=\"\" class=\"wp-image-165\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-17.png 826w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-17-300x110.png 300w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-17-768x282.png 768w\" sizes=\"auto, (max-width: 826px) 100vw, 826px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"990\" height=\"470\" src=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-19.png\" alt=\"\" class=\"wp-image-169\" srcset=\"https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-19.png 990w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-19-300x142.png 300w, https:\/\/www.rajeshkumar.xyz\/blog\/wp-content\/uploads\/2024\/05\/image-19-768x365.png 768w\" sizes=\"auto, (max-width: 990px) 100vw, 990px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Reference<\/h2>\n\n\n\n<p><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/solr.apache.org\/guide\/solr\/latest\/getting-started\/solr-glossary.html\">https:\/\/solr.apache.org\/guide\/solr\/latest\/getting-started\/solr-glossary.html<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>General Solr Terminology: SolrCloud Terminology (for distributed deployments): In Solr terminology, there is a sharp distinction between the&nbsp;logical&nbsp;parts of an [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-109","post","type-post","status-publish","format-standard","hentry","category-apache-solr"],"_links":{"self":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/comments?post=109"}],"version-history":[{"count":10,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/109\/revisions"}],"predecessor-version":[{"id":170,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/109\/revisions\/170"}],"wp:attachment":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/media?parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/categories?post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/tags?post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}