thắc mắc Cách thiết kế database cho hệ thống lớn

buiduchanh1995

buiduchanh1995

Senior Member
E chào các bác. Chả là em có một issue như thế này muốn tham khảo ý kiến các bác.

Hiện tại e đang làm về mảng AI vào đang thiết kế 1 hệ thống liên quan đến giao thông. Bài toán cụ thể thì với camera giao thông thì db của em đang lưu các thứ sau :
  • Config của các camera ( thông tin camera, vms, địa điểm )
  • Collection lưu lại các dữ liệu dạng tracing, violation

Vấn đề ở collection tracing/violation thì thực ra là thông tin của từng phương tiện trên từng tuyến đường ( loại xe, màu xe, biển số v..v) nhưng như các bác đã biết thì số lượng phương tiện rất nhiều -> số lượng record cho tracing sẽ tăng rất nhiều -> như e dự kiến thì 1 ngày sẽ có khoảng tầm 50-60k bản ghi/ 1 cam/ 1 ngày. Số lượng cam của bên em thì cứ tính trung bình khoảng đơn vị nghìn cam/ 1 location => 50-60M bản ghi 1 ngày và thường dữ liệu phải lưu ít nhất là 3 tháng gần nhất => số lượng record lưu trữ khoảng 50M x 90 = 4B5 bản ghi

Hiện tại hệ thống thì đang sử dụng mongodb cho việc lưu trữ tát cả nhưng khi query thì khá chậm. Các bác có thể cho em lời khuyên về thiết kế database cho bài toán trên dể tối ưu đọc/ghi với ạ.

Em cảm ơn các bác.
 
Config thì cứ lưu theo mongodb, chia theo partitions theo đơn vị
Collection là timeseries có thể lưu theo đơn vị, rồi partitions ra -> nếu mà k OLTP thì suggest là đẩy dữ liệu đó qua object storage như s3 rồi chia partitions theo ngày, giờ sẽ save cost rất nhiều, mà tốc độ truy vấn nhanh
 
vẫn giữ con mongo, nhưng chỉ lưu data 1 ngày / 1 tuần, sync cái collection đó sang mấy cái big data server trong này đã đề cập

code cũ ko đổi phần save mà chỉ code lại phần query là từ big data

// mấy cái big data server kia quản trị khoai phết, cài đặt cũng khó hơn mongo nhiều, ko may có vấn đề thì vẫn giữ được phần save, mất phần query thôi
 
Dùng scylladb thôi. Scylla viết dựa trên Cassandra (Viết bằng java) bằng C++ nên nhanh hơn cassandra với cùng hardware + async tốt hơn
 
