thắc mắc query vào database liên tục

KiemTienKhongKho2022 said:
Sao vào thread này toàn suggest Kafka Connect, Debezium chi cho phức tạp mà nặng nề vậy :burn_joss_stick:. Có mỗi cái DB đã maintain phát mệt rồi, mấy thím còn thêm đủ thứ hoa lá vào, chỉ tội thằng dev vào sau :adore:
Click to expand...
sao bác ko nghĩ là thêm hoa lá thì thằng dev sau mới có cơ hội tăng lương :v
 
KiemTienKhongKho2022 said:
Sao vào thread này toàn suggest Kafka Connect, Debezium chi cho phức tạp mà nặng nề vậy :burn_joss_stick:. Có mỗi cái DB đã maintain phát mệt rồi, mấy thím còn thêm đủ thứ hoa lá vào, chỉ tội thằng dev vào sau :adore:
Click to expand...
right tool for the right job thôi fence, cái gì có thể giải quyết dễ dàng bằng những tool phổ biến, đã trải qua thử thách thực tế bởi nhiều anh lớn thì nếu chẳng có lý do gì đủ mạnh thì ngồi sáng tạo lại cái bánh xe làm gì? Thực ra đi maintain gặp hoa lá cành mà hàng tiêu chuẩn còn hạnh phúc gấp tỉ lần phải ôm 1 giải pháp nhà trồng không giống ai fence ạ.
 
Last edited:
10s 1 lần thì thím index cái timestamp rồi quét thôi, tốn thêm storage cái index thôi chứ performance không có vấn đề gì đâu. Khi nào scan 10 lần 1s mới sợ thôi
Update: à nếu bảng insert + update nhiều thì theo dõi performance có thể bị ảnh hưởng do index nữa :D
 
Last edited:
Level 1 của ETL thôi có gì đâu.
Level 1: cronjob, interval :sexy_girl:

Mình từng làm 1 con ETL khá to (vài chục ngàn loc) vẫn trigger bằng crontab nhá :byebye:
Còn chuyện query vào db thì bạn cứ sizing và monitor nó xem có vấn đề gì không, cần thì ước lượng peaktime và có chiến lược để recovery data.
Nếu các job bắt đầu phình lên và phức tạp thì nghĩ tới việc move qua dùng những con orchestration như airflow, luigi ...
Quan trọng là xem tương lai nó có phình lên hay không thì chấp nhận tốn tgian ngay từ đầu để làm thôi. Còn nó không phình thì cứ cái gì nhanh gọn lẹ mà quất

via theNEXTvoz for iPhone
 
chắc là cloud kiểu thuê con VPS/Ec2/AppEngine rồi manual setup DB à :v ; nếu vậy thì dùng cái feature replication của db luôn đi cho an tâm (mọi RMDB đều có hết. google "Tên DB + replication").
Nếu cloud là RDS/CloudSQL<-> on-premise thì vote bỏ luôn con on-premise đi và chỉ cần trả x2 cho cloud là nó lo tất; hoặc quay lai bước trên(VPS <-> On-premise, xài feature replication của DB luôn).

Viết lệnh chay để interval sync db kiểu này phiền hà lắm,(nếu sync hết thì chạy như rùa ; Còn sync theo từng thay đổi thì sync cái gì, khi schema đổi thì phải báo trì code sync, rồi thì audit_log có sync ko ,...) , tốt nhất là cứ xài DB gì thì cứ dùng replication của db đó đi cho lành
 
Yurisha said:
right tool for the right job thôi fence, cái gì có thể giải quyết dễ dàng bằng những tool phổ biến, đã trải qua thử thách thực tế bởi nhiều anh lớn thì nếu chẳng có lý do gì đủ mạnh thì ngồi sáng tạo lại cái bánh xe làm gì? Thực ra đi maintain gặp hoa lá cành mà hàng tiêu chuẩn còn hạnh phúc gấp tỉ lần phải ôm 1 giải pháp nhà trồng không giống ai fence ạ.
Click to expand...
đây là câu chuyện dài giữa right tool for the job and the best tool for the job

Theo tui, Kafka chính là best tool for the job. Cron job + đánh index chính là right tool for the job.
 
Ủa thím có thể stream các change event trong DB để stream việc thay đổi dữ liệu được mà.
Trevor_Schmeler said:
Mình đang có cái yêu cầu sync up giữa On-premises vs cloud. Mà k/h thì có yêu cầu dữ liệu phải sync sớm lên cloud. Mình cũng hơi ngần ngại dùng interval nhưng ko có cách nào khác. Tìm tài liệu của MS thì không thấy. Đang ko rõ thời gian ngắn quá thì có ảnh hưởng gì tới database server không.

Sent from Xiaomi Pro via nextVOZ
Click to expand...
 
Trevor_Schmeler said:
Mình đang có cái yêu cầu sync up giữa On-premises vs cloud. Mà k/h thì có yêu cầu dữ liệu phải sync sớm lên cloud. Mình cũng hơi ngần ngại dùng interval nhưng ko có cách nào khác. Tìm tài liệu của MS thì không thấy. Đang ko rõ thời gian ngắn quá thì có ảnh hưởng gì tới database server không.

Sent from Xiaomi Pro via nextVOZ
Click to expand...
Dùng cloud hãng nào thì dùng tool và tài liệu của hãng đó. Cái AWS có cung cấp tool để migrate đó. Query liên tục ko thành vấn đề, vấn đề ở câu query cost có nhiều ko.
 
các giải pháp có thể thì ae nói cả ở trên rồi,
chủ thớt cứ phải thử rồi monitor tính toán sao cho phù hợp,
nếu là tôi thì CDC
 
Bác ném nó vào Queue rồi set 10s run 1 lần.
Tùy thuộc vào BU logic dự án mà quất thôi.
Quan trọng là tại sao lại 10s và mục đích để làm gì vậy bác?
 
mình cũng thấy thắc mắc :D nếu cần near realtime thì đừng nghĩ tới xử lý theo kiểu batch processing như thế nhờ, dùng kafka connect hoặc dbz như các bác đề xuất này, đọc log CDC đỡ ảnh hưởng performance hơn, còn như thớt nói dùng ADF chọc liên tục thế thì chết con ngta :v rồi 1 ngày nó nằm ngay đơ ra cũng khổ ( mặc dù bác đánh index thì cũng k ngoại trừ khả năng chết nếu 1 lúc nào đó có multiple session chọc vào đủ lớn)
 
Chưa thấy ai khuyến khích call server liên tục như vậy.
Bạn muốn real time thì có thể dùng cơ chết Websocket. Thư viện Signal có Signal Hub. Nó nhận những thay đổi từ phía db để gửi kết quả cho client subscribe.
Tức là nếu db thay đổi thì client mới thay đổi, chứ không phải real time là thay đổi liên tục.
 
Thường lưc nào chả có Job phải làm như vậy. Nhưng chạy 24/24 thì lại cả vấn đề lắm rủi ro. Thông thường các cụ to đầu chọn 1 khung giờ ít rủi ro nhất rồi cho chạy các job này.
T có 4,5 job Sync cứ 4-5s chạy 1 phát đây. Tránh call vào service thường mà viết riêng ra thôi.
 
Toidaidot93 said:
Chưa thấy ai khuyến khích call server liên tục như vậy.
Bạn muốn real time thì có thể dùng cơ chết Websocket. Thư viện Signal có Signal Hub. Nó nhận những thay đổi từ phía db để gửi kết quả cho client subscribe.
Tức là nếu db thay đổi thì client mới thay đổi, chứ không phải real time là thay đổi liên tục.
Click to expand...
Chưa lội hết page tưởng thớt là đồng bộ db từ nơi này qua nơi khác. Hoá ra Real Time á. RealTime thì như thím này mà triển nhé.
 
LuciferMorningStar00 said:
Chưa lội hết page tưởng thớt là đồng bộ db từ nơi này qua nơi khác. Hoá ra Real Time á. RealTime thì như thím này mà triển nhé.
Click to expand...
Ừm bạn
Vì yêu cầu của thớt là call lên server liên tục với mục đích lấy dữ liệu.Nó cũng có nghĩa như realTime rồi.
THay vì call thì mình có thể dùng realtime. Có thay đổi dữ liệu mới call
 
Toidaidot93 said:
Ừm bạn
Vì yêu cầu của thớt là call lên server liên tục với mục đích lấy dữ liệu.Nó cũng có nghĩa như realTime rồi.
THay vì call thì mình có thể dùng realtime. Có thay đổi dữ liệu mới call
Click to expand...
  • Là Real Time thì cứ Websocket - SignalR mà táng.
  • Còn Sync Data giữa 2 DB thì cũng có nhiều loại Job hỗ trợ thế. Đang làm dotnet có thằng Azure Function support cũng ngon mà rẻ.
 
nghĩ lại mình dùng oubox patern , 300ms query 1 lần mà con db cpu vẫn ko quá 20% , phải cho devops giảm gấp cpu db xuống cho đỡ tồn xiền , 10s thì còn tùy xem datasize và điều kiện tìm kiếm và cấu trúc bảng thế nào , 10s mà tìm kiếm bảng ko index, size cỡ 10 triệu bản ghi thì vỡ alo.
 
Em mới nghe ông sếp e nói về việc chạy song song 2 DB instance, 1 để đọc, 1 để ghi rồi đồng bộ và khi làm procedure thì khi nào cần ghi thì save sang con db ghi, khi cần đọc thì ghi vào con đọc, e nghe thấy ko hợp lý lắm, ko biết có bác nào có kinh nghiệm vụ chia db instance chỉ đọc chỉ ghi và khi làm procedure thì làm ntn để tăng hiệu suất ko ạ?
 
marmot said:
Em mới nghe ông sếp e nói về việc chạy song song 2 DB instance, 1 để đọc, 1 để ghi rồi đồng bộ và khi làm procedure thì khi nào cần ghi thì save sang con db ghi, khi cần đọc thì ghi vào con đọc, e nghe thấy ko hợp lý lắm, ko biết có bác nào có kinh nghiệm vụ chia db instance chỉ đọc chỉ ghi và khi làm procedure thì làm ntn để tăng hiệu suất ko ạ?
Click to expand...
song song 2 DB Instance => Đây là pattern nên phải có. Kể cả không dùng cloud thì Production cũng vẫn nên có 2 database luôn luôn synchronously replication ( 1 Primary, 1 Standby). Lỡ cái Primary crashed thì cái Standby được promoted lên làm Primary ngay. Ví dụ Oracle có Oracle Data Guard sync giữa 2 database, database thì dùng RAC (Real Application Cluster). Primary database sẽ đưa ra connection READ_WRITE, còn Standby Database thì cung cấp connection READ_ONLY. Trong code thì setup 2 connection, tuỳ tác vụ CUD thì dùng READ_WRITE còn R thì dùng READ_ONLY
 

Similar threads

buiduchanh1995
thắc mắc Cách thiết kế database cho hệ thống lớn
2
Replies
37
Views
3K
khonganhit19
khonganhit19
jerryno6
thắc mắc migrate data từ PROD sang DEV environment trên google cloud SQL for PostgreSQL
Replies
15
Views
873
Doan Minh Trung
Doan Minh Trung
qkhanhpro
thắc mắc AV nào cho home server?
Replies
0
Views
112
qkhanhpro
qkhanhpro
Nguyễn Minh Hà
thảo luận Giá vàng liên tục phá kỷ lục mới, còn có thể tiếp tục đầu tư không?
Replies
2
Views
158
Nguyễn Minh Hà
Nguyễn Minh Hà
Cigarette Smoking Man
Vì sao hơn 3 triệu hợp đồng bảo hiểm mất hiệu lực?
Replies
0
Views
187
Cigarette Smoking Man
Cigarette Smoking Man

Share this page

Back
Top