Thiết kế hệ thống data report

Chào anh chị, mình đang cần thiết kế hệ thống với khoảng 100000req/s save , read data vào cảm postgres và mongo cho hệ thống report, đồng thời cũng đọc từ đó có khoảng 10m row thì thường anh chị xử lí kiểu gì cho đỡ load lock lâu ạ

1 Like

phải biết bạn cần làm gì với 10m row đó thì mới biết cần xử lý gì chứ
100k request/s là khoảng 8 tỷ request mỗi ngày
nếu hệ thống bạn cần tới mức đó, thì chắc chắc cũng không lên cái forum nhỏ này để hỏi rồi, kể cả trên này có chuyên gia đã xử được cái như vậy cũng không trả lời được vì câu hỏi quá chung chung

bớt nghĩ tới mấy cái xa xôi như này đi, kể cả bạn có nhận được một câu trả lời hoàn chỉnh, thì cũng không có nghĩa là bạn đã có kiến thức để giải quyết vấn đề này đâu

8 Likes

Đồng ý với ý kiến của @ kisuluoibieng , câu hỏi của bạn có thể xem là hỏi bâng quơ mà cũng ko hiểu mình hỏi gì!

Vài thông số để bạn dễ hình dung:

  • Đối với server bình thường thì có thể handle được khoảng 1000-2000 request per second.

  • Để có thể tăng hơn 2000 thì với một standalone server phải khũng hơn rất nhiều. Lên 100k là quá xa rời thực tế, nó phải cluster hoặc thứ gì đó tương tự.

  • 10 triệu records là quá bình thường đối với hệ thống hiện tại. Để dễ hình dung nó chỉ chiếm khoảng 1Gb-2Gb storage. Trong khi những database trung bình cũng phải vài mươi Gb, hệ thống lớn phải tính bằng Tb!

Giải pháp?

  • Cái này tùy vào database phục vụ cho mục đích gì, muốn “rất nhanh” thì cache database lên memory (aka. RAM), ít nhanh hơn chút thì Flash drive, phần ít dùng thì cho lên regular storage.
  • Đối với DB Postgres nói riêng và database nói chúng, để tăng khả năng phục vụ, chắc chắn phải nghĩ tới cái giải pháp Load-Balancing + High Availability (aka. scale out). I.e. Postgres streaming + Pgpool/Patroni.

Nói thêm là ko ai chạy report trên hệ thống với high-load (OLTP) như trên.

Vài ý kiến trao đổi, hy vọng bạn có được idea với hệ thống, dù tưởng tượng, vẫn bám sát thực tế chứ lên tới Cloud!

8 Likes

Mấy chủ đề như vầy Mod, Admin cần lưu ý, lưu lại vì có thể những “nhân tài” như này tương lai sẽ giống như 3 thým mà Microsoft vừa rồi kiện vì tạo 750 triệu tài khoản email.

2 Likes

Với câu hỏi này, bạn nên chủ động làm một cuộc meeting với team dự án +1 SA vào để phân tích xem project cần gì, dataflow như thế nào, tính năng report có gì đặc biệt. Từ đó mới vẽ ra được infrastructure, giải pháp để cho app chạy tốt với khối lượng data lớn, request nhiều

Lên đây hỏi thì khó tìm ra người giải đáp được. Mà nếu họ giải được thì nên cảm tạ người ta bằng một lời mời vào công ty của bạn với mức lương hậu hĩnh

3 Likes

Như mọi người đề cập ở trên, cậu cần cung cấp thêm thông tin để có thể có design phù hợp.
Design là công việc cần cân nhắc rất nhiều chi tiết để xem thứ gì có thể đánh đổi. Thế nên, thử cung cấp thêm các chi tiết dưới đây nhé!

  1. Trong 100k RPS đó, bao nhiêu % là read only? Bao nhiêu % là insert/update/delete?
    Và đó là estimate RPS trung bình, hay là peak?
  2. Đây là hệ thống gì? 1 batch chạy để tạo report, hay là 1 hệ thống REST API nhận request từ nhiều nguồn? Có ràng buộc gì về mặt thời gian cho hệ thống không?
  3. Ai là người dùng hệ thống report này? Report được tạo ra dưới dạng gì và chứa thông tin gì? Thời điểm nào người dùng cần report?
  4. Người dùng có cần tìm report trong quá khứ không? Nếu có, trong thời gian bao lâu người ta cần?
  5. Đâu là nguồn dữ liệu tới hệ thống? Và cách thức dữ liệu được đưa vào hệ thống ra sao?
  6. Mongo DB và PostgreSQL đóng vai trò gì ở đây?
  7. 10 mil row ở đâu? Đó là tổng row của cả DB hay là của 1 bảng nào đó thôi?
  8. “Load lock” là gì? :sweat:
2 Likes

Nếu ý bạn như sau:

  1. Thiết kế hệ thống data report với một tần suất cao của các yêu cầu (requests) đến 100,000 yêu cầu mỗi giây, bao gồm cả việc ghi (save) và đọc (read) dữ liệu từ cả hai hệ thống cơ sở dữ liệu là PostgreSQL và MongoDB.

  2. Còn mình đoán “load lock” trong câu hỏi của bạn có thể hiểu là vấn đề về hiệu suất khi có nhiều truy vấn hoặc thao tác ghi dữ liệu cùng một lúc, dẫn đến việc cơ sở dữ liệu phải xử lý các khóa (locks) và thời gian chờ (load time) tăng lên. Và bạn muốn biết cách xử lý tình trạng này để giảm thời gian chờ và đảm bảo rằng hệ thống có khả năng xử lý lớn và đồng đều.

Về vấn đề này thì mình thường thực hiện một số giải pháp: tối ưu hóa database bằng cách sử dụng indexing, partitioning, replication và sharding, cũng như tối ưu hóa truy vấn và sử dụng các kỹ thuật như caching, asynchronous processing, và connection pooling.
Mấy cái này nhằm mục đích: tăng hiệu suất hệ thống, giảm áp lực lên cơ sở dữ liệu, và đảm bảo khả năng mở rộng và đồng đều trong xử lý dữ liệu.

Lưu ý là đây là cách hiểu câu hỏi của bản thân mình, như theo @kisuluoibieng@csdl đã nói thì câu hỏi của bạn còn bâng quơ và bạn nên sửa lại câu hỏi hoặc cung cấp thêm thông tin mà mọi người cần thiết để trả lời câu hỏi của bạn!

1 Like

100,000 update/s và select ra từ 10,0000,000 records, phải hỏi là bạn update và select cái gì, 1 đoạn string 100 từ, hay 1 đoạn text dài tương đương 2 trang giấy A4, và câu query nó đơn giản hay phức tạp ra sao.

Mà hỏi thông tin sơ sài vậy, thì mình thấy giải pháp tốt nhất là tốn vài triệu đi mướn mấy ông chuyên làm database xử lý dùm cho, chắc ăn hơn.

P/s: còn không thì cứ chơi server max cấu hình nha, skills chưa cao thì mình bù đắp bằng tiền hoặc nhiều tiền.

4 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?