Remove irrelevant content from GSI architecture page

content/architecture/global-secondary-indexes.dita

@@ -66,50 +66,5 @@
        </fig></p></dd>
     </dlentry>
    </dl></section>
-  <section><title>Index Storage Options</title>
-   <p>Index service can be configured to utilize standard or the memory-optimized storage option.</p>
-   <p>Memory-Optimized GSI: Indexes are created for achieving low latency query execution. When memory-optimized storage option is selected, all indexes on the cluster utilize fast in-memory index processing for efficient index maintenance and index scans. Memory optimized indexes uses the skiplist structure as opposed to B-tree indexes. Skiplist structure optimize memory consumption. They also enhance concurrent processing of index updates and scans with a lock-free processing arrangements of the index in memory. Memory optimized indexes provide the most optimized index for processing high velocity mutations and high frequency scans.</p>
-   <p>When standard storage option is selected, the supervisor process uses the ForestDB storage engine to persist changes to the individual indexes to disk. Each index gets a dedicated file. With standard storage mode, writes to the storage can either be done using an append-only write or using a write with circular reuse depending on the write mode selected for global secondary indexes.</p>
-   <p>Both write modes in the standard storage mode for GSI requires compaction to clean up the orphaned space. Writes with circular reuse require compaction much less frequently compared to the append only writes. For more information about compaction and differences between ForestDB and Couchstore, and write modes in ForestDB, see <xref href="storage-architecture.dita">Storage Architecture</xref>.</p>
-  </section>
-  <section><title>GSI and High Availability </title>
-  <p>Unlike the database engine or the views engine, Global Secondary Indexes do not provide automatic built-in replicas. As an administrator, you can manually create replicas with GSIs by using the index service to create identical indexes on separate nodes. To create redundant copies of an index, you can create the same index definition with different index names on different nodes that are running the index service. 
-  </p>
-   <p>If one of the copies of the index is not available due to a node failure, N1QL queries automatically redirect and use the available identical index for the execution of the query. This ensures that the index service has an index available for faster query execution as long as a one copy of the index is available on one of the index service nodes.</p>
-   <p>The following example shows how to place two indexes on two separate nodes (nodeA and nodeB)
-    that have identical definitions using the WITH clause.
-    <codeblock>     CREATE INDEX Index1_beer_name 
-     ON `beer-sample`(name) 
-     WHERE type="beer" USING GSI WITH {"nodes":["nodeA:8091"]};
-     CREATE INDEX Index2_beer_name 
-     ON `beer-sample`(name)
-     WHERE type="beer" USING GSI WITH {"nodes":["nodeB:8091"]};  </codeblock></p>
-  </section>
-  <section><title>GSI and Index Mirroring and Partitioning </title>
-   <p>With global secondary indexes, you can place each index only on a single node. However, as an administrator, you can create an identical index definition and place each index on a separate node to engage multiple nodes when executing highly concurrent queries. When identical index definitions on separate nodes are available, N1QL queries use the round-robin algorithm to load balance the index scan operations. This ensures each index on each node takes an equal share of the index scan workload and engages both the nodes for best performance. As an administrator, you can create more indexes with identical definitions to scale-out the index scans to additional nodes. See the example described in the previous section on "GSI and high availability".</p>
-   <p>An index definition can define a filter to limit the documents being indexed. As an administrator, you can partition indexes by splitting them into multiple smaller segments and placing the individual segments in separate nodes to engage multiple nodes for processing highly concurrent queries. </p>
-   <p>The following example illustrates partitioning the beer_name index into segments using a
-    BETWEEN clause. Index1_beer_name1 specifies names that are between "A" and "C", while
-    Index1_beer_name2 specifies names between "C" and "F", and so on.
-    <codeblock>    CREATE INDEX Index1_beer_name1 
-    ON `beer-sample`(name) 
-    WHERE type="beer" AND name BETWEEN "A" AND "C"
-    USING GSI WITH {"nodes":["nodeA:8091"]};
-
-    CREATE INDEX Index1_beer_name2 
-    ON `beer-sample`(name) 
-    WHERE type="beer" AND name BETWEEN "C" AND "F"
-    USING GSI WITH {"nodes":["nodeB:8091"]};
-    ...  </codeblock></p>
-   <p> The first query below uses Index1_beer_name1 index to return the result which only engages
-    nodeA as the index is created on nodeA, while the second query scans Index_beer_name2 index
-    which is on nodeB.
-    <codeblock>     SELECT * FROM `beer-sample` 
-     WHERE type="beer" AND name = "Blackberry";
-
-     SELECT * FROM `beer-sample` 
-     WHERE type="beer" AND name = "Downtown Brown";  </codeblock>
-   </p>
-  </section>
  </conbody>
 </concept>