| FILTER mới là nơi database bắt đầu có giá trị: đừng chỉ `SELECT *`

Được viết bởi thanhdt vào ngày 25/05/2026 lúc 23:07 | 52 lượt xem

Code bám theo: Phu dao 5.2_Crypto Day du lieu ve PostgreSQL (20 nam).ipynb

Notebook đang dừng ở bước đọc lại dữ liệu bằng SELECT *. Về mặt học thuật thì ổn. Nhưng về mặt hệ thống, giá trị thật của PostgreSQL chỉ xuất hiện khi bạn biết FILTER đúng chỗ.

Sau khi dữ liệu đã được chuẩn hóa thành các cột:
Symbol
Datetime
Open
High
Low
Close
Volume
Timeframe

thì bước tự nhiên tiếp theo không phải là cứ đọc cả bảng lên rồi mới xử lý bằng tay. Bước đúng hơn là:
lọc ngay từ database.

Ví dụ, thay vì:
python
query = f"SELECT * FROM {schema}.trading_data_crypto"
data = pd.read_sql(query, con=engine)

ta nên nghĩ theo kiểu:
– chỉ lấy ETHUSDT
– chỉ lấy 1d
– chỉ lấy giai đoạn 2020-01-01 tới 2024-12-31

Ví dụ logic filter:
sql
SELECT *
FROM public.trading_data_crypto
WHERE Symbol = 'ETHUSDT'
AND Timeframe = '1d'
AND Datetime >= '2020-01-01'
AND Datetime < '2025-01-01'
ORDER BY Datetime;

Vì sao FILTER quan trọng về mặt kỹ thuật?

1. Giảm tải RAM cho Python
Nếu bảng ngày càng lớn, SELECT * sẽ kéo tất cả lên notebook. Database đáng ra phải làm phần lọc nặng trước, rồi Python mới xử lý phần còn lại.

2. Tăng tốc workflow phân tích
Thay vì load cả kho rồi mới lọc bằng pandas, bạn lấy đúng lát dữ liệu cần cho:
– chart
– backtest
– dashboard
– signal research

3. Giữ flow dữ liệu sạch hơn
Khi WHERE nằm trong query, logic “mình đang phân tích cái gì” được nói rất rõ:
– symbol nào
– timeframe nào
– khoảng thời gian nào

4. Dễ tách thành hàm dùng lại
Sau này bạn có thể viết:
get_data(symbol, timeframe, from_date, to_date)
và để lớp database làm việc lọc phía sau

Flow kỹ thuật tóm tắt

text
PostgreSQL table
-> WHERE Symbol / Timeframe / Datetime
-> dataset nhỏ hơn, đúng hơn
-> pd.read_sql()
-> chart / strategy / backtest

Insight kỹ thuật đáng nói

Database không có giá trị lớn chỉ vì “lưu được dữ liệu”. Giá trị thật nằm ở chỗ:
lọc được đúng phần dữ liệu cần dùng, đúng lúc, với chi phí thấp hơn việc kéo cả bảng lên Python.

Pitfall kỹ thuật

  • SELECT * ở giai đoạn học là ổn, nhưng giữ thói quen đó khi dataset lớn sẽ rất tốn tài nguyên
  • Nếu không filter theo Timeframe, cùng một symbol nhưng khác timeframe có thể bị trộn
  • Nếu không filter theo Datetime, chart/backtest rất dễ đọc thừa giai đoạn không liên quan
  • Nếu sau này thêm nhiều symbol mà không filter theo Symbol, dataset đọc lên sẽ mất kiểm soát rất nhanh

Góc nhìn trader thực chiến: khi bạn đã có PostgreSQL, bài toán không còn là “lưu dữ liệu được chưa”. Bài toán là “lấy đúng lát dữ liệu nào để phục vụ quyết định nhanh và chính xác hơn”. Đó chính là tư duy FILTER.

Comment FILTER nếu bạn muốn mình viết tiếp bộ query mẫu cho crypto theo Symbol + Timeframe + Datetime.

Bài viết chia sẻ góc nhìn kỹ thuật và vận hành dữ liệu, không phải khuyến nghị đầu tư.

| Kết nối PostgreSQL trong notebook này đang đi theo flow nào?

