Lưu trữ dữ liệu realtime sử dụng google cloud

Chung 1 server vẫn đc. Có lẽ nên dùng redis ở server để show dữ liệu realtime

Chào bạn, bên mình hiện tại đang xử lý một lượng dữ liệu cũng tương đối lớn, ~500tr records mỗi ngày, dữ liệu này bao gồm nhiều loại dữ liệu, vào liên tục, và cũng có lúc cao điểm và thấp điểm. Nên cũng có chút kinh nghiệm cho chuyện này

Về việc hứng dữ liệu, mình thấy là bạn nên sử dụng Http Request thay vì tcp socket, lý do: cái này là về độ available của hệ thống. Mặc dụ TCP Socket tốt hơn về performance nhưng khi một node TCP down, thì những client đang connect cũng sẽ rớt. Vậy dựng Http Request vào thì một instance Http rớt thì vẫn còn instance hứng (nhớ dựng load balance). Nếu trên Java thì có thể sư dụng Netty để làm đầu hứng, đã được cộng đồng ủng hộ vị độ chịu tải và độ ổn định của nó cực kỳ cao.

Về mặt dữ liệu, bên bạn cần phải xác định rõ, những dữ liệu này có cần phải mang tính unique không? ví dụ như log bắn về thời gian sử dụng của smartwatch chẳng hạn, thì không cần phải mang tính unique trong đây, chỉ cần sum lại giờ này có bao nhiêu người xài v.v. Có thể aggregate ngay từ bước index dữ liệu. Nhưng có những dữ liệu phải mang tính transaction thì phải dữ lại gần như là raw, chỗ này là tuỳ vào tính chất dữ liệu để lựa chọn DB cho phù hợp.

Còn việc db và web có nên chung server không thì cái đó tuỳ vào độ nặng của server ra sao, nếu còn dư resource thì cứ phang cái web lên chạy, chừng nào thấy không ổn thì rút ra deploy chỗ khác.

Thứ ba nữa là về realtime, dữ liệu để đạt được realtime thì ngay từ bước hứng dữ liệu, bạn đã phải chắt lọc lại dữ liệu để hiển thị realtime. Hãy xác định các dữ liệu cần realtime để thiết kế, không phải dữ liệu nào cũng cần realtime. Dữ liệu này sau khi chắt lọc cho realtime, bạn có thể write vào kafka hoặc xuống rawlog để cho phần job tiếp theo xử lý (ví dụ các tác vụ Machine Learning) hay segment.

Build một hệ thống big data khá là phức tạp, bạn phải làm rõ dữ liệu của bạn có những gì và cần những gì. Hãy làm rõ với KH của bạn rồi chúng ta có thể tiếp tục.

Note thêm là mình chưa sử dụng Google cloud lần nào nên không có kinh nghiệm sử dụng những công cụ nó hỗ trợ, và không biết nó có những gì. Còn nếu làm “cây nhà lá vườn” và sử dụng GGC như là PaaS thì có thể chia sẻ được. Nhưng sử dụng GGC hoặc code cây nhà lá vườn có những cái cost khác nhau, không biết bên KH của bạn có những mong muốn như thế nào.

Mình thấy có thằng Google firebase tối ưu cho runtime với lượng dữ liệu lớn. Bạn tìm hiểu xem thế nào, vì m chưa dùng nó bao giờ nên ko giúp đc nhiều.

Đấy là kiểu “cây nhà lá vườn”, mình phải xây dựng hết mọi thứ từ a-z. Nhưng nếu sử dụng google cloud thì nó sẽ hổ trợ cho mình những gì để bớt tốn công xây dựng và bảo trì? Mọi người có giải pháp nào tối ưu cho bài toán này khi sử dụng với google cloud không nh

Google Cloud có Google BigTable, có thể thay thế MongoDB, Google Dataflow hỗ trợ tính toán dữ liệu batch hoặc streaming, datalab, bigquery để hỗ trợ phân tích và visualization, cloud pub/sub có thể thay thế webservice nhận dữ liệu client đẩy vào. Google có mô tả khá rõ ở trang của họ rồi

Google Cloud

Big Data Solutions  |  Data Analytics Products  |  Google Cloud

GCP offers a proven, integrated end to end Big Data solution, based on years of innovation, that lets you capture, process, store and analyze your data within a single platform.

