Tag: case

Dolt，本機開發測試用的 MySQL server

看到「Dolt is Git for Data!」這個專案，是個在本機上跑的 MySQL server，另外可以在上面的資料進行版本控制，看起來很適合本機開發測試。

首先抓下來可以看到沒幾個檔案 (這是 linux-amd64 版)，也可以看到跟 Git 的關係：

$ tree
.
├── bin
│   ├── dolt
│   ├── git-dolt
│   └── git-dolt-smudge
└── LICENSES

然後用 bin/dolt sql-server -P 3307 -u root -p passw0rd 跑就可以把一個相容於 MySQL 的伺服器跑在 port 3307，然後用 mysql -h 127.0.0.1 --port 3307 -u root -p 就可以輸入密碼 passw0rd 登入進去：

$ mysql -h 127.0.0.1 --port 3307 -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.7.9-Vitess

可以從 Server version 看到專案是用了 Vitess 實做的 MySQL 界面。

另外測了一下，透過連線所做的變更 (像是 CREATE DATABASE 與 CREATE TABLE，以及 CRUD 中的 CUD) 是不會寫回磁碟裡的，嘗試了不同的設定，不管改什麼都是這樣，應該是故意設計成這樣。

在本機跑 test case 測試應該還不錯，會比 SQLite 的 :memory: 更接近 MySQL 一些，不過在 CI 裡的話應該是可以直接把 MySQL 跑起來...

Raspberry Pi 4 官方的殼 + 官方的風扇

在「Raspberry Pi heatsink and case fan continued」這邊看到 Raspberry Pi 官方有出 RPi4 的殼 + 風扇，看起來是兩個月前的消息了，雖然我自己還是比較喜歡維護上比較方便的被動散熱... (在「Raspberry Pi 4 的散熱問題」這邊有提到過兩個方案)

官方的測試是編 Linux kernel，大概會跑快一個小時，首先是跑在預設上限 1.5Ghz 的情況下：

在超頻到 1.8Ghz 但沒有風扇的情況下，除了溫度比較高，反而還會變慢：

讓人迷惑的是，加上風扇後速度其實跟沒有超頻差不多，只是整體的溫度比較低... 這樣就看不太懂了，超頻的效能跑去哪了：

所以是編譯過程卡 i/o 嗎？暫時想不到其他原因...

Raspberry Pi 4 的散熱問題

找被動散熱資料的時候翻到的，Raspberry Pi 4 有新的韌體可以刷，而新的韌體會降低一些功率消耗，也讓溫度降一些：「Thermal testing Raspberry Pi 4」。

會找被動散熱是因為手上的 Raspberry Pi (一代) 已經壞了兩顆風扇了，大概每年要換一次，風扇的成本是不高，但換起來總是頗麻煩...

而新的 Raspberry Pi 4 在拿到後，發現整包附的是散熱片 + 風扇組合，跑起來也還不錯，但長遠來看還是希望找個被動散熱方案...

目前看到幾個測試，一個是搜尋到在 Reddit 上的「Raspberry Pi 4 heatsink testing」這篇 (或是作者自己的 blog 上：「Raspberry Pi 4 heatsink testing」)，裡面提到散熱片夠大，或是用銅製散熱片，在全速跑的時候不會降速：

另外在「Raspberry Pi 4 ICE Tower CPU Cooling Fan Tested」這邊也有看到不開風扇情況下，用散熱塔也行：

另外是整個機殼都拿來散熱的方式，看起來也還行：

如果真的不夠用而需要再拼的話，也許會考慮製冷片，不過先買個殼測試看看...

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息：「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究，除了預設值以外，另外跟四種不同的參數做比較，分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人，常用的 open source 工具)、DBA 手動調整，以及 RDS：

MySQL：

PostgreSQL：

比較明顯的結論是：

  • Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台，以及包括 99% 的 Latency 與 QPS，這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
  • OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果，本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情，我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

Heroku CI 正式推出

月初才提到「Heroku 也要進入 CI 市場...」，前幾天就開放使用了：「Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use」。

收費方式是依照 Heroku Pipelines 收費，一個 Heroku Pipelines 是 USD$10/month：

Each CI-enabled Heroku Pipeline is charged just $10/month for an unlimited number of test runs.

比起其他棚是無限量 Travis CI 的 $69/month (1 concurrent job，不限時間)，或是 CircleCI 的 Free 方案 (1 concurrent job，限時每個月 1500 分鐘) 或是 USD$50/month (2 concurrent job，不限時間)，感覺有些微妙...

感覺還是先繼續用 Travis CI 好了，目前 Open Source Project 的標準，路邊可以隨便檢到很多範例用... (像是用 Google 找 ".travis.yml" "language:php" site:github.com 就可以找到很多 PHP 的範例)

用 AspectMock 來替換 PHP function...

前幾天下班前同事說小鐵 jaceju 介紹了 Codeception/AspectMock 這個把 PHP function 抽換掉的套件，不需要靠 PECL 另外裝，不過缺點是只能抽換 namespace 裡面的 function... 不過這樣對於補 code coverage 也很夠了 :o

測了一下，寫了個小程式：

<?php

namespace myscript;

require __DIR__ . '/vendor/autoload.php';

\AspectMock\Kernel::getInstance()->init();

use AspectMock\Test;

echo time(), "\n";

Test::func(__NAMESPACE__, 'time', 'now');

echo time(), "\n";

然後跑出來變成：

1466612797
now

而字串 'now' 也可以換成 anonymous function，這樣已經可以做不少事情了...