剛好工作上用到,記錄一下…. 這樣以後再用到時就只要稍微改一下相關的參數就好了XD
trino --server localhost:8080 \
--user george \
--execute 'SELECT * FROM A as a
LEFT JOIN b ON a.id = b.id
WHERE a.id > 0' \
--output-format CSV > ~/workspace/mds_object.csv
Just another WordPress site
剛好工作上用到,記錄一下…. 這樣以後再用到時就只要稍微改一下相關的參數就好了XD
trino --server localhost:8080 \
--user george \
--execute 'SELECT * FROM A as a
LEFT JOIN b ON a.id = b.id
WHERE a.id > 0' \
--output-format CSV > ~/workspace/mds_object.csv
之前是使用Certbot來更新我這個網誌的Let’s encrypt certificate,運作上也還算正常,但自動更新cert這邊常常更新不了(這部分感覺應該是我設定上的問題)…
後來在公司上, DK有提到了dehydrated這個輕量化的Let’s enrypt 設定工具,實際上去快速看了一下它的repoistory以後,真的覺得對於一般的Linux 環境使用上蠻友善的(因為它所需要的工具通常都是Linux 系統預設的工具)。
快速掃完以後,直接進入正題關於設定上的相關指令… (這邊直接參考 DK 的 wiki上的設定)
# using a temporary directory to download the dehydrated
cd ~/tmp
wget "https://raw.githubusercontent.com/dehydrated-io/dehydrated/master/dehydrated"
chmod +x dehydrated
sudo mv dehydrated /usr/local/bin/
# create directories that dehydrated will need
sudo mkdir -p /etc/dehydrated /var/www/dehydrated
#change to the dehydrated dir
cd /etc/dehydrated
# setup the config
echo 'OCSP_MUST_STAPLE=yes' | sudo tee -a config
echo 'KEYSIZE=2048' | sudo tee -a config
echo 'WELLKNOWN=/var/www/dehydrated' | sudo tee -a config
# setup the domain file
echo 'blog.gechen.org' | sudo tee -a domains.txt
這邊的範例主要是透過Nginx來當做之後dehydrated 執行時,用來回應Let’s encrypt 的challenge…
下面就直接貼Nginx 的對應domain的範例設定檔
server {
listen 80;
server_name blog.gechen.org;
rewrite ^(.*) https://$host$1 permanent;
}
server {
listen 443 ssl;
server_name blog.gechen.org;
index index.php;
ssl_certificate /etc/dehydrated/certs/blog.gechen.org/fullchain.pem;
ssl_certificate_key /etc/dehydrated/certs/blog.gechen.org/privkey.pem;
# ... skip some configs
# this part is for dehydrated
location /.well-known/acme-challenge/ {
alias /var/www/dehydrated;
}
}
如果是第一次使用 dehydrated
則要額外執行下面指令
sudo dehydrated --register --accept-terms
透過下面的指令來做Let’s encrypt certificate的申請/更新
# the following command will apply/renew certificates for the domains in file: /etc/dehydrated/domains.txt
sudo dehydrated -c
# or we can also directly use command below to apply for specific domain certificate
sudo dehydrated -c -d blog.gechen.org
這邊直接引用DK 大大的wiki範例來設定 weekly 的憑證更新…
echo -e '#!/bin/bash\nexport PATH=/usr/sbin:/usr/bin:/bin:"${PATH}"\nsleep $(expr $(printf "%d" "0x$(hostname | md5sum | cut -c 1-8)") % 86400); dehydrated -c && ( service nginx reload )' | sudo tee /etc/cron.weekly/dehydrated; sudo chmod 755 /etc/cron.weekly/dehydrated
從DK的blog上看到的分享工具 data-diff 後, 快速看了一下它的說明文件以後, 感覺這東西有需求的話應該會蠻不錯用的!
看起來可以比對多個data source的資料表, 而且預計支援的資料庫或相關服務也蠻多是市面上常見的… 蠻適合以後有需要時再來試看看.
最近收到AWS的個人帳單以後, 突然發現我帳單上的金額與我的想像有些落差, 也因為這樣子, 開始來對一下是哪些項目在吃錢…
大概對了一下, 發現主要的花費在EC2 instance 與 EBS 兩個項目上面, EC2 instance 這邊的花費就是題外話了, 但EBS這邊就慢讓我意外的… 細看了以後才發現當初不知道為什麼把使用的EBS 成 使用30GB, 但我實際上的使用也才6GB左右…
(雖然這也不是什麼大錢, 但每個月給它這樣扣也是覺得還不如把錢省下來去訂閱其他有用服務….)
原本想說把root volume EBS 調低應該不是件難事, 結果沒想到AWS預設上是不支援這件是的, 它可以往上調高, 但不支援調低…
在網路上找了不少相關的教學文, 主要的作法都是, 大概都是…
rsync
的資料拷貝/boot
以後, 就可以把新的EBS volume來取代原有的 EBS root volume. /dev/sda1
才會成為那台EC2上的root volume)經由上述步驟的教學文實際嘗試以後, 都會卡再做出來的EBS volume是無法當成是原本這一台EC2的root volume, 它會直接讓那台EC2開不起來. (機器顯示 running
, 但是ssh 連不到…)
上述的測試其實我參考了不少文章, 但最後卡的點都是一樣的, 做出來的 EBS volume是不能用的… (我這邊使用的EC2 t4g family, 不太確定跟ARM 版本的 grub-install
有關??? 也許今天使用的是x86的機器就可以? 之後有機會再來試試)
因為上面測試也花了不少時間, 所以最後就自己做了一些流程上的調整如下:
rsync
將舊的EC2 資料都複製到新的EC2上. (基本上除了 /boot, /tmp, /mnt, /dev
以外, 都要sync 到新的EC2的對應資料夾)最後靠這個方式成功把 EBS size降下來了, 不過靠這個方式比較像是duplicate出一台新的EC2, 而不是clone出一模一樣的機器…
雖然說我本身沒在接觸SRE 相關的工作職責, 但有看到相關資訊還是來紀錄一下…
Grafana Labs 最近出了 一套 Grafana OnCall OSS, 直接瞄準了SRE 對於Oncall 相關的需求XDDD
看起來對於 PagerDuty 這類型的服務應該會產生一定程度的影響
在Hacker News 上看到的一些相關比較,作者比較了現有AWS Lambda 的程式語言,並記錄每種語言在不同情境下的cold start的時間。
測試架構大概如下:
clients -> HTTP API -> Lambda function -> Dynamo DB
Cold start:
* All languages(except Java and .Net) have a pretty small cold start.
AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) | by Aleksandr Filichkin | Sep, 2021 | Medium
* Java even cannot start with 128Mb. It needs more memory. But GraalVM can help in this case.
* Rust beats all runtimes for all setups for cold start, the only exception is 128 MB where Python is the best.
Warm start:
* Golang and Rust are the winners. They have the same brilliant performance.
AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) | by Aleksandr Filichkin | Sep, 2021 | Medium
* .Net has almost the same performance as Golang and Rust, but only after 1k iterations(after JIT).
* GraalVM has a stable great performance almost the same as .Net and a bit worse than Rust and Golang. But it doesn’t perform well for the smallest setup.
* Java is the next after GraalVM.The same as .Net, Java needs some time(1–3k iterations) for JIT(C1). Unfortunately for this particular use case, I was not able to achieve the expected great performance after JIT C2 compilation. Maybe AWS just disabled it.
* Python has stable good performance but works too slow for the 128 MB.
* Ruby has almost the same performance as Python, but we see some duration growing after 20 min invocations(after 15k iteration).
* NodeJs is the slowest runtime, after some time it becomes better(JIT?) but still is not good enough. In addition, we see the NodeJS has the worst maximum duration.
Go與Rust是其中最穩定的且效能最好的,在幾乎所有的情境下,都是前2名。(唯一的例外是,Python在128MB RAM 的環境下是最快的)。
對我而言比較意外的是Node.js,沒想到會是最慢的!?
網路上看到的一個Cassandra的簡易計算機,作者還有的提供原始碼在Github 上,所以如果有需要的話也可以自己fork一份自己架在自己的網頁上。
這個計算機的功能也很簡單,主要是提供使用者可以快速顯示在不同的cluster狀態下,根據keyspace的read/write 設定對於叢集的影響,像是:
從Databrick blog 上看到的一篇文章,剛好在提到一些資料處理概念,剛好也可以複習一下相關的知識。
et’s first dive into what exactly incremental ETL is. At a high level, it is the movement of data between source and destination – but only when moving new or changed data. The data moved through incremental ETL can be virtually anything – web traffic events or IoT sensor readings (in the case of append data) or changes in enterprise databases (in the case of CDC).
https://databricks.com/blog
概念上,就是將原始收集到的資料,透過每個階段的ETL job,來整理與清洗資料,並且再存入下一個資料儲存的地方;而每個處理的階段就因組織而異了,但最終目的就是希望真的需要用某些資料時,它已經是處理好在那了。
另外,大量的原始/歷史資料其實就可以存在像Datalake 這類型的地方,以減少儲存成本。
對於Data driven的組織來說,這樣的架構設計可以讓資料的處理更有效率,且大量的原始資料若存放在Datalake 則又可以降低營運成本。
但相對的,也有些負面的取捨如下:
在Scylla Blog上看到的Cassandra 4.0 vs Cassandra 3.11的相關測試文章,沒想到會去測試Cassandra不同版本間的效能比較,還蠻意外的XD
從測試的數據來看,Cassandra 4.0的效能幾乎在各個測試情境下,都比Cassandra 3.11要好不少,看起來平均有20-30%的效能改進;等之後有機會再看看是否有更多相關的測試數據出來XDD
在Hacker Daily News上看到的新資訊,美國的National Security Agency 與 Cybersecurity and Infrastructure Security Agency 出版的一個Kubernetes安全強化指南;雖然很久沒用kubernetes了,但對於這相關的資訊還是些記錄一下,以後說不定有機會用到。