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

Thử Arangodb dựa trên rocksdb của facebuck xem sao :)
Db của fb nó query phát 1 thì chỉ còn nghi ngờ về user thôi :D
 
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.
 

Off topic:
Tui cũng khá đặt câu hỏi cho Cassandra hay ScyllaDb vì yêu cầu rõ ràng là focus trên time series và geolocation.

Trong khi 2 thằng này không được thiết kế chuyên biệt cho chuyện đó.

Lúc đầu tui có nghĩ đến InfluxDb chuyên dùng cho IoT. Cực mạnh cho time series với write throughput. Nhưng lại không mạnh bên geolocation tuy nhiên nó cũng có add-in cho chuyện đó.

Nếu dự án chưa bắt đầu thì tụi sẽ đề nghị InfluxDb. Còn bắt đầu rồi thì ráng tối ưu MongoDb trước xem sao.
 
Last edited:
(1,2,3) vâng, chính cty tôi đang dùng Timescale (project của tôi) cho bài near realtime monitor system, đây nhưng khác thớt chỗ chúng tôi chỉ cần weekly data câu chuyện nó khác. Chỉ vì support compression mà cover được vấn đề scalable của hệ thống có lạc quan quá không bác, single node thì bài toán xác định dừng lại ở xử lý vài chục terabyte thay vì petabyte rồi. Tất nhiên tôi không cổ súy dùng dao mổ trâu để giết gà.
(4) Bác có thể giải thích or dẫn chứng cho "Cassandra không được dùng cho mục đích truy vấn time series data" k?
Scaling Time Series Data Storage - #Netflix
Building Netflix’s Distributed Tracing Infrastructure - #Netflix

Tôi quote tạm 2 câu example test Google Professional Data Engineer liên quan đến vấn đề này các bác thẩm xem sao:
Code:
Q3 : A pharmaceutical factory has over 100,000 different sensors generating
JSON-format events every 10 seconds to be collected. You need to gather the
event data for sensor & time series analysis.
Which database is best used to collect event data?

Q10 : An air-quality research facility monitors the quality of the air and
alerts of possible high air pollution in a region. The facility receives
event data from 25,000 sensors every 60 seconds. Event data is then used
for time-series analysis per region. Cloud experts suggested using BigTable
for storing event data.
What will you design the row key for each even in BigTable?

Off topic:
Tui cũng khá đặt câu hỏi cho Cassandra hay ScyllaDb vì yêu cầu rõ ràng là focus trên time series và geolocation.

Trong khi 2 thằng này không được thiết kế chuyên biệt cho chuyện đó.

Lúc đầu tui có nghĩ đến InfluxDb chuyên dùng cho IoT. Cực mạnh cho time series với write throughput. Nhưng lại không mạnh bên geolocation tuy nhiên nó cũng có add-in cho chuyện đó.

Nếu dự án chưa bắt đầu thì tụi sẽ đề nghị InfluxDb. Còn bắt đầu rồi thì ráng tối ưu MongoDb trước xem sao.
Em ref article của chính InfluxDb cho vấn đề "không được thiết kế chuyên biệt cho chuyện đó":
Compare InfluxDB vs Apache Cassandra (https://www.influxdata.com/comparison/influxdb-vs-cassandra/)
 
(1,2,3) vâng, chính cty tôi đang dùng Timescale (project của tôi) cho bài near realtime monitor system, đây nhưng khác thớt chỗ chúng tôi chỉ cần weekly data câu chuyện nó khác. Chỉ vì support compression mà cover được vấn đề scalable của hệ thống có lạc quan quá không bác, single node thì bài toán xác định dừng lại ở xử lý vài chục terabyte thay vì petabyte rồi. Tất nhiên tôi không cổ súy dùng dao mổ trâu để giết gà.
(4) Bác có thể giải thích or dẫn chứng cho "Cassandra không được dùng cho mục đích truy vấn time series data" k?
Scaling Time Series Data Storage - #Netflix
Building Netflix’s Distributed Tracing Infrastructure - #Netflix

Tôi quote tạm 2 câu example test Google Professional Data Engineer liên quan đến vấn đề này các bác thẩm xem sao:
Code:
Q3 : A pharmaceutical factory has over 100,000 different sensors generating
JSON-format events every 10 seconds to be collected. You need to gather the
event data for sensor & time series analysis.
Which database is best used to collect event data?

Q10 : An air-quality research facility monitors the quality of the air and
alerts of possible high air pollution in a region. The facility receives
event data from 25,000 sensors every 60 seconds. Event data is then used
for time-series analysis per region. Cloud experts suggested using BigTable
for storing event data.
What will you design the row key for each even in BigTable?


Em ref article của chính InfluxDb cho vấn đề "không được thiết kế chuyên biệt cho chuyện đó":
Compare InfluxDB vs Apache Cassandra (https://www.influxdata.com/comparison/influxdb-vs-cassandra/)
Đọc cái benchmark đi bạn ui. Có nêu ra và có số liệu, trước giờ tui chọn db dựa vào benchmark chứ k phải articles...
Tui đọc xog cái articles bạn đưa rồi tui thấy bạn đang nhầm lẫn giữa warehouse solution với multiple components trong đó có Cassandra với single component solution với 1 time series db á
 
Đọc cái benchmark đi bạn ui. Có nêu ra và có số liệu, trước giờ tui chọn db dựa vào benchmark chứ k phải articles...
Tui đọc xog cái articles bạn đưa rồi tui thấy bạn đang nhầm lẫn giữa warehouse solution với multiple components trong đó có Cassandra với single component solution với 1 time series db á
Benchmark liên quan gì bác, point của tôi là scalable, title của thread là ... cho hệ thống lớn. Bác lấy benchmark của timescale ra cũng k khách quan. Còn đoạn sau tôi k hiểu ý bác lắm.
 
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.

đây nhé thớt, định comment mà bạn này comment giống ý mình rồi, nhu cầu chủ thớt không cần phải ghi vào db luôn, vẫn query các kiểu như thường được
 
+1 cho HDFS / Query bằng Trino. Ưu điểm: Lưu thoải mái, cả năm cũng được, vì snappy nén tốt (<10%), partition theo ngày, dễ maintain - query chậm thì gắn thêm machine vào làm executer chia tải (thích hợp với on-prem). Nhược điểm: chỉ có partition, ko có index nên phải full-scan từng partition nếu muốn query kiểu “sedan màu đỏ”, chỉ thích hợp cho usecase write thường xuyên, lâu lâu read/query (vd làm report). Cẩn thận duplicated data.

Timescale thì lý thuyết vẫn xử đc 5 tỷ record (thậm chí Postgres cũng được), phần ngoài 5 tỷ (cold data) thì compress về dưới 15%. Tuy nhiên mỗi lần re-index sẽ khá thốn, vì bạn cần tối ưu index cho cả query, index size, time-series column, với compress segment. Định nghĩa 1 phương tiện là 1 series thì mình cảm thấy ko hiệu quả lắm vì quá nhiều.
 
Benchmark liên quan gì bác, point của tôi là scalable, title của thread là ... cho hệ thống lớn. Bác lấy benchmark của timescale ra cũng k khách quan. Còn đoạn sau tôi k hiểu ý bác lắm.

Nếu scale đến petabytes storage thì chia r multi-tiered storage với 1 db và 1 object storage rồi chia ra partitions rồi. Chứ không dại gì mà keep cold storage trên db cả.
Ngay từ đầu là tui recommend thớt object storage rồi, còn bạn thấy bạn store tất cả trên Cassandra thì bạn cứ triển.
Còn solution cho thớt vẫn là 1 timeseries db nếu quá lớn thì đẩy vào object storage ...
 
(1,2,3) vâng, chính cty tôi đang dùng Timescale (project của tôi) cho bài near realtime monitor system, đây nhưng khác thớt chỗ chúng tôi chỉ cần weekly data câu chuyện nó khác. Chỉ vì support compression mà cover được vấn đề scalable của hệ thống có lạc quan quá không bác, single node thì bài toán xác định dừng lại ở xử lý vài chục terabyte thay vì petabyte rồi. Tất nhiên tôi không cổ súy dùng dao mổ trâu để giết gà.
(4) Bác có thể giải thích or dẫn chứng cho "Cassandra không được dùng cho mục đích truy vấn time series data" k?
Scaling Time Series Data Storage - #Netflix
Building Netflix’s Distributed Tracing Infrastructure - #Netflix

Tôi quote tạm 2 câu example test Google Professional Data Engineer liên quan đến vấn đề này các bác thẩm xem sao:
Code:
Q3 : A pharmaceutical factory has over 100,000 different sensors generating
JSON-format events every 10 seconds to be collected. You need to gather the
event data for sensor & time series analysis.
Which database is best used to collect event data?

Q10 : An air-quality research facility monitors the quality of the air and
alerts of possible high air pollution in a region. The facility receives
event data from 25,000 sensors every 60 seconds. Event data is then used
for time-series analysis per region. Cloud experts suggested using BigTable
for storing event data.
What will you design the row key for each even in BigTable?


Em ref article của chính InfluxDb cho vấn đề "không được thiết kế chuyên biệt cho chuyện đó":
Compare InfluxDB vs Apache Cassandra (https://www.influxdata.com/comparison/influxdb-vs-cassandra/)
Off topic:
Tụi tránh sa đà vào cãi nhau vô nghĩa nên bạn thông cảm tui sẽ không nói qua lại nhiều.

Bạn đọc bài báo rồi bạn cũng thấy mỗi bài toán khác nhau dùng cách khác nhau để đạt được tối ưu công suất trên cùng một giá thành

Và theo ý tôi Cassandra nó không tạo ra chuyên biệt cho time-series. Nó hỗ trợ query theo time, tạo partition theo time không có nghĩa là nó được tối ưu cho time series data.

MsSql, Postgres... nó cũng hỗ trợ time query và time partition vậy? Mà ngay cả cái MongoDb nó cũng hỗ trợ đánh index theo time luôn, không cần phải dùng tới Cassandra. Nên tôi đề nghị chủ thớt xem lại coi đã tối ưu MongoDb chưa trước khi đi tìm database khác.

Nhưng đó là ý kiến cá nhân của tui thôi. Còn các bạn muốn dùng gì thì cứ dùng.
 
Chọn gì thì phần maintain cũng khoai, thớt xin cty tiền xăng xe sang bên khách cao vào nhé, hỗ trợ ăn trưa, rồi rủ các sếp bên kia nhậu :LOL:
 
rồi tóm lại là chọn dc chưa :D

Tóm lại như các bác trên chia sẻ
  • Tối ưu lại mongo và cân nhắc việc index lượng lớn dữ liệu
  • Cassandra
  • Clickhouse
  • Lưu file HDFS

😂 Giờ mỗi mục còn phải đọc tài liệu và setup thử đánh giá xem ntn đã bác. Nhiều keyword ntn thì e tìm hiểu chắc cũng mất kha khá thời gian.


via theNEXTvoz for iPhone
 
Back
Top