Được viết bởi thanhdt vào ngày 25/05/2026 lúc 23:07 | 48 lượt xem

Code bám theo: Phu dao 5.2_Crypto Day du lieu ve PostgreSQL (20 nam).ipynb

Nếu bài 1 nói về vai trò của SQLAlchemy, thì bài 2 phải nói thẳng về flow kết nối: dữ liệu đi từ đâu, chuỗi kết nối được tạo thế nào, engine sinh ra để làm gì, và notebook đang đọc/ghi PostgreSQL theo đúng thứ tự ra sao.

Trong notebook này, phần kết nối PostgreSQL đi theo trình tự rất rõ:

Bước 1: khai báo thông tin kết nối
python
user = 'admin'
password = '1'
host = 'localhost'
port = '5432'
database = 'DataBTC'

Đây là 5 mảnh ghép tối thiểu để Python biết:
– đăng nhập bằng ai
– vào máy nào
– qua cổng nào
– truy cập database nào

Bước 2: tạo chuỗi kết nối
python
connection_string = f"postgresql+psycopg2://{user}:{password}@{host}:{port}/{database}"

Chuỗi này rất đáng để người mới hiểu kỹ:
postgresql = dialect database
psycopg2 = driver
user:password = thông tin xác thực
host:port/database = địa chỉ và tên DB

Bước 3: tạo engine
python
engine = sqlalchemy.create_engine(connection_string)

engine là object trung tâm để:
– ghi dữ liệu với to_sql
– đọc dữ liệu với read_sql

Nghĩa là thay vì mỗi lần đọc/ghi lại viết logic kết nối từ đầu, notebook tạo ra một “cổng giao tiếp chuẩn” rồi dùng lại.

Bước 4: xác định bảng và schema
python
table_name = 'trading_data_crypto'
schema_name = 'public'

Đây là bước nhiều người mới hay bỏ qua. Không phải cứ kết nối DB là xong. Bạn còn phải xác định:
– ghi vào bảng nào
– bảng đó nằm trong schema nào

Bước 5: ghi dữ liệu
python
data.to_sql(table_name, con=engine, if_exists='append', index=False, schema=schema_name)

Notebook dùng append, nghĩa là:
– bảng vẫn giữ nguyên
– dữ liệu mới được nối thêm vào bảng hiện có

Bước 6: đọc dữ liệu ngược lại
Ở nửa sau notebook:
python
query = f"SELECT * FROM {schema}.trading_data_crypto"
data = pd.read_sql(query, con=engine)

Đây là bước rất quan trọng vì nó chứng minh pipeline không dừng ở chỗ “ghi được”. Nó còn kiểm tra:
– đọc lại có được không
– schema có đúng không
– dữ liệu trong DB có giữ đúng cấu trúc DataFrame mong muốn không

Flow kỹ thuật tóm tắt

text
user/password/host/port/database
-> connection_string
-> create_engine()
-> table + schema
-> to_sql(append)
-> read_sql(SELECT ...)

Insight kỹ thuật đáng nói

Kết nối database không phải một thao tác đơn lẻ. Nó là một flow hai chiều:
– ghi xuống được
– và đọc ngược lên được

Nếu chỉ to_sql() thành công mà read_sql() không ổn, hệ thống dữ liệu vẫn chưa hoàn chỉnh.

Pitfall kỹ thuật

  • Notebook đang hardcode user/password, cách này học thì dễ nhưng deploy thật thì không nên
  • Dùng append mà không có cơ chế deduplicate sẽ rất dễ nhân đôi dữ liệu
  • Tên bảng/schema đúng nhưng quyền user không đủ thì vẫn fail ở bước ghi
  • Dữ liệu crypto có thể không thật sự đủ “20 năm” vì tuổi đời symbol trên sàn không đủ dài, nên query dài năm không có nghĩa là DB có dữ liệu từ ngày bạn mong muốn

Góc nhìn trader thực chiến: phần kết nối PostgreSQL là nền hạ tầng. Không có lớp này, dữ liệu chỉ là thứ chạy qua notebook rồi biến mất. Có lớp này, dữ liệu bắt đầu trở thành tài sản có thể lưu, truy vấn, lọc và dùng lại cho backtest hoặc chiến lược sau này.

