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.
- write throughput ở đây là append-only, không có update và khả năng cao là từ IOT device qua servers đẩy vào database. Nếu xử lý kiểu này thì đa phần là ingest theo batch, SQL xử lý còn ngon nữa
- throughput insert batch row của timescale cực lớn cho append-only data, thớt dùng on-premise có khả năng cao là intranet từ server đến db (IO cao) nên mình mới recommend
- phần storage có support compression nên không cần cold storage vào object storage để save cost
- use case này phần tracing và violation là truy vấn time series data. Khá giống cái benchmark case GitHub - timescale/tsbs: Time Series Benchmark Suite, a tool for comparing and evaluating databases for time series data (https://github.com/timescale/tsbs?tab=readme-ov-file#internet-of-things-iot). Và mình nói luôn là Cassandra không được dùng cho mục đích truy vấn time series data
(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à.
- write throughput ở đây là append-only, không có update và khả năng cao là từ IOT device qua servers đẩy vào database. Nếu xử lý kiểu này thì đa phần là ingest theo batch, SQL xử lý còn ngon nữa
- throughput insert batch row của timescale cực lớn cho append-only data, thớt dùng on-premise có khả năng cao là intranet từ server đến db (IO cao) nên mình mới recommend
- phần storage có support compression nên không cần cold storage vào object storage để save cost
- use case này phần tracing và violation là truy vấn time series data. Khá giống cái benchmark case GitHub - timescale/tsbs: Time Series Benchmark Suite, a tool for comparing and evaluating databases for time series data (https://github.com/timescale/tsbs?tab=readme-ov-file#internet-of-things-iot). Và mình nói luôn là Cassandra không được dùng cho mục đích truy vấn time series data
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 đó":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.
Đọ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...(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/)
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.Đọ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 á
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.
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.
Off topic:(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/)
rồi tóm lại là chọn dc chưa