Solr基本定義釐清

• Cluster
  由一群Node組成，並且由ZooKeeper管理。當有新的Core要加入，必須向ZooKeeper註冊。
• Node
  要用來跑Solr的JVM instance，一般來說就是Server。如果有需要的話，一個Node上可以跑好幾個Core。
• Core
  Server instance，也同時代表Solr index。每個Core擁有自己的Config文件與schema定義文件。
• Collection
  由一群Core組成，而這些Core來自於同一個single logical index。而每個Collection也擁有自己專屬的Config文件與schema文件。
• Shard 
  單一Collection的邏輯區塊logical section

Solr簡介

• 基於Lucene的企業及全文檢索搜尋平台
• 近實時的索引(查詢)能力 
• Solr Core是跑在真實Solr伺服器中唯一要被具體命名、可被管理、config的索引，也就是說一台Solr Server可以託管多個Solr Core
• 承上，Core就是索引，那為何要有多個Core呢？因為不同文件有不同的組成方式，例如欄位不同，像商品資料就和氣象資料差異極大，需要不同的Core來索引與儲存
• schema是Solr Core中用來定義欄位的文件，包含欄位的名稱、data type...或是這個欄位是否能被索引或儲存
• schema可以事先定義，也可以透過API動態實現
• schema更新不用重啟Solr Core，但是舊文件不會因為新的schema而更新舊的索引，只有新文件才會套用新schema
• Collection是logical的，Core是physical的
• Solr不提供藉由程式撰寫來Reindex，它的Reindex其實就是index it again，讓整個index的過程重跑一次
• 需要Reindex的情況有"Schema Changes"與"Upgrade"二種，所以強烈建議將Reindex安排在升級的時候一起作，因為實施的過程中有部分時間無法適用，除非用SolrCloud才能index to another collection
• SolrCloud = Solr + ZooKeeper
• 承上，早期作擴展遇到failover都要手動處理，難度很高，後來引入Hadoop常用的ZooKeeper來作failover和load balance，就稱之為SolrCloud

Log Structure Merged Tree簡介

 Log Structure Merged Tree簡稱LSM，閱讀筆記如下：

• key:value的儲存系統設計
• 因key:value特性寫入快速，但犧牲讀取速度
• 原理是一棵大樹，分成多棵小樹，每次寫入都由C0開始，資料量變大後，往上merge為C1，並取代舊的C1
• key:value的更新僅限於C0層才會即時操作，若是要更新的資料已經被推到上層了，會等到merge的時候才一併處理
• 需要密集寫入，少量查詢的場景很適合採用LSM