thảo luận Thảo luận về Database.

QTQTQT said:

Em có case check trùng Key trong cùng 1 năm, với lượng dữ liệu khoảng 10-15 tỷ/năm. Các thím có suggest gì không. Nếu dùng DB thì thằng nào hiệu quả cho việc này cho em xin kinh nghiệm với.

Click to expand...

10-15 tỷ là tỷ VND hay tỷ record thím? trung bình 1 tỷ record/tháng thì traffic bự vcl, traffic cỡ này thì bác phải tính architect khác chứ dựa vào check unique của db thôi thì ko ổn.
Trước hết thì xác xuất trùng của data là bao nhiêu? key là data dạng gì? uuid, auto_increment hay kiểu product sku tự generate trên tầng application?
Giả sử case 1 là kiểu uuid, kiểu này xác xuất trùng ít, thím có thể dùng con redis, set expire key mặc định là vài giờ, mỗi lần insert thì vào check cache rồi mới insert vào db. Case 2 kiểu sku tự gen xác xuất trùng nhiều thì thím filter thêm 1 lớp ở local cache ở trên application nữa trước khi xuống db, thêm con redis ở giữa nữa nếu muốn

huungphan said:

10-15 tỷ là tỷ VND hay tỷ record thím? trung bình 1 tỷ record/tháng thì traffic bự vcl, traffic cỡ này thì bác phải tính architect khác chứ dựa vào check unique của db thôi thì ko ổn.
Trước hết thì xác xuất trùng của data là bao nhiêu? key là data dạng gì? uuid, auto_increment hay kiểu product sku tự generate trên tầng application?
Giả sử case 1 là kiểu uuid, kiểu này xác xuất trùng ít, thím có thể dùng con redis, set expire key mặc định là vài giờ, mỗi lần insert thì vào check cache rồi mới insert vào db. Case 2 kiểu sku tự gen xác xuất trùng nhiều thì thím filter thêm 1 lớp ở local cache ở trên application nữa trước khi xuống db, thêm con redis ở giữa nữa nếu muốn

Click to expand...

Request thì ko khủng lắm đâu tại máy ông hay gửi 1 request là 1 list nên chia 10-100 ra mới ra lượng request thím nhé. Có điều kiểm tra trùng dữ liệu vẫn phải xử lý cho từng thằng một.
Bên mình sẽ nhận dữ liệu từ các đối tác truyền lên.
Key là 1 bộ gồm PartnerID + auto_increment, việc chia partner id riêng giảm thiểu việc trùng giữa các partner rồi.
Dùng Redis thì hạn chế được việc trùng gửi duplicate bản tin trong 1 khoảng thời gian ngắn rồi. Tuy nhiên mấy ông partner vui vui thi thoảng lại gửi lại 1 cái id cũ. Ví dụ hiện tại đang 30_000_000 méo biết sao mấy ông ấy lại gửi lại vài request với ID từ 1_000_000 chẳng hạn.

Hiện tại đang áp dụng Bloom filter và apply trên từng partner để tăng perf. Lên đây hỏi thêm các bác thêm có thêm ý tưởng nào hiệu quả ko.

QTQTQT said:

Request thì ko khủng lắm đâu tại máy ông hay gửi 1 request là 1 list nên chia 10-100 ra mới ra lượng request thím nhé. Có điều kiểm tra trùng dữ liệu vẫn phải xử lý cho từng thằng một.
Bên mình sẽ nhận dữ liệu từ các đối tác truyền lên.
Key là 1 bộ gồm PartnerID + auto_increment, việc chia partner id riêng giảm thiểu việc trùng giữa các partner rồi.
Dùng Redis thì hạn chế được việc trùng gửi duplicate bản tin trong 1 khoảng thời gian ngắn rồi. Tuy nhiên mấy ông partner vui vui thi thoảng lại gửi lại 1 cái id cũ. Ví dụ hiện tại đang 30_000_000 méo biết sao mấy ông ấy lại gửi lại vài request với ID từ 1_000_000 chẳng hạn.

Hiện tại đang áp dụng Bloom filter và apply trên từng partner để tăng perf. Lên đây hỏi thêm các bác thêm có thêm ý tưởng nào hiệu quả ko.

Click to expand...

