Tag: python

快速產生 SQLite 資料的方式：一分鐘內產生十億筆資料

在「Towards Inserting One Billion Rows in SQLite Under A Minute」這邊看到作者想要在一分鐘內在 MBP 2019 上面寫 1B 筆資料進 SQLite，裡面有些方法還蠻值得玩一下的，這台 MBP 2019 機器的規格是：

The machine I am using is MacBook Pro, 2019 (2.4 GHz Quad Core i5, 8GB, 256GB SSD, Big Sur 11.1)

第一版是 Python 寫的，塞 10M 筆花了 15 分鐘：

In this script, I tried to insert 10M rows, one by one, in a for loop. This version took close to 15 minutes, sparked my curiosity and made me explore further to reduce the time.

加了五個 PRAGMA 的版本變成 100M 筆十分鐘：

The naive for loop version took about 10 minutes to insert 100M rows.

用批次處理則可以降到八分半：

The batched version took about 8.5 minutes to insert 100M rows.

再來是拿經典神器 PyPy 出來用，降到兩分半：

All I had to do was run my existing code, without any change, using PyPy. It worked and the speed bump was phenomenal. The batched version took only 2.5 minutes to insert 100M rows. I got close to 3.5x speed :)

接下來就是跳槽到 Rust 了，中間也有不少 tuning 相關的討論，但直接先跳到最後面好了... 最後 100M 只用了 33 秒：

I created a threaded version, where I had one writer thread that received data from a channel and four other threads which pushed data to the channel. This is the current best version which took about 32.37 seconds.

能用 PyPy 的地方還是可以考慮一下的...

用 Python 的 DuckDB 下 SQL 指令翻 Parquet 的資料

在「Querying Parquet using DuckDB」這邊看到 DuckDB 這個東西，裡面引用的文章是「Querying Parquet with Precision using DuckDB」，可以直接對 Parquet 格式的資料下 SQL 找資料。

先前好像有看到 DuckDB 但沒有太注意，剛剛再次看到，然後玩了一下還蠻有趣的。DuckDB 支援蠻多程式語言與資料格式，不過這邊文章拿 Python 與 Parquet 玩還蠻有趣的...

先把 Parquet 的範例資料抓下來，然後透過 pip 裝 duckdb：

cd /tmp; wget https://github.com/cwida/duckdb-data/releases/download/v1.0/taxi_2019_04.parquet; pip install -U duckdb

然後進到 Python 3 的互動界面：

>>> import duckdb
>>> print(duckdb.query("SELECT COUNT(*) FROM 'taxi_2019_04.parquet' WHERE pickup_at BETWEEN '2019-04-15' AND '2019-04-20'").fetchall())
[(1276565,)]

然後在範例裡面，檔名的部份還可以用 *，看了一下說明，底層是 glob 類的用法：

DuckDB supports the globbing syntax, which allows it to query all three files simultaneously.

文章裡有提到速度比 Pandas 快很多，不過我覺得這好像不太能這樣比，會拿 Pandas 出來的時候常常是其他用法，但至少看起來速度是個 DuckDB 在意的點。

不過反而馬上想到的是，之後處理 CSV 之類的檔案應該也會試看看 DuckDB...

Django 3.2 LTS

Django 3.2 LTS 出了：「Django 3.2 released」，對應的 release note 可以在「Django 3.2 release notes」這邊看到。

這個版本比較特別，一般版本提供大約 15 個月的支援，LTS 版本則提供 36 個月的支援，不過目前用起來的感覺還是鼓勵大家平常就要安排升級計畫，不然 3.2 升級到 4.2 鐵定是個超痛苦的過程。

昨天把 Django 3.1 的專案升級上 3.2 後，跑 test case 就遇到「Customizing type of auto-created primary keys」這邊描述的問題，目前先用 DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' 解，其他的倒是沒什麼問題...

幾個我覺得有趣的，像是 JSONL 格式：

The new JSONL serializer allows using the JSON Lines format with dumpdata and loaddata. This can be useful for populating large databases because data is loaded line by line into memory, rather than being loaded all at once.

然後不支援 PostgreSQL 9.5 與 MySQL 5.6 了：

Upstream support for PostgreSQL 9.5 ends in February 2021. Django 3.2 supports PostgreSQL 9.6 and higher.

The end of upstream support for MySQL 5.6 is April 2021. Django 3.2 supports MySQL 5.7 and higher.

很久前寫 Django 1.x，然後就荒廢很久，最近是從 3.0 開始寫，有些東西熟一點以後覺得怪怪的，之後要找時間測一些東西，修正對 Django 的用法。

檔案壓縮順序造成壓縮率的差異

Hacker News Daily 上看到「Why are tar.xz files 15x smaller when using Python's tar library compared to macOS tar?」這篇，作者問了為什麼他用 Python 的 tarfile 壓出來比起用 tar 壓出來小了 15 倍，檔案都是 JSON 檔壓成 XZ 格式：

I'm compressing ~1.3 GB folders each filled with 1440 JSON files and find that there's a 15-fold difference between using the tar command on macOS or Raspbian 10 (Buster) and using Python's built-in tarfile library.

看到 1440 個檔案應該會有直覺是一分鐘一個檔案，跑一天的量...

隔天他把原因找出來了，在裝了 GNU Tar 並且加上 --sort='name' 參數後，壓出來的大小就跟 Python 的 tarfile 差不多了：

Ok, I think I found the issue: BSD tar and GNU tar without any sort options put the files in the archive in an undefined order.

After installing GNU tar on my Mac with:

brew install gnu-tar

And then tarring the same folder, but with the --sort option:

gtar --sort='name' -cJf zsh-archive-sorted.tar.xz /Users/user/Desktop/temp/tar/2021-03-11

I get a .tar.xz archive of 1.5 MB, equal to the archive created by the Python library.

底層的原因是檔名與檔案內容有正相關的相似度 (因為裡面都是 sensor 資料)，依照檔名排序壓縮就等於把類似的 JSON 檔案放在一起壓，使得 xz 可以利用這點急遽拉高壓縮率：

My JSON files contain measurements from hundreds of sensors. Every minute I read out all sensors, but only a few of these sensors have a different value from minute to minute.

By sorting the files by name (which has the creation unixtime at the beginning of it), two subsequent files have very little different characters between them. Apparently this is very favourable for the compression efficiency.

遇到類似的情境可以當作 tuning 的一種，測試看看會不會變小很多...

Raspberry Pi 推出 MCU 產品 Pico

Raspberry Pi 推出了新的產品線 Raspberry Pi Pico，基於 ARM 架構的 MCU (microcontroller unit)，Hacker News 上也有不少討論：「Raspberry Pi Pico and RP2040 Microcontroller (raspberrypi.org)」。

與 Raspberry Pi 的 Zero 系列比起來，Zero 上面有 512MB RAM，不算大但還是可以跑一個完整的 OS。而 Pico 的定位就直接是 MCU 了，基本上就是特製的系統。

再來是看 Pico 的規格，比隔壁棚的 ESP32 低一些，但可以看出來 Pico 主要的定位還是教學：高速雙核心 CPU、多腳位、大的記憶體以及 flash (對於一般量產的 MCU 來說)，支援透過 Micro-USB 的 5V 供電界面方便開發與使用。

官方支援 C 與 MicroPython 兩種開發使用的模式，其中在 Hacker News 上有人抱怨 MicroPython 哭爸慢，不過這點應該還好，要在上面跑比較複雜的人會自己跳到 C 上面開發。

最後來講價位，目前定價是每顆 USD$4，當然跟一般商用量產的 MCU 差不少 (會盡可能壓低到「剛好夠用」的等級，價錢就有可能低到 USD$0.x)，但相比於現在在教學上很紅的 ESP32 (大約在 USD$10 附近) 來說，等於是殺出另外一條產品線，加上挾帶著 Raspberry Pi 的知名度來說，等於是讓更多人熟悉 MCU...

一人團隊的技術架構

Hacker News Daily 上看到的文章，在講一人團隊時所設計的技術架構：「The Tech Stack of a One-Man SaaS」。這種資訊通常帶有個人偏好，維護成本算是蠻重要的重點，在多人團隊就未必會這樣選，但就拿著爆米花看戲的心態來說應該還 OK。

像是作者很明顯熟悉 Python，就可以看到他裡面會列出許多 Python 相關的 toolchain 與維護工具。

裡面比較有趣的是他對 DigitalOcean 的 K8S 問題很多抱怨了一番，然後換去 Linode 後又因為不想要自己管 PostgreSQL 而決定搬到 AWS 上面，可以用 RDS 省事... 花錢解決 XD

算是當短文小說在看...

日本郵政的 CSV 資料

看到「Parsing the Infamous Japanese Postal CSV」這篇在抱怨日本郵政提供的 CSV 資料超級糟糕的問題覺得頗「有趣」的，在 Hacker News 上也有人「同病相憐」XDDD：「Parsing the Infamous Japanese Postal CSV (dampfkraft.com)」。

文章作者是「posuto」這個套件的維護人，這個套件讓開發者可以很方便的在 Python 下從郵遞區號推出對應的地點資訊：

import posuto as 〒

? = 〒.get('〒105-0011')

print(?)
# "東京都港区芝公園"
print(?.prefecture)
# "東京都"
print(?.kana)
# "トウキョウトミナトクシバコウエン"
print(?.romaji)
# "Tokyo To, Minato Ku, Shibakoen"
print(?.note)
# None

作者建立的資料是從「読み仮名データの促音・拗音を小書きで表記するもの(zip形式)」這邊取得並且分析，然後這篇文章就是在描述這些 CSV 檔的資料裡面有超級多奇怪的例外，用機器讀取超哭爸的 XDDD (好像不怎麼意外？)

不過最有趣的應該還是他提到的這個：

Oh, and if you need a Win3.1 or DOS program to copy the data onto an IBM H floppy disk, just check the bottom of JP Post's page - they've got you covered.

看起來是頁面下方的這塊：

這就真的太哭爸了啊 XDDD

Python 3.9.0 以及 3.10.0a1

Python 3.9.0 出了：「Python 3.9.0 is now available, and you can already test 3.10.0a1!」。

下一個版本是 3.10 而非 Python 4：

OK, boring! Where is Python 4?

Not so fast! The next release after 3.9 will be 3.10. It will be an incremental improvement over 3.9, just as 3.9 was over 3.8, and so on.

在「What’s New In Python 3.9」裡面的「Optimizations」這段有測一些基本操作的效能，可以看到 Python 3.9 其實比 Python 3.8 慢了一些？好像也沒有提到原因就是了...

Facebook 放出 Pysa，靜態分析 Python 程式碼的工具

Facebook 丟出來的靜態分析工具，可以拿來分析 Python 程式碼：「Pysa: An open source static analysis tool to detect and prevent security issues in Python code」，專案在「facebook/pyre-check」這邊可以取得。

不過軟體居然是用 OCaml 寫的啊，另外已經包好了，可以用 pip 直接裝 pyre-check。

官方的說明裡面有提到要裝 watchman，不過這算是選擇性安裝，不裝 watchman 直接執行也可以用，只是會跳個訊息跟你說裝了可以遞增檢查：

To enable pyre incremental, you can install watchman: https://facebook.github.io/watchman/docs/install

最近在寫的專案都是用 Python，剛好可以拿來掃這些專案...

Django 3.1

看到「Django 3.1 Released」這邊的公告，比較完整的改變可以在「Django 3.1 release notes」這邊翻到。

這應該是第一次要把手上的專案跳 minor version 升級，看起來應該是還好，但天曉得會有什麼狀況... 看起來主要會是 sha1 要被換成 sha256 會有影響到。

另外看到這個：

SimpleTestCase now implements the debug() method to allow running a test without collecting the result and catching exceptions. This can be used to support running tests under a debugger.

看起來應該也蠻有用的，可以玩看看...