khonganhit19 said:
chuyển sang dùng cassandra nhé, hoặc scylladb
Nhưng mức data như kia thì nên dùng cassandra cho dễ tìm tài liệu tham khảo
Click to expand...
CzeK said:
Recommend scylladb, discord trước cũng dùng cassandra nhưng sau này migrate qua scylla.
Có thể đọc thêm tại đây: How Discord Stores Trillions of Messages (https://discord.com/blog/how-discord-stores-trillions-of-messages)
Click to expand...
Em cảm ơn 2 bác, e chưa dùng 2 db trên nên em sẽ thử tìm hiểu xem thế nào ạ. Chủ yếu em muốn tốc độ ghi ổn vì ghi thì nhiều hơn đọc. Việc đọc thì xuất hiện phía end user nên tần suất sẽ không nhiều được như ghi, kiểu người dùng sẽ search các dữ liệu cách đó khoảng 1 tháng -> e cần phần query đủ nhanh để đáp ứng việc đấy
icecreamhot said:
shading chia bảng ra theo location or cam
vẫn to thì partitioning table theo time.
cái dễ của data này là nó độc lập nhau
Click to expand...
việc chia theo location thì e cũng tính đến rồi nhưng thế thì tương đối nhiều bảng nên hướng hiện tại em đang tìm giải pháp dạng dùng bảng chung á bác. Nếu tệ quá thì e sẽ chia nhỏ lại theo location ạ
DareDevil.a.k.MattMurdock said:
Config thì cứ lưu theo mongodb, chia theo partitions theo đơn vị
Collection là timeseries có thể lưu theo đơn vị, rồi partitions ra -> nếu mà k OLTP thì suggest là đẩy dữ liệu đó qua object storage như s3 rồi chia partitions theo ngày, giờ sẽ save cost rất nhiều, mà tốc độ truy vấn nhanh
Click to expand...
dạ bên em deploy on-premise nên không được connect internet á bác :D
 
Về cơ bản thì việc save lại thì chắc không vấn đề gì vì thực ra các dữ liệu là độc lập. Hiện tại vấnd dề chính của em là cái data đó nó bao gồm vài field dạng : Địa điểm, Thời gian, biển số xe, màu xe, loại xe v..v để phục vụ việc filter dữ liệu

Kiểu filter cho user dữ liệu tại multi location với thời gian từ 01-01-2024 7:00:00 đến 29-01-2024 15:30:00 với các xe sedan màu đỏ. Việc query như vậy với dữ liệu lớn thì bên e respone ra khá chậm nên e cũng muốn cải thiện phần đó ạ
 
Payload của 1 document dữ liệu không lớn.
Write nhiều/Read ít.
Trích xuất bắt buộc trên time và location (mấy field khác là optional).
Tổng dữ liệu khoảng 10 tỉ.

Theo ý của mình bạn nên thử optimize cái mongodb trước xem sao thay vì thay đổi database mà chưa thử nghiệm/có kinh nghiệm làm việc với database mới là thật sự không nên (góc nhìn của mình).

Bạn thử scale thêm cái MongoDb xem sao. Dữ liệu nhiều như vậy thì phần cứng cũng phải tương ứng. Bạn không ghi rõ cái MongoDb Cluster hiện tại của bạn bao nhiêu node? Ram bao nhiêu? Cpu thế nào? Đã nhận diện được các query nào chậm chưa? Query Profiler đã làm chưa?
Ngoài ra, tìm hiểu cách đánh index dựa trên time và geolocation trên MongoDb thế nào?

Các Db khác có thể nhanh hơn, nhưng mình nghĩ không có cải thiện được nhiều đâu. Nếu một db mà "nhanh kinh khủng" hơn các database còn lại thì giờ nó đã chiếm hết thị trường rồi.

Cái database đáng ra phải lựa chọn trước khi bắt đầu dự án chứ giờ đổi kéo theo nhiều thứ lắm. Có thể làm trễ tiến độ lắm luôn, cẩn thận trước khi làm. Còn nếu muốn đổi phải có thử nghiệm, roadmap, rồi so sánh chán chê còn chưa làm nữa, vì nó tốn nhiều thời gian và công sức tiền của.
 
DareDevil.a.k.MattMurdock said:
Nếu là on-premise, append-only, query filter nhiều thì 1 vote cho OLAP SQL nhá, cụ thể là timescale. Còn nếu aggregation nhiều thì 1 vote cho clickhouse
Click to expand...
bài của thớt dùng Timescale k ổn áp lắm, write throughput lớn và nếu tôi hiểu đúng là multiple device write cùng lúc vào db sink -> lúc này sink mà là dạng single node thì tải hệ thống + IO phải đề phòng. Thêm nữa 3 tháng ~4,5b records, thì mấy con như Timescale lưu được mấy tháng, chưa kể ngoài những cột thớt liệt kê thì k biết còn bao nhiêu metric camera đẩy ra (có thể nhiều cột).
=> +1 vote Cassandra khắc phục các yếu tố kể trên, bao gồm cả việc scale hệ thống trong tương lai khi thêm nhiều camera/location.
Bây giờ bài toán là chọn partition key, second index thì phải phụ thuộc vào use case cụ thể của thớt.

P/s: tôi vote Cassandra thay vì Scylla là bởi vì tôi đoán thớt làm ở tổ chức dạng nhà nước/private infra. Kinh nghiệm mà tôi trải qua thì deploy mấy con JVM base + cộng đồng lớn nó dễ chịu hơn nhiều từ lúc setup cho đến lúc khắc phục nếu có issues.
 
Last edited:
4B5 bản ghi thì mình khuyên nên ghi bằng HDFS, ghi bằng file, chia location theo ngày. Lúc nào cần thì chọc vào file đọc lên cho nhanh. Chứ lưu vào DB cũng không tối ưu lắm.
Dữ liệu trong 1 tuần thì ghi vào Oracle cũng được. Chia partition theo ngày, đánh index cẩn thận chắc là ổn.
 
Mấy bài toán dạng này bạn có thể tìm hiểu các hệ thống data warehouse, data warehouse được thiết kế chuyên phục vụ mục đích query lượng dữ liệu lớn. Gần đây mình nghe khá nhiều người khen Clickhouse, thậm chí có người xử lý 500B bản ghi chỉ sử dụng 1 máy NUC ClickHouse Cost-Efficiency in Action: Analyzing 500 Billion Rows on an Intel NUC (https://altinity.com/blog/2020-1-1-clickhouse-cost-efficiency-in-action-analyzing-500-billion-rows-on-an-intel-nuc).
 
4nh7i3m said:
Payload của 1 document dữ liệu không lớn.
Write nhiều/Read ít.
Trích xuất bắt buộc trên time và location (mấy field khác là optional).
Tổng dữ liệu khoảng 10 tỉ.

Theo ý của mình bạn nên thử optimize cái mongodb trước xem sao thay vì thay đổi database mà chưa thử nghiệm/có kinh nghiệm làm việc với database mới là thật sự không nên (góc nhìn của mình).

Bạn thử scale thêm cái MongoDb xem sao. Dữ liệu nhiều như vậy thì phần cứng cũng phải tương ứng. Bạn không ghi rõ cái MongoDb Cluster hiện tại của bạn bao nhiêu node? Ram bao nhiêu? Cpu thế nào? Đã nhận diện được các query nào chậm chưa? Query Profiler đã làm chưa?
Ngoài ra, tìm hiểu cách đánh index dựa trên time và geolocation trên MongoDb thế nào?

Các Db khác có thể nhanh hơn, nhưng mình nghĩ không có cải thiện được nhiều đâu. Nếu một db mà "nhanh kinh khủng" hơn các database còn lại thì giờ nó đã chiếm hết thị trường rồi.

Cái database đáng ra phải lựa chọn trước khi bắt đầu dự án chứ giờ đổi kéo theo nhiều thứ lắm. Có thể làm trễ tiến độ lắm luôn, cẩn thận trước khi làm. Còn nếu muốn đổi phải có thử nghiệm, roadmap, rồi so sánh chán chê còn chưa làm nữa, vì nó tốn nhiều thời gian và công sức tiền của.
Click to expand...
Hiện tại job của e đang chia song song 1 bên sẽ đánh giá cái đó và cũng đang chưa có report, khả năng thì e sẽ tự chủ động check lại việc đó. E sẽ note các gợi ý của bác
virusace said:
bài của thớt dùng Timescale k ổn áp lắm, write throughput lớn và nếu tôi hiểu đúng là multiple device write cùng lúc vào db sink -> lúc này sink mà là dạng single node thì tải hệ thống + IO phải đề phòng. Thêm nữa 3 tháng ~4,5b records, thì mấy con như Timescale lưu được mấy tháng, chưa kể ngoài những cột thớt liệt kê thì k biết còn bao nhiêu metric camera đẩy ra (có thể nhiều cột).
=> +1 vote Cassandra khắc phục các yếu tố kể trên, bao gồm cả việc scale hệ thống trong tương lai khi thêm nhiều camera/location.
Bây giờ bài toán là chọn partition key, second index thì phải phụ thuộc vào use case cụ thể của thớt.

P/s: tôi vote Cassandra thay vì Scylla là bởi vì tôi đoán thớt làm ở tổ chức dạng nhà nước/private infra. Kinh nghiệm mà tôi trải qua thì deploy mấy con JVM base + cộng đồng lớn nó dễ chịu hơn nhiều từ lúc setup cho đến lúc khắc phục nếu có issues.
Click to expand...
Yeb dư án e đang làm thuộc kiểu của nhà nước và infra 100% phải private không em ngồi đếm kiến mất. Khá nhiều bác đang recommend việc sử dụng Cassandra nên e sẽ thử tìm hiểu xem ạ
itachicitus said:
Mấy bài toán dạng này bạn có thể tìm hiểu các hệ thống data warehouse, data warehouse được thiết kế chuyên phục vụ mục đích query lượng dữ liệu lớn. Gần đây mình nghe khá nhiều người khen Clickhouse, thậm chí có người xử lý 500B bản ghi chỉ sử dụng 1 máy NUC ClickHouse Cost-Efficiency in Action: Analyzing 500 Billion Rows on an Intel NUC (https://altinity.com/blog/2020-1-1-clickhouse-cost-efficiency-in-action-analyzing-500-billion-rows-on-an-intel-nuc).
Click to expand...
:D Thank bác. Để em ngâm cứu bác nhé
 
Cảm ơn các bác vì đã chia sẻ ý kiến :v khá là nhiều giải pháp nên chắc em sẽ thử dần với hệ thống r đánh giá thử xem như thế nào.
 

Similar threads

Gigabyte_1993
thắc mắc Cần chỉ giáo về hệ thống camera Dahua
2
Replies
27
Views
495
jeremienguyen
jeremienguyen
thánh chuột
tìm việc [FREELANCE] GRAPHIC DESIGN - Chuyên thiết kế Banner / Poster / Logo / Social Post
Replies
0
Views
32
thánh chuột
thánh chuột
Masterchiefs
'Cơn bão' tăng giá ổ đĩa HDD và SSD
2 3 4
Replies
65
Views
4K
leduyquang753
leduyquang753
manoao
Malaysia sẽ xây dựng trung tâm thiết kế vi mạch tích hợp lớn nhất Đông Nam Á
2 3
Replies
45
Views
2K
naughtyfox93
naughtyfox93
manoao
Xe máy không chính chủ, làm sao phạt nguội?
Replies
0
Views
104
manoao
manoao

Share this page

Back
Top