清晨六點半，鵬城科技園附近的老舊小區裡，林晨已經坐在電腦前兩個小時了。
窗外天色漸亮，遠處科技園玻璃幕牆反射出初升陽光的金色。屋內只有鍵盤敲擊聲和機箱風扇的低鳴。螢幕上，量化投資系統的監控面板正平穩執行，但林晨的目光卻鎖定在日誌區不斷滾動的一條警告資訊上：
“資料查詢延遲超過200，建議最佳化儲存結構”。
這是系統執行一週以來，第一次出現效能警告。
林晨端起已經涼掉的半杯咖啡，盯著那條警告看了很久。他知道問題出在哪裡——系統架構升級了，前端後端都現代化了，但資料儲存這一塊，還停留在“能用就行”的階段。
目前系統用的還是最簡單的SQLite資料庫，所有交易記錄、市場資料、指標計算結果都塞在同一個檔案裡。當資料量小的時候沒問題，但現在系統同時監控著A股三十多隻股票、基金、黃金ETF，每秒鐘要處理上百條即時行情，每天生成的交易日誌和指標資料已經超過十萬條。
“該給系統搭個像樣的資料庫架構了”。林晨自言自語道，聲音在安靜的房間裡顯得格外清晰。
他開啟一個新的思維導圖文件，在中央寫下“量化系統資料庫設計”。然後開始拆解需求。
第一類是結構化資料：交易記錄、賬戶資產變化、使用者配置引數。這些資料需要嚴格的事務支援，要保證每一筆交易記錄都準確無誤，不能丟失。這類資料最適合用傳統的關係型資料庫。
SQL。林晨在思維導圖上寫下這個選項。開源、穩定、社群成熟，他在之前的跨境電商專案裡用過很多次，熟悉得像老朋友。
第二類是時序資料：股價、成交量、技術指標值。這些資料的特點是時間戳是天然的主鍵，資料量巨大，寫入頻繁，查詢模式固定——基本都是按時間範圍查詢。用傳統關係型資料庫儲存這類資料，就像用貨櫃車運快遞，能運但效率太低。
InfluxDB。林晨寫下第二個選項。專門為時間序列資料設計的資料庫，寫入速度快，壓縮效率高，針對時間範圍查詢做了深度最佳化。這是他自學AI時接觸到的技術，當時用InfluxDB儲存神經網路訓練過程中的損失函式變化曲線，效果很好。
第三類是快取資料：即時行情、臨時計算結果、會話狀態。這些資料需要極快的讀寫速度，但可以容忍偶爾丟失，因為源頭資料還在。
Redis。第三個選項出現在思維導圖上。記憶體資料庫，讀寫速度能達到微秒級，是提升系統響應速度的利器。
“SQL存核心交易，InfluxDB存時序行情，Redis做快取加速”。林晨看著這個三層架構設計，點了點頭。
接下來的三天，林晨進入了沉浸式的編碼狀態。
每天早晨六點起床，七點開始工作，中午蘇婉會把午飯送到書房門口——自從父母要來鵬城的訊息確認後，蘇婉對他的支援更加細緻入微，彷彿在用行動告訴他：家裡有我，你專心做你的事。
林晨先攻SQL部分。他在阿里雲上申請了一個最基礎版的RDS例項，一個月不到兩百塊錢。然後開始設計表結構。
交易表需要記錄：交易ID、標的程式碼、買賣方向、數量、價格、手續費、交易時間、策略ID。他給交易時間欄位加了索引，這樣按時間查詢交易記錄會很快。
賬戶資產表需要記錄：每日收盤後的總資產、現金餘額、持倉市值、當日盈虧。這個表要保證每天只有一條記錄，用作長期資產走勢分析。
策略配置表、標的監控列表、風險規則表……林晨一邊設計一邊寫DDL語句，手指在鍵盤上飛舞。這些表之間的關係用外部索引鍵約束起來，確保資料一致性。
“建庫指令碼完成”。第三天上午十點，林晨執行了最後一個SQL檔案。SQL資料庫裡，十多個表整齊排列，索引建立完畢，初始資料也匯入完成。
接下來是InfluxDB。林晨在同一個雲賬號下開通了時序資料庫服務。這個的設計更簡單，因為InfluxDB不需要預定義表結構。
他建立了一個名為“rket_data”的儲存桶，然後開始規劃資料寫入格式。每條行情資料包含：測量名稱（如stock_price）、標籤（標的程式碼、市場型別）、欄位（開盤價、最高價、最低價、收盤價、成交量）、時間戳。
“寫入測試”。林晨寫了一段Python指令碼，模擬生成股價資料寫入InfluxDB。監控面板顯示，寫入速度穩定在每秒五千條以上，查詢最近一小時的行情資料，響應時間不到50毫秒。
“這才是專業的感覺”。林晨看著監控資料，嘴角上揚。
最後是Redis。他在雲伺服器上直接部署了Redis服務，配置了持久化策略——雖然快取資料可以丟失，但有些計算中間結果還是儲存下來比較好，避免重複計算。
快取設計是個細緻活。林晨規劃了幾個關鍵快取：
