Cassandra 4.0

在Scylla Blog上看到的Cassandra 4.0 vs Cassandra 3.11的相關測試文章,沒想到會去測試Cassandra不同版本間的效能比較,還蠻意外的XD

從測試的數據來看,Cassandra 4.0的效能幾乎在各個測試情境下,都比Cassandra 3.11要好不少,看起來平均有20-30%的效能改進;等之後有機會再看看是否有更多相關的測試數據出來XDD

reference:

PostgreSQL 上資料插入時產生的duplicate key conflict

事發經過

起因於最近工作上遇到的一個小插曲,剛好寫完某一個服務以後,發現某一個整合測試會在特定的情況下發生錯誤。

在經過一系列的測試以後,發現整合測試的錯誤只會發生在測試資料庫剛被初始化完成時;在進一步追下去發現,每次噴出來的錯誤訊息為 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重新對應上表的資料)

References

無所不在的SQL injection

一樣是在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是否有對應的處理方式。

reference

Cassandra用來刪table的指令

雖然說CQL很像SQL,但在Cassandra中,用來刪table指令也是有差異的,在stackoverflow上找到下面可以用下面的指令來刪除…

TRUNCATE keyspace_name.table_name;

或是用

TRUNCATE table_name;

值得注意的是,在stackoverflow中有提到,刪table前,Cassandra預設會先對要刪的table建立一分snapshot,所以有刪table的動作的話,可能要定時清理一下舊的snoapshot。

reference: