剛好工作上用到,記錄一下…. 這樣以後再用到時就只要稍微改一下相關的參數就好了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
從DK的blog上看到的分享工具 data-diff 後, 快速看了一下它的說明文件以後, 感覺這東西有需求的話應該會蠻不錯用的!
看起來可以比對多個data source的資料表, 而且預計支援的資料庫或相關服務也蠻多是市面上常見的… 蠻適合以後有需要時再來試看看.
看到DK的文章上提到這個功能覺得也太有趣了, 沒想到會有這麼簡單方式來從CSV檔中讀取想要的內容…
將sqlite3 透過memory的方式讀取了以後, 就可以透過SQL來找到其中想要的內容了…
sqlite3 :memory: -cmd '.mode csv' -cmd '.import mds_content_status.csv temp' -cmd '.mode column' 'SELECT * FROM temp'
為了讓使用方式更方便, 還可以在.bashrc
或 .zshrc
中把上面的cli 指令包裝成 shell function 如下:
function query_csv() {
local CSV_FILE=$1
local TABLE=$2
local QUERY=$3
sqlite3 :memory: -cmd '.headers on' -cmd '.mode csv' -cmd ".import ${CSV_FILE} ${TABLE}" -cmd '.mode column' "${QUERY}"
}
然後我們就可以用下面的方式去query了…
query_csv users.csv user_table 'SELECT id, name FROM user_table where id=17807'
網路上看到的一個Cassandra的簡易計算機,作者還有的提供原始碼在Github 上,所以如果有需要的話也可以自己fork一份自己架在自己的網頁上。
這個計算機的功能也很簡單,主要是提供使用者可以快速顯示在不同的cluster狀態下,根據keyspace的read/write 設定對於叢集的影響,像是:
在Scylla Blog上看到的Cassandra 4.0 vs Cassandra 3.11的相關測試文章,沒想到會去測試Cassandra不同版本間的效能比較,還蠻意外的XD
從測試的數據來看,Cassandra 4.0的效能幾乎在各個測試情境下,都比Cassandra 3.11要好不少,看起來平均有20-30%的效能改進;等之後有機會再看看是否有更多相關的測試數據出來XDD
起因於最近工作上遇到的一個小插曲,剛好寫完某一個服務以後,發現某一個整合測試會在特定的情況下發生錯誤。
在經過一系列的測試以後,發現整合測試的錯誤只會發生在測試資料庫剛被初始化完成時;在進一步追下去發現,每次噴出來的錯誤訊息為 ERROR: duplicate key value violates unique constraint "files_pkey"
,這個錯誤其實蠻奇妙的,因為這張表的id
我是讓其內部自動產生的(auto increment),但在資料庫執行一段時間以後,發現同樣的測試又可以pass了。
最後追下去發現stckoverflow上,其它人也有遇到類似的問題,照著答案中的方向去試了以後就順利解決了。
在PostgreSQL中,如果我們設定primary key 為serial
or bigserial
時,PostgreSQL內部會產生一組relation
用來管理對應的primary key 其下一組資料寫入時,auto increment 後的值為何。
由於我在產生測試資料時是有包含id
的值,所以造成對應的那張表的id sequence誤判了當新的一筆資料要再被寫入時對應的id
值,但再過了一段時間以後,PostgreSQL內部又會重新sync id sequence
,所以才會有資料庫運行一段時間後,測試又可以通過了的情況。
最後的解決方案就是重新整理測試資料,讓其不包含id
,所以那張表的id
的管理就完全由其資料庫內部來作,自然就解決了id sequence out of sync
的問題了。
(stackoverflow 文章中有另外提到其它手動的方式,來讓 primary key sequence
重新對應上表的資料)
一樣是在Hacker Daily News上看到的一篇文章,作者說明了他在google上找到了30個關於php + email 註冊 的相關教學文章,發現其中的16筆是有SQL injection 的風險。
趁這個機會再來複習一下SQL Injection, 畢境這是非常常見的攻擊之 一;主要的攻擊手段是將一段有害的字串,透過網頁輸入的方式傳送至伺服器上,而伺服器的程式在沒有做任何檢查的情況下,就帶入網頁送上來的那些參數並執行了特定的SQL而造成問題。
從oswap上看到的一個典型的範例是,讓使用者在網頁端填入firstname與 lastname,然後伺服器這邊就透過使用者給的資訊來去資料庫找對應的使用者資訊,若此時使用者給的是像這樣的資訊
Firstname: evil'ex
and Lastname: Newman
且執行的SQL可能會是長這樣, 其造成的問題就是會讓資料庫試著去執行evil
指令而失敗
select id, firstname, lastname from authors where firstname = 'evil'ex' and lastname ='newman'
事實上,還有更多網路上可以找到的攻擊範例,而解決方式就是在伺服器這邊需要針對使用者傳上來的資訊做更多的驗證,之後才可以使用。
另外,一些常見的web framework通常都會將這些驗證自動套用到程式中,所以如果我們有使用web framework的話,也可以看一下所使用的framework是否有對應的處理方式。
雖然說CQL很像SQL,但在Cassandra中,用來刪table指令也是有差異的,在stackoverflow上找到下面可以用下面的指令來刪除…
TRUNCATE keyspace_name.table_name;
或是用
TRUNCATE table_name;
值得注意的是,在stackoverflow中有提到,刪table前,Cassandra預設會先對要刪的table建立一分snapshot,所以有刪table的動作的話,可能要定時清理一下舊的snoapshot。