case của thím cug unique phết, khỏi kn đám đông chắc cug khó cho thêm tí context đi thím auto_increment này là bên nào nào generate? idea của e thì vẫn là giảm xác suất key trùng dần dần, đến lúc xuống đến db thì việc trùng xảy ra rất ít để đảm bảo db ko thành bottle neck thôi chứ cuối cùng vẫn cái db là source of truth, vẫn là chỗ đảm bảo data vẫn đúng. E nghĩ nếu là auto_increment thì thím so cái data có id nhỏ nhất trong request với id lớn nhất của partner trong db thử

huungphan said:

case của thím cug unique phết, khỏi kn đám đông chắc cug khó cho thêm tí context đi thím auto_increment này là bên nào nào generate? idea của e thì vẫn là giảm xác suất key trùng dần dần, đến lúc xuống đến db thì việc trùng xảy ra rất ít để đảm bảo db ko thành bottle neck thôi chứ cuối cùng vẫn cái db là source of truth, vẫn là chỗ đảm bảo data vẫn đúng. E nghĩ nếu là auto_increment thì thím so cái data có id nhỏ nhất trong request với id lớn nhất của partner trong db thử

Click to expand...

Cụ thể auto_increment partner tự gen, hiện tại em có lưu maxId của partner để compare. Nhưng tỷ lệ gửi lên trùng của partner đang khá nhiều 10-20% trước có check bằng DB nhưng khá chậm do đó áp thêm 1 lớp bloom filter vào.

Hiện tại nó đang thế này:

request -> lớn hơn maxId thì insert, nhỏ hơn thì check trong bloom -> Không trùng thì insert, nếu có thể trùng thì check trong DB.

Cách này thì perf cũng tạm ổn nhưng đang thấy nhiều layer quá nên đang nghĩ cách tối ưu thím à.

Trước giờ chỉ biết oracle, mssql và 1 chút về mongo DB. Ngồi hóng các cao nhân chia sẻ

QTQTQT said:

Cụ thể auto_increment partner tự gen, hiện tại em có lưu maxId của partner để compare. Nhưng tỷ lệ gửi lên trùng của partner đang khá nhiều 10-20% trước có check bằng DB nhưng khá chậm do đó áp thêm 1 lớp bloom filter vào.

Hiện tại nó đang thế này:

request -> lớn hơn maxId thì insert, nhỏ hơn thì check trong bloom -> Không trùng thì insert, nếu có thể trùng thì check trong DB.

Cách này thì perf cũng tạm ổn nhưng đang thấy nhiều layer quá nên đang nghĩ cách tối ưu thím à.

Click to expand...

Còn cách nữa là đi nói chuyện với partner đó thím mình think out of the box 1 chút, để hệ thống chạy smooth thì cần hợp tác 2 bên chứ ko thể 1 bên làm 1 bên phá. Vấn đề nhiều layer thì mình nghĩ nó là trade off cần có thôi, thím giảm layer thì 1 chỗ nào đó trong hệ thống phải gánh thêm việc. Cug có thể nghĩ đến thay process, việc check duplicate có thể là 1 bước trước khi partner gửi request insert data, như vậy thì khả năng duplicate key cug thấp hơn, các bước validate trong insert request cug giảm dẫn đến ít layer hơn

huungphan said:

Còn cách nữa là đi nói chuyện với partner đó thím mình think out of the box 1 chút, để hệ thống chạy smooth thì cần hợp tác 2 bên chứ ko thể 1 bên làm 1 bên phá. Vấn đề nhiều layer thì mình nghĩ nó là trade off cần có thôi, thím giảm layer thì 1 chỗ nào đó trong hệ thống phải gánh thêm việc. Cug có thể nghĩ đến thay process, việc check duplicate có thể là 1 bước trước khi partner gửi request insert data, như vậy thì khả năng duplicate key cug thấp hơn, các bước validate trong insert request cug giảm dẫn đến ít layer hơn

Click to expand...

Ok thím, việc trao đổi vs partner là chắc chắn rồi. Nếu họ giảm tỉ lệ trùng thì sẽ match ngay layer đầu sẽ nhanh hơn nhiều, nhưng họ có update mình vẫn cần xử lý để đảm bảo.