Việc dùng hàng dựng sẵn đương nhiên sẽ tiện hơn rất nhiều về lâu dài, đặc biệt chi phí maintainance và monitoring / debugging vì đa số sẽ không “sập” dù lượng dữ liệu và tốc độ dữ liệu đẩy vào tăng lên (Cho đến khi nào còn… tiền). Đương nhiên điểm yếu của nó là một khi đã sử dụng sẽ gắn chặt với nó và rất khó để thay đổi nhà cung cấp, đồng thời sẽ tốn 1 thời gian khá nhiều để tìm hiểu về kiến trúc và cách sử dụng do Google đề xuất ra.

Chung 1 server vẫn đc. Có lẽ nên dùng redis ở server để show dữ liệu realtime

Tại ở server thì chủ yếu là chỉ lưu trữ dữ liệu thôi chứ không cần show dữ liệu kiểu realtime ra dữ liệu show ra là dữ liệu đã được phân tích và tính toán rồi hoặc đơn giản chỉ là truy vấn dữ liệu trong 1 khoản thời gian trong quá khứ nào đó thôi

Về việc hứng dữ liệu, mình thấy là bạn nên sử dụng Http Request thay vì tcp socket, lý do: cái này là về độ available của hệ thống. Mặc dụ TCP Socket tốt hơn về performance nhưng khi một node TCP down, thì những client đang connect cũng sẽ rớt. Vậy dựng Http Request vào thì một instance Http rớt thì vẫn còn instance hứng (nhớ dựng load balance). Nếu trên Java thì có thể sư dụng Netty để làm đầu hứng, đã được cộng đồng ủng hộ vị độ chịu tải và độ ổn định của nó cực kỳ cao.

Mình nghỉ dùng Http Request + json mà triển nhỉ, chắc ổn

Về mặt dữ liệu, bên bạn cần phải xác định rõ, những dữ liệu này có cần phải mang tính unique không? ví dụ như log bắn về thời gian sử dụng của smartwatch chẳng hạn, thì không cần phải mang tính unique trong đây, chỉ cần sum lại giờ này có bao nhiêu người xài v.v. Có thể aggregate ngay từ bước index dữ liệu. Nhưng có những dữ liệu phải mang tính transaction thì phải dữ lại gần như là raw, chỗ này là tuỳ vào tính chất dữ liệu để lựa chọn DB cho phù hợp.

Khách hàng thì cứ muốn lưu hết dữ liệu raw, lưu như thế thì dữ liệu sẽ thuộc hàng quá khủng phải cần phải nói chuyện với “thượng đế” về vụ này mới được [quote=“Nancru, post:3, topic:41234”]
Còn việc db và web có nên chung server không thì cái đó tuỳ vào độ nặng của server ra sao, nếu còn dư resource thì cứ phang cái web lên chạy, chừng nào thấy không ổn thì rút ra deploy chỗ khác.
[/quote]
Chổ này thì mình nghỉ nó phụ thuộc vào tài nguyên hệ thống cơ mà mình đang phân vân giữa việc tách phần thu thập dữ liệu(nhận dữ liệu từ client để đẩy vào database) và phần web(chỉ để show/phân tích dữ liệu ra) ra làm 2 projects hay là chung 1 project luôn [quote=“Nancru, post:3, topic:41234”]
Dữ liệu này sau khi chắt lọc cho realtime, bạn có thể write vào kafka hoặc xuống rawlog để cho phần job tiếp theo xử lý (ví dụ các tác vụ Machine Learning) hay segment.
[/quote]
Kiểu này giống như xử lý bất đồng bộ, dữ liệu lưu vào đâu đó rồi 1 tác vụ khác sẽ từ từ xử lý sau mình hiểu thế không biết có đúng không

Build một hệ thống big data khá là phức tạp, bạn phải làm rõ dữ liệu của bạn có những gì và cần những gì. Hãy làm rõ với KH của bạn rồi chúng ta có thể tiếp tục.

Phần này mình nghỉ là phần phức tạp nhất trong hệ thống, vì thế nên phải giành ra vài ngày để clear với khách hàng trước khi bắt tay vào việc