Comment CONNECT nếu bạn muốn mình viết tiếp checklist kiểm tra kết nối PostgreSQL trước khi đẩy data thật.

Bài viết chia sẻ góc nhìn kỹ thuật và vận hành dữ liệu, không phải khuyến nghị đầu tư.

| SQLAlchemy thực ra đang làm gì trong flow `DataFrame -> PostgreSQL`?

Được viết bởi thanhdt vào ngày 25/05/2026 lúc 23:07 | 50 lượt xem

Code bám theo: Phu dao 5.2_Crypto Day du lieu ve PostgreSQL (20 nam).ipynb

Nhiều người mới học Python Database nhìn thấy sqlalchemy.create_engine(...) rồi nghĩ đây chỉ là “một dòng code kết nối database”. Thực ra trong flow của notebook này, SQLAlchemy đang giữ vai trò là lớp trung gian cực quan trọng giữa pandasPostgreSQL.

Nếu tách notebook ra theo từng lớp kỹ thuật, ta sẽ thấy:

Lớp 1: lấy dữ liệu từ Binance
Hàm loaddataBinance_FromTo_Split() dùng ccxt để kéo OHLCV, sau đó đưa về DataFrame với các cột:
Timestamp
Open
High
Low
Close
Volume

Tiếp theo code đổi Timestamp sang Datetime, rồi thêm:
Symbol
Timeframe

Cuối cùng DataFrame được chuẩn hóa lại thành:
Symbol, Datetime, Open, High, Low, Close, Volume, Timeframe

Lớp 2: SQLAlchemy đứng giữa DataFrame và PostgreSQL
Đây là lúc notebook dùng:
python
connection_string = f"postgresql+psycopg2://{user}:{password}@{host}:{port}/{database}"
engine = sqlalchemy.create_engine(connection_string)

Ở đây có 3 lớp thư viện đang phối hợp:
pandas: giữ dữ liệu dạng bảng
sqlalchemy: tạo engine, quản lý dialect kết nối
psycopg2: driver thật sự nói chuyện với PostgreSQL

Nói ngắn gọn:
pandas biết dữ liệu là gì
SQLAlchemy biết gửi dữ liệu đi qua cổng nào
psycopg2 là người lái xe đi tới PostgreSQL

Lớp 3: đẩy bảng vào database
Notebook dùng:
python
data.to_sql(table_name, con=engine, if_exists='append', index=False, schema=schema_name)

Dòng này có nghĩa:
– lấy toàn bộ DataFrame
– map cột của pandas sang cột bảng SQL
– append dữ liệu vào bảng public.trading_data_crypto

Flow kỹ thuật tóm tắt

text
ccxt -> DataFrame OHLCV
-> thêm Datetime / Symbol / Timeframe
-> SQLAlchemy engine
-> psycopg2 driver
-> PostgreSQL table

Insight kỹ thuật đáng nói

Điểm mạnh nhất của SQLAlchemy trong flow này không phải “kết nối được”, mà là nó tạo ra một interface đủ chuẩn để:
pandas.to_sql() ghi dữ liệu
pandas.read_sql() đọc dữ liệu ngược lại
– và sau này có thể đổi chiến lược đọc/ghi mà không phải đập toàn bộ pipeline

Pitfall kỹ thuật

  • Nhiều người tưởng chỉ cần có SQLAlchemy là đủ, nhưng thiếu driver psycopg2 thì PostgreSQL vẫn không nói chuyện được
  • to_sql(..., if_exists='append') rất tiện, nhưng nếu không có khóa chống trùng thì dữ liệu có thể bị append lặp
  • Cột thời gian nếu không chuẩn hóa trước khi đẩy xuống DB sẽ gây rối ở bước query sau này

Góc nhìn trader thực chiến: trong hệ thống data cho Auto Trading, SQLAlchemy không phải phần phụ. Nó là lớp giúp DataFrame rời khỏi notebook tạm thời và bước vào một kho dữ liệu có thể truy vấn lại, lọc lại và tái sử dụng về sau.

Comment SQLA nếu bạn muốn mình viết tiếp bài riêng về pandas + sqlalchemy + psycopg2 nên chia vai thế nào trong hệ thống dữ liệu.

Bài viết chia sẻ góc nhìn kỹ thuật và vận hành dữ liệu, không phải khuyến nghị đầu tư.