DevOps筆記

Chef
    想像一下我們現在需要搭建一台MySQL Database Slave服務器，安裝過程我們手動操作了沒過多久，又需要第二台，這時候我們會想，如果之後安裝第一台的時候把操作過程執行的命令寫成腳本，現在安裝第二台，運行一下腳本就行了，節約時間而且不容易出錯。
Chef就相當於這樣的一個腳本管理工具，但功能要強大得多，可定製性強，Chef將腳本命令代碼化，定製時只需要修改代碼，安裝的過程就是執行代碼的過程。
來源：http://heylinux.com/archives/2175.html

Continuous Integration 持續整合(CI工具)
    持續集成（CI）的目標是對開發團隊的代碼進行集成，包括代碼的構建、單元測試與集成測試的執行，以及生成執行結果的報表等等。CI使開發團隊無需將時間浪費在處理代碼衝突的問題上，因此很多人將其視為敏捷軟件開發的奠基石。
比較常見的軟體是Jenkins
來源:http://www.infoq.com/cn/news/2016/04/DevOps-continuous-integration-to

Docker
Docker 解決什麼問題?
    想像我們有網站伺服器、資料庫伺服器等。
為了兩個環境不互相影響，我們會用兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
另外，測試環境也同樣會這樣建立。兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
開發環境也是同樣這樣建立。兩個 Virtual Machine 建立， VM 1 為網站伺服器，VM2 為資料庫伺服器。
問題來了，測試、開發、上線環境都需要這樣建立，有沒有比較快的方式呢?
我們可能建立完一個環境之後，將該好幾G Mb檔案大小的 VM複製。複製完後，再對該系統環境做一些小修改。
這是目前使用 VM 的情境。
Docker 出現之後
    就再也不用複製好幾 G 的檔案，同時在一個VM內，就可以執行container 1 網站伺服器，container 2 資料庫伺服器。
Container 1 與 Container 2相互獨立不影響，每一個 Container 檔案都很小。運作起來就好像獨立的 VM 一般。
由於檔案小，又可以保有獨立的環境運作，因此在DevOps環境佈署上，Docker 成為一個火紅的話題。
來源：http://www.qa-knowhow.com/?p=1638

斯斯有三種，Join的訣竅也有三種!

最近遇到一件詭異的事，某個平常很穩定的SQL，忽然執行到逾時。上網查發現原來是統計資訊不及時導致SQL Server選錯執行計畫。原來平常SQL的Join在內部還可分為三種執行模式。似乎是如果table資料常有大量的資料異動，像是我們家APS每次跑一個計畫就要寫入上百萬筆資料，很容易因為統計資訊更新不及時出現選錯執行計畫的窘境，我們公司的DBA是建議就使用hash join 雖然不是最佳的選擇，但至少穩定。

以下為MSDN的說明:

出處:Advanced Query Tuning Concepts

SQL Server employs three types of join operations:

• Nested loops joins
• Merge joins
• Hash joins

If one join input is small (fewer than 10 rows) and the other join input is fairly large and indexed on its join columns, an index nested loops join is the fastest join operation because they require the least I/O and the fewest comparisons. For more information about nested loops, see Understanding Nested Loops Joins.
If the two join inputs are not small but are sorted on their join column (for example, if they were obtained by scanning sorted indexes), a merge join is the fastest join operation. If both join inputs are large and the two inputs are of similar sizes, a merge join with prior sorting and a hash join offer similar performance. However, hash join operations are often much faster if the two input sizes differ sihttps://www.blogger.com/blogger.g?blogID=3153720234527010496#editor/target=post;postID=2111640605181692195gnificantly from each other. For more information, see Understanding Merge Joins.
Hash joins can efficiently process large, unsorted, nonindexed inputs. They are useful for intermediate results in complex queries because:

• Intermediate results are not indexed (unless explicitly saved to disk and then indexed) and often are not suitably sorted for the next operation in the query plan.
• Query optimizers estimate only intermediate result sizes. Because estimates can be very inaccurate for complex queries, algorithms to process intermediate results not only must be efficient, but also must degrade gracefully if an intermediate result turns out to be much larger than anticipated.

The hash join allows reductions in the use of denormalization. Denormalization is typically used to achieve better performance by reducing join operations, in spite of the dangers of redundancy, such as inconsistent updates. Hash joins reduce the need to denormalize. Hash joins allow vertical partitioning (representing groups of columns from a single table in separate files or indexes) to become a viable option for physical database design. For more information, see Understanding Hash Joins.

這邊有大陸高手中文說明，有範例
 看懂SqlServer查询计划