Thắc Mắc - Query Vào Database Liên Tục | Page 3 | TheNEXTvoz
Có thể bạn quan tâm
- Forums New posts
- Latests Featured content New posts New profile posts Latest activity
- New posts
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
- Forums
- Học tập & Sự nghiệp
- Lập trình / CNTT
- Thread starter Thread starter Trevor_Schmeler
- Start date Start date Jul 12, 2021
- 1
- 2
- 3
- 4
Go to page
Go Next Last
karenshii
Senior Member
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ậysao 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. 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
Click to expand...
Yurisha
Senior Member
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ậyright 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: Jul 15, 2021
captain Teemo siêu nhân
Junior Member
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
Last edited: Jul 15, 2021 
the_ruler
Đã tốn tiền
Level 1 của ETL thôi có gì đâu. Level 1: cronjob, interval
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á 
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_
Đã tốn tiền
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
Senior Member
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.
kaitoubg
Member
Ủ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...K
kissofdragon1211
Đã tốn tiền
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.
2TbP
Senior Member
10s mà reponse dưới 0.5s thì thoải mái con gà mái
Chơi Bời
Đã tốn tiền
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
Senior Member
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? Cchickeninabigworld_NT22
Junior Member
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) T Toidaidot93
Junior Member
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
The Man from Earth
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
The Man from Earth
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é. T
Toidaidot93
Junior Member
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
LuciferMorningStar00
The Man from Earth
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ẻ.
Vuanhhuy93
Senior Member
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
Junior Member
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
Senior Member
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 Prev
- 1
- 2
- 3
- 4
Go to page
Go Next Last You must log in or register to reply here.Similar threads
Ô tô tông liên hoàn xe máy khi chờ đèn đỏ ở Giảng Võ - Láng Hạ - Meowdolf Kitler
- Dec 15, 2025
- Điểm báo
thắc mắc Màn hình chớp tắt liên tục - BiKentz
- Nov 26, 2025
- GPU & Màn hình
Cầu Tiên Sơn liên tục 'sứt đầu mẻ trán' vì xe quá khổ mắc kẹt dưới gầm cầu - Ngô Bệnh Dĩ
- Dec 9, 2025
- Điểm báo
![Lan Già [Real]-v2025](https://data.voz.vn/avatars/s/2025/2025558.jpg?1722523383){kind=small}
L AI bước vào thành phố: Tương lai tiện nghi hay kỷ nguyên giám sát mới? - lavie_lavie
- Dec 19, 2025
- Điểm báo
Trải nghiệm mua sắm cực kì tồi tệ tại Xiaomi Offical ở Lazada và Shopee ( có hình) - Raikyo
- Dec 4, 2025
- Chuyện trò linh tinh™
Share: Facebook X (Twitter) LinkedIn Reddit Pinterest WhatsApp Share Link Thread statistics
Created Trevor_Schmeler, Jul 12, 2021 Last reply from FullStackFlutterGolang, Jun 8, 2023 Replies 68 Views 9,869Share this page
Facebook X (Twitter) LinkedIn Reddit Pinterest WhatsApp Share Link- Forums
- Học tập & Sự nghiệp
- Lập trình / CNTT
Từ khóa » Debezium Là Gì
-
Thay đổi Thu Thập Dữ Liệu Với Debezium: Hướng Dẫn đơn Giản, Phần 1
-
Cấu Hình Debezium Kết Nối Với SQL Server Bằng Docker - Techmaster
-
Tutorial :: Debezium Documentation
-
010: Apache Kafka Connect Concept - Viblo
-
Hướng Dẫn Cài đặt Và ứng Dụng Kafka Connect - VTS Engineering
-
MySQL CDC With Apache Kafka And Debezium - Clairvoyant
-
Có Bạn Nào Trong Group Mình đang Sử Dụng Kĩ Thuật CDC (Change ...
-
#157 - A Year And A Half With Debezium: CDC With MySQL | Revue
-
[Kafka-connect] Streaming The Data Of MySQL ... - NimTechnology
-
System Design Cơ Bản: Message Broker - TopDev
-
Thắc Mắc - Cách Sử Dụng Hệ Thống Data Change Capture (CDC) Cho ...
-
Giải Quyết Các Vấn đề Tích Hợp Bằng MySql Binlog — P2
-
Cách Tốt Nhất để Lấy Những Thay đổi Do Trigger Trong Database
-
Phân Loại Giữa Các Hệ Thống Message Queue | By Anh Le - Medium
-
Kafka Connect - Confluent Documentation
-
Debezium/connect - Docker Image