Note thêm là mình chưa sử dụng Google cloud lần nào nên không có kinh nghiệm sử dụng những công cụ nó hỗ trợ, và không biết nó có những gì. Còn nếu làm “cây nhà lá vườn” và sử dụng GGC như là PaaS thì có thể chia sẻ được. Nhưng sử dụng GGC hoặc code cây nhà lá vườn có những cái cost khác nhau, không biết bên KH của bạn có những mong muốn như thế nào.

Khách hàng bảo là mua bên google cloud rồi thế nên mình không có sự lựa chọn là phải nguyên cứu về nó

Google Cloud có Google BigTable, có thể thay thế MongoDB, Google Dataflow hỗ trợ tính toán dữ liệu batch hoặc streaming, datalab, bigquery để hỗ trợ phân tích và visualization, cloud pub/sub có thể thay thế webservice nhận dữ liệu client đẩy vào. Google có mô tả khá rõ ở trang của họ rồi https://cloud.google.com/products/big-data/

thấy tiện ghê luôn, phần thu thập, lưu trữ và phân tích nó làm gần hết cho mình cả rồi nhỉ. Để mình nguyên cứu theo mô hình này xem

Việc dùng hàng dựng sẵn đương nhiên sẽ tiện hơn rất nhiều về lâu dài, đặc biệt chi phí maintainance và monitoring / debugging vì đa số sẽ không “sập” dù lượng dữ liệu và tốc độ dữ liệu đẩy vào tăng lên (Cho đến khi nào còn… tiền). Đương nhiên điểm yếu của nó là một khi đã sử dụng sẽ gắn chặt với nó và rất khó để thay đổi nhà cung cấp, đồng thời sẽ tốn 1 thời gian khá nhiều để tìm hiểu về kiến trúc và cách sử dụng do Google đề xuất ra.

Khách hàng thì lúc nào cũng “dể mà em, vài ngày là xong” có biết là tụi dev nó phải nguyên cứu công nghệ mới kiểu “realtime” để phục vụ các “thượng đế” một cách tốt nhất đâu .

Mình thấy có thằng Google firebase tối ưu cho runtime với lượng dữ liệu lớn. Bạn tìm hiểu xem thế nào, vì m chưa dùng nó bao giờ nên ko giúp đc nhiều.

Bạn @Itachi_Citus có đề cập đến Google BigTable giờ có thêm cái Google Firebase nữa . Theo mình google được thì cả 2 bên đều là nonsql, 1 bên là wide column còn 1 bên là document dữ liệu mình lưu đơn giản lắm, chỉ là các giá trị điện năng thôi thế nên mình nghỉ document có lẻ sẽ phù hợp hơn, không biết việc lựa chọn này có ảnh hưởng nhiều tới hiệu suất truy vấn không nhỉ

Mình nghỉ dùng Http Request + json mà triển nhỉ, chắc ổn

Ý là Http Request thôi, còn dữ liệu gửi về thì gì cũng được, nhưng để tiết kiệm băng thông thì nên tính tới bài toán tiết kiệm kí tự. Ví dụ như json gửi về key: deviceVersion, thay vì chuỗi dài thòng lòng thì viết tắt thành dv hoặc gửi theo batch dữ liệu v.v Mặc dù nhìn có vẻ đơn giản, nhưng nó sẽ tiết kiệm rất, rất nhiều $, lẫn độ ổn định cho hệ thống.

Chổ này thì mình nghỉ nó phụ thuộc vào tài nguyên hệ thống cơ mà mình đang phân vân giữa việc tách phần thu thập dữ liệu(nhận dữ liệu từ client để đẩy vào database) và phần web(chỉ để show/phân tích dữ liệu ra) ra làm 2 projects hay là chung 1 project luôn

Cái này là project management thôi, muốn code chung cũng được, code riêng cũng được. Nhưng thường là tách riêng ra cho dễ về mặt deploy và maintanance.

Khách hàng bảo là mua bên google cloud rồi

Có thể chỉ dùng hosting services của nó thôi để deploy application của mình, hoặc dùng hết phần nó hỗ trợ. Nhưng theo tự đánh giá là KH này prefer dùng hàng dựng sẵn cho lẹ, ko chuộng cây nhà lá vườn. Vậy thôi, chúc bạn may mắn nhé.

A post was merged into an existing topic: Topic lưu trữ các post off-topic - version 3