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

karenshii · 14/7/21

KiemTienKhongKho2022 đã nói:
Sao vào thread này toàn suggest Kafka Connect, Debezium chi cho phức tạp mà nặng nề vậy . 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

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

Yurisha · 14/7/21

KiemTienKhongKho2022 đã nói:
Sao vào thread này toàn suggest Kafka Connect, Debezium chi cho phức tạp mà nặng nề vậy . 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

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 ạ.

captain Teemo siêu nhân · 15/7/21

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

the_ruler · 15/7/21

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

BanhXe0_ · 20/7/21

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

vothevinh · 20/7/21

Yurisha đã nói:
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 ạ.

đâ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.

kaitoubg · 20/7/21

Ủa thím có thể stream các change event trong DB để stream việc thay đổi dữ liệu được mà.

Trevor_Schmeler đã nói:
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

kissofdragon1211 · 20/7/21

Trevor_Schmeler đã nói:
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

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.

2TbP · 21/7/21

10s mà reponse dưới 0.5s thì thoải mái con gà mái

Chơi Bời · 14/10/21

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

keeloren · 18/10/21

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?

chickeninabigworld_NT22 · 20/10/21

mình cũng thấy thắc mắc

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)

Toidaidot93 · 27/10/21

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.

LuciferMorningStar00 · 27/10/21

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.

LuciferMorningStar00 · 27/10/21

Toidaidot93 đã nói:
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.

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é.

Toidaidot93 · 27/10/21

LuciferMorningStar00 đã nói:
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é.

Ừ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

LuciferMorningStar00 · 27/10/21

Toidaidot93 đã nói:
Ừ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

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ẻ.

Vuanhhuy93 · 27/10/21

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.

marmot · 31/5/23

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 ạ?

dark_matter · 31/5/23

marmot đã nói:
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 ạ?

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

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

Senior Member

Senior Member

Junior Member

Đã tốn tiền

Đã tốn tiền

Senior Member

Member

Đã tốn tiền

Member

Đã tốn tiền

Senior Member

Junior Member

Junior Member

The Man from Earth

The Man from Earth

Junior Member

The Man from Earth

Senior Member

Junior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này