3D裝箱問題

3D裝箱問題

最近遇到一家客戶的集批設備必須考慮容積限制,所以順便google下原來這有專

有名詞叫做裝箱問題(3D BIN Packing)。git上也有不少這類的程式,也看了不

少paper，最多應用的paper都是船舶貨櫃業，想一想也是,多裝一個櫃成本多

很多，才會衍生求解此問題的價值。

最後在google上找到一個神人用excel寫的,還附帶用excel話的3D圖(超屌)

http://people.bath.ac.uk/ge277/index.php/clp-spreadsheet-solver/

以下是程式大概的邏輯

應用演算法:large neighborhood search

1.先排序itemtype,排完一種後再換一種堆疊

2.Itemtype要先依照可堆最多個原則選擇擺放哪一面(考慮6個面)

3.考慮長寬高,重量限制,某item與某item是否可在同容器的限制

4.效益高的item先放,成本低的容器先選

5.迭代:跑機率一半從最佳解開始變形,一半從目前解開始變

這個演算法針對特定行業問題有優勢，因為可以運用行業domain寫業務邏輯

再加上版身演算法的迭代求解過程通常可以找到不錯的解。

題外話,測試時發現一個簡單的問題100個A,100個B,如果箱子全部用A可以得

到最佳解,但只要混了B就有機率填不滿容器(箱子)，這是此演算法的特性,

他會從目前的解一直變形,也就是說目前的解如果走錯路之後就會一直錯下去。

針對此問題的解法是增加業務邏輯，在迭代求解前先用單一item(A或B)是否

可以得到最佳解，不行再進入演算法的迭代過程。

最後花了3天的時間把exce的code移植成C#版本,畫圖的部份則改用WPF的

3D模型來實作內部有的寫法是因為vba的限制,其實搬到C#可以用更好的寫法,

目前列第二階段再調整

以下是目前的畫面。

這個3D模型也是google找來的,我只修改部份程式碼(丟要畫幾個圖形及座標)

雖然滿足率都是1,但是看圖形可以發現組合不一樣

比特幣是區塊鏈的應用

比特幣是區塊鏈的應用

每個block
    10分鐘內的交易紀錄+前個block的hash值+一個數值(nonce)產生一個hash值(很長)
   
礦工的工作
    找出未被確認的block(只有一個,大家競爭),block內含10分鐘的交易
    要用電腦找出數值(nonce),讓nonce+10分鐘內的交易紀錄+前個block的hash值可以小於dufficulty
    找到後可以廣播把結果給其他礦工核可(除了10分鐘交易外,還有礦工酬勞也一併在此block),
    各方核可後才把該block掛到鏈上
   
平常的交易
    交易通常由礦工的帳本可以檢查付款方是否有足夠的金額給付,檢查過了會放到
    交易池(未被確認的block)交給礦工去計算該block

Read Committed Snapshot與SNAPSHOT isolation差異

SQL2005隔離層級
Read Committed Snapshot與SNAPSHOT isolation差異

Read Committed Snapshot只是Read Committed的進化版本,本質上並一是一種事務隔離層級,
在此模式下select語句並不會等待該row commit,而是直接讀取上一個已經commited的資料
那跟select語句使用with nolock有什麼差異?簡單說nolock一樣不會等待row commit
但是可能取到uncommited的資料(垃圾)。

SNAPSHOT isolation呢
當第一個事務啟動此隔離層級,後續每個事務對同一筆資料讀到的都是當時commited的資料
假設有個值i=10,三個session同時啟動事務
第一個session讀到10,把10給為15,commit
第二個session讀到10,把10給為15,commit,
第三個session讀到10,把10給為100,commit

然後
第一個session commit成功,另外兩個session commit會失敗

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查询计划

[SSIS]當資料來源透過cursor或程式邏輯產生的,要如何取出資料集？ 使用[執行SQL工作]

1.當資料來源透過cursor或程式邏輯產生的,最後資料放在table variable,可以透過[執行SQL工作編輯器]把資料集取回

2.此結果集要指定給一個ssis變數,此變數型態為object

3.接著使用foreach將資料一筆一筆取出

4.指定foreach取出的資料,一個欄位要指定一個變數承接

5.這邊例子是透過這兩個變數組成insert語法

union與union all差異

select part,sum(qty) qty
from
(
   select part,sum(qty) qty from A
   union
   select part,sum(qty) qty from B
)
上面的語法union會把A+B撈出的資料做distinct
這樣會導致最外層sum的時候資料有短缺