Để cân nhắc thì sẽ cần đi từ tổng thể bài toán. Nếu cả hệ thống của bác update nhiều, chỉ có bảng password là ít update thì chúng ta cần ưu tiên cả hệ thống trước.
Vào vấn đề chính thì:
- Bác muốn tìm kiếm dữ liệu nhanh nhất có thể trong một bảng. Vậy thì bác có thể làm như sau:
1. Index. Chắc chắn rồi, 80% khi tối ưu tốc độ query thì chúng ta sẽ nghĩ đến index đầu tiên. Bác tạo index cho field mà bác cần tìm kiếm.
2. Partition. Hiểu đơn giản thì đây là kỹ thuật chia nhỏ table ra thành các phân vùng nhỏ, khi bác thực hiện câu lệnh Select thì engine của database sẽ chỉ cần thực hiện tìm kiếm trong một vùng dữ liệu nhỏ thay vì quét cả cái bảng dữ liệu rất là lớn.
3. Hash join. Bác đang tách username 1 bảng và password một bảng. Em không hiểu mục đích tại sao bác lại làm như vậy lắm, nhưng nếu để join hai bảng với nhau thì Hash join là một chiến lược tốt nếu bác muốn tăng tốc query. Đánh đổi là bộ nhớ sẽ tốn nhiều hơn.
4. Cache, buffer pool. Đây là kỹ thuật mà bác nên thực hiện đầu tiên. Table của bác có tần suất write siêu thấp, cache và buffer pool là một lựa chọn rất tốt khi muốn tăng tốc query.
Để lựa chọn database.
- Nếu bác nhiều tiền, oracle rất là ngon. Việc tối ưu partition và subpartition của oracle là không phải bàn cãi. Các thứ khác cũng rất ngon.
- Nếu không muốn tốn tiền thì PostgreSql cũng rất ngon. PostgreSql có một điểm mạnh khi thực hiện Select đó là nó sẽ tập hợp nhiều điều kiện để đánh giá và đưa ra được cách thực thi câu lệnh mà tốn ít tài nguyên nhất. Với câu lệnh select đơn giản thì điều này không khác biệt lắm khi so với mysql hay mssql nhưng nếu câu lệnh phức tạp thì chênh lệch là rất rõ ràng. Tuy nhiên thì kiến trúc của postgreSql khiến cho việc update dữ liệu sẽ kém hiệu quả hơn các database còn lại. Tất nhiên là nếu tần suất update dữ liệu cho cả hệ thống là thấp thì cũng không sao.
)
Ông warehouse join đc thì tốn kém ( Bigquery ) hoặc ác mộng maintain (Timescale, Clickhouse ... )