Cảm ơn thím nhiều vì đã góp ý nhé. Thím đang ở VN hay nước ngoài

upload271 said:

ở đây có thím nào biết shrink DB cho sql server không ạ?

Click to expand...

Thím hỏi gid thì cứ post lên

Up Các thím cứ trao đổi nhiệt tình nhá,để tối về rảnh em tổng hợp lại các vấn đề cho mọi người dễ đọc

P/s: Vẫn hóng về thằng Cassandra ạ

QTQTQT said:

Ok thím, việc trao đổi vs partner là chắc chắn rồi. Nếu họ giảm tỉ lệ trùng thì sẽ match ngay layer đầu sẽ nhanh hơn nhiều, nhưng họ có update mình vẫn cần xử lý để đảm bảo.

Cảm ơn thím nhiều vì đã góp ý nhé. Thím đang ở VN hay nước ngoài

Click to expand...

Thế nghĩa là chỉ cần check cho từng partner ? Số lượng record trung bình của mỗi partner là bn ? Dữ liệu vẫn đang update realtime (tầm 1tỷ record / 1 tháng ?). Bài toán là check cho cái request update realtime này ? Hay process cho đống dữ liệu đã có (vài trăm tỉ record?)

_Gia_Cat_Luong_ said:

Thế nghĩa là chỉ cần check cho từng partner ? Số lượng record trung bình của mỗi partner là bn ? Dữ liệu vẫn đang update realtime (tầm 1tỷ record / 1 tháng ?). Bài toán là check cho cái request update realtime này ? Hay process cho đống dữ liệu đã có (vài trăm tỉ record?)

Click to expand...

Hiện tại đang có 17 partner thím ah, partner thì tập trung vào khoảng 5 ông to nhất mỗi ông ~100tr. Ko update chỉ check trùng trước khi insert theo từng năm 1 một thôi thím.

QTQTQT said:

Hiện tại đang có 17 partner thím ah, partner thì tập trung vào khoảng 5 ông to nhất mỗi ông ~100tr. Ko update chỉ check trùng trước khi insert theo từng năm 1 một thôi thím.

Click to expand...

Id là number hay string vậy mai fen - thấy AI thì chắc là number ? Also, 100tr là 1 tháng nghĩa là tầm 1,2 tỉ 1 năm - check trong dataset này thôi, right ?

_Gia_Cat_Luong_ said:

Id là number hay string vậy mai fen - thấy AI thì chắc là number ?

Click to expand...

Number thím nhé.

QTQTQT said:

Number thím nhé.

Click to expand...

Mình đề xuất dùng bitset của redis, vì id là AI nên dự là khá dense chứ không rải rác.

Evenlope calc 1 tí: 17 partner, mỗi partner = 1,2 tỉ number 1 năm => 17*1200000000/8 = 2.5GB RAM ~ 3GB thôi.

Cách thức check có thể phân theo partner id và range, size tầm 1m hoặc 10m là ổn.

Nghĩa là với mỗi id thì lấy nó chia cho size, ví dụ id = 123,456,789, size = 10m -> thì ứng với range là 123456789 / 10m = 12. Khi đó id sẽ nằm trong bitset với key là <parter_id>:12. Offset là 123456789 % 10m = 3456789. Chỉ việc check xem bit này on hay off thôi.

Các key có thể đặt expire time tầm 1,5 năm, hoặc tự viết job manually xóa cũng được. Definitely là nhanh hơn BF, hỗ trợ batch processing, và luôn cho đáp án chính xác, khỏi phải check lại DB. Cũng cache friendly nữa vì 90% là chỉ check trong 1 vài key range gần đây chứ ít khi nào lquan tới các range cũ.

_Gia_Cat_Luong_ said:

Mình đề xuất dùng bitset của redis, vì id là AI nên dự là khá dense chứ không rải rác.

Evenlope calc 1 tí: 17 partner, mỗi partner = 1,2 tỉ number 1 năm => 17*1200000000/8 = 2.5GB RAM ~ 3GB thôi.

Cách thức check có thể phân theo partner id và range, size tầm 1m hoặc 10m là ổn.

Nghĩa là với mỗi id thì lấy nó chia cho size, ví dụ id = 123,456,789, size = 10m -> thì ứng với range là 123456789 / 10m = 12. Khi đó id sẽ nằm trong bitset với key là <parter_id>:12. Offset là 123456789 % 10m = 3456789. Chỉ việc check xem bit này on hay off thôi.

Các key có thể đặt expire time tầm 1,5 năm, hoặc tự viết job manually xóa cũng được. Definitely là nhanh hơn BF, hỗ trợ batch processing, và luôn cho đáp án chính xác, khỏi phải check lại DB. Cũng cache friendly nữa vì 90% là chỉ check trong 1 vài key range gần đây chứ ít khi nào lquan tới các range cũ.

Click to expand...

Ok thím, ý tưởng tốt quá thím à check chính xác luôn thì ko phải check DB và cũng rất nhanh.

QTQTQT said:

Request thì ko khủng lắm đâu tại máy ông hay gửi 1 request là 1 list nên chia 10-100 ra mới ra lượng request thím nhé. Có điều kiểm tra trùng dữ liệu vẫn phải xử lý cho từng thằng một.
Bên mình sẽ nhận dữ liệu từ các đối tác truyền lên.
Key là 1 bộ gồm PartnerID + auto_increment, việc chia partner id riêng giảm thiểu việc trùng giữa các partner rồi.
Dùng Redis thì hạn chế được việc trùng gửi duplicate bản tin trong 1 khoảng thời gian ngắn rồi. Tuy nhiên mấy ông partner vui vui thi thoảng lại gửi lại 1 cái id cũ. Ví dụ hiện tại đang 30_000_000 méo biết sao mấy ông ấy lại gửi lại vài request với ID từ 1_000_000 chẳng hạn.

Hiện tại đang áp dụng Bloom filter và apply trên từng partner để tăng perf. Lên đây hỏi thêm các bác thêm có thêm ý tưởng nào hiệu quả ko.

Click to expand...

nếu vđ để sinh distributed unique id. thì bạn có thể xem snowflake của twitter

Cái này thay vì partnerId bạn có thể dùng ngày ở định dạng yyyymmdd + sequence để làm id, không nên dùng id từ hệ thống bên ngoài làm id vì mình không kiểm soát được.

noobdev said:

Up Các thím cứ trao đổi nhiệt tình nhá,để tối về rảnh em tổng hợp lại các vấn đề cho mọi người dễ đọc

P/s: Vẫn hóng về thằng Cassandra ạ

Click to expand...

Mình có thời gian làm vận hành Cassandra trên large product thì có 1 số nhận xét sau.
Cassandra được phát triển bởi Facebook vào 2007 cho tính năng inbox search. Trong C.A.P thì Cassandra tiêu biểu cho A.P (available và partition tolerant). Cassandra sử dụng kiến trúc peer-to-peer, nghĩa là node đều kết nối với nhau và có vai trò ngang hàng. Nên khi sập 1 node vẫn không ảnh hưởng tới available của hệ thống.
Thông thường tốc độ Write của cassandra nhanh hơn Read nên nó hay được dùng trong trường hợp mình cần ghi nhiều hơn đọc. Vd như lưu Audit logs, sensor logs, iot apps, time series app như hawkular.
Việc vận hành Cassandra on prem để nó hoạt động trơn tru khá phức tạp nên có một team SRE hay DB maintain. Chẳng hạn như phải xây dựng được cơ chế backup & restore cho cassandra, dữ liệu trên cass đôi khi bị mismatch giữa các node làm cho app bị sập thì phải chui vô repair (sync lại data giữa các node) hoặc có thể sử dụng tool reaper.
Điều đặc biệt là cassandra nó không có loadbalancer đứng trước như mấy DB khác see more.

Bonus:
https://github.com/pingcap/awesome-database-learning
https://blog.pythian.com/cassandra-use-cases/

Rvor said:

Cái này thay vì partnerId bạn có thể dùng ngày ở định dạng yyyymmdd + sequence để làm id, không nên dùng id từ hệ thống bên ngoài làm id vì mình không kiểm soát được.

Click to expand...

Id bên parner tạo, có 1 cách là validate id của file theo max id trong hệ thống, ko đc thì reject tất, báo bên khách gửi lại

Cho e hỏi có cách nào hiệu quả chuyển data từ Postgre sang SnowSQL ko ạ