一、Redis 和 CPU 的基本關係 多數人認為 Redis 性能僅與 CPU 快慢有關，其實 CPU 的「多核架構」與「多 CPU 架構」也會影響 Redis 效能。 二、主流的 CPU 架構 1. CPU 核心與快取層級 每個 CPU 處理器有多個物理核心，每個核心擁有私有的 L1 與 L2 cache。 L3 cache 為共享緩存，各物理核心可共用，容量大但速度較慢。 兩個超執行緒（邏輯核心）共用一個物理核心的 L1/L2 cache。 CleanShot 2025-06-26 at 13.08.44@2x

時間序列數據（Time Series Data） 時間序列數據（Time Series Data）是依時間先後順序排列的數據集合，通常用來表示某個變數隨時間變化的情況。 特點： 時間順序重要 數據點具備時間戳（例如：每天的氣溫、每分鐘的股價） 常用於分析趨勢、季節性、異常等 常見應用：

先跟你分享一個我曾經遇到的需求。 當時，我們要開發一個圖片存儲系統，要求這個系統能快速地記錄圖片 ID 和圖片在存儲系統中保存時的 ID（可以直接叫作圖片存儲對象 ID）。同時，還要能夠根據圖片 ID 快速查找到圖片存儲對象 ID。 photo_id: 1101000051photo_obj_id: 3301000051 127.0.0.1:6379> set 1101000051 3301000051 我們保存了 1 億張圖片，大約用了 6.4GB 的內存。但是，隨著圖片數據量的不斷增加，我們的 Redis 內存使用量也在增加，結果就遇到了大內存 Redis 實例因為生成 RDB 而響應變慢的問題

打開 Message API Webhook 功能 進入 Line Office Account，在帳號一覽選擇你要設定的 Official Account 設定 > 回應設定 > 打開「聊天」跟「Webhook」功能 image 設定 > Messaging API > 啟用 Messaging API 選擇服務提供者 > 選擇你的帳號

複雜性是規模擴展的大敵 你知道的，程式碼越簡單越好 如果真的無法消除複雜性，那就把它隔離開來 一個簡單的範例 譬如說要計算 sin 的時候，我們只要直接去呼叫 sin 函數就好而不用去管內部的實作 實際上計算 sin 的實作非常的複雜，但是因為他的介面簡單，所以我們用起來也不會很複雜 隱藏內部的細節 v1

如何消除掉那種實際上可以避免的狀況(或者說是「使用上的錯誤」，像是在關閉檔案之後又想要寫入檔案，或是在物件完成初始化之前就去調用那個物件裡的方法) 設計出不容易誤用的程式（介面） 比如說，你寫了某個函式，其中有兩個參數是陣列值，或許你會希望這兩個陣列，總是具有相同的大小 void showAuthorRoyalties( const vector<string> & titles, const vector<double> & royalties) { assert(titles.size() == royalties.size());

大部分情況下，我們會傾向找出更通用的做法 譬如以下的例子 Sign * findRedSign(const vector<Sign *> & signs) { for (Sign * sign : signs) if (sign->color() == Color::Red) return sign;

11.1 將兩個查詢結果聯集的 UNION 使用UNION 關鍵字可以將兩個查詢的結果做聯集，只要兩者的欄位資料型別、欄位數與欄位排列順序相同即可。 用 UNION 聯集只保留不重複的列資料 聯集的意思就是將兩個集合中的所有元素放在一起，並將重複的元素只保留一個。 我們用兩個SELECT 語句分別查出市集年份是2019與2020年的首次市集日期，然後將這兩個查詢的輸出結果合併起來。因為第一個查詢與第二個查詢的輸出不重複，都會被放進聯集的輸出中： SELECT market_year, MIN(market_date) AS first_market_date FROM farmers_market.market_date_info

如果我們是第一次接觸到這個資料庫時，在做查詢與分析之前，就需要瞭解他的結構與特性。 EDA: 探索性資料分析 9.1 EDA 準備要探索的標的 我們需要透過 SQL 查詢瞭解表格的資料樣貌，包括以下幾件事情： 表格多大？ 資料的時間跨度？ 每個產品與每筆購買記錄中有哪些可用資訊？

利用窗口函數 ROW_NUMBER 取得每個供應商最高價的產品 依據前面所學，我們可以利用 MAX() + GROPU BY 取得每個供應商最高價的產品的價格 SELECT vendor_id, MAX(original_price) AS highest_price FROM vendor_inventory GROUP BY vendor_id ORDER BY vendor_id image

LEFT JOIN CleanShot 2024-01-24 at 16.16.24@2x LEFT JOIN 是以左表格作爲主表格，右表格則是從表格 product_category 1->* product_category SELECT * FROM product LEFT JOIN product_category

MySQL Workbench Community Edition https://dev.mysql.com/downloads/workbench/ MySQL Workbench Community Edition 8.0.34 在 MacOS 14.2.1 一直當掉，不推薦使用 推薦使用 https://github.com/Sequel-Ace/Sequel-Ace 雖然功能比較少，但還滿穩定的 關聯式資料庫 一對多

11-2 使用函式建構子 跳過 11-3 使用類別 interface Person { id: string name: string city: string }

7-2-1 JS 動態型別 擁有型別的是值本身，而不是變數 let myVar; console.log(`${myVar} = ${typeof myVar}`) myVar = 12; console.log(`${myVar} = ${typeof myVar}`) myVar = 'Hello'; console.log(`${myVar} = ${typeof myVar}`) myVar = true;

The knapsack problem The simple solution Dynamic programming ruby code require 'terminal-table' products = {

Hash functions hash table = hash function + array there are some requirements for a hash function: It needs to be consistent. For example, suppose you put in “apple” and get back “4”. Every time you put in “apple”, you should get “4” back. It should map different words to different numbers. For example, a hash function is no good if it always returns “1” for any word you put in. In the best case, every different word should map to a different

Binary search Binary search is an algorithm; its input is a sorted list of elements example Algorithm running times grow at different rates Big O establishes a worst-case run time Q: Suppose you’re using simple search to look for a person in the phone book. In this case, you’re looking for Adit. This guy is the first entry in your phone book. So you didn’t have to look at every entry—you found it on the first try. Did this algorithm take O(n) time? Or did it take O(1) time because you found the person on the first try?

There’s a bug! (after optimization) Identify actions: Step 1 Draw each action: Step 2 Simplify the diagram: Step 3 JavaScript threading model simplification steps All actions on a single timeline go into a single box. Consolidate timelines that end by creating one new timeline.

The customer communications team continues Requirement: Filter for only good customers (three or more purchases). Map those to their biggest purchases. version 1 version 2

recap Pattern 1: Straightforward implementation Pattern 2: Abstraction barrier Abstraction barriers hide implementations Ignoring details is symmetrical marketing team => don't care the details of the implementation dev team => don't care how marketing team uses the functions