Gửi mọi người Group Telegream Wecommit Public Community : www.wecommit.com.vn/wecommitcommunity ,anh em có thể trao đổi những câu hỏi , vấn đề khi xem Video và kết nối với tôi trong Group nhé (trường hợp click trực tiếp bị lỗi thì ae copy link ra browser nhé)
Trong video này, Anh Huy chỉ nói cách họ làm sao để giải quyết vấn đề mà không nói ra tên của phương pháp đó. Cách họ làm gọi là Sharding architecture. Zookeeper(directory based sharding), key-based, range-based sharding chỉ là những cách để chia database. Hy vọng anh có thêm nhiều videos chia sẽ nhung kiến trúc và cách họ áp dụng trong thực tế.
Quả join ở phần ứng dụng thì bản chất cũng phải có dữ liệu đc query vào db . sau đó join xử lý dữ liệu dưới ứng dụng . Nói chung bài viết cũng ý nghĩa . Với lại em cũng từng làm các hệ thống lớn như vậy cũng chia nhỏ thêm nữa là query vào các database standby và chỉ insert vào master . Tối ưu nữa là cahe là kinh điển và index partion hợp lý. Có hệ thống hằng ngày hàng tuần tạo ra các bảng để phục vụ điều này thay vì partion
Ở Việt Nam thì đa phần là chỉ cần chia mức độ Read sang hệ thống dự phòng (Slave). Nhưng ở các bài toán làm dữ liệu đa quốc gia, yêu cầu đọc ghi rất cao thì sẽ cần tới việc sử dụng kiến trúc phân tán như trong Video mình nói. Thật ra thì trong mô hình trong video, các database đều được sử dụng Master - Slave luôn anh em nhé.
Cảm ơn sự ủng hộ của anh em. Mình rất vui vì thấy nó mang lại giá trị cho anh em. Anh em đăng ký kênh để nhận thông báo các video mới nhất của mình nhé
Em cảm ơn anh. Kênh của anh rất nhiều kiến thức hữu ích và thú vị. Anh có thể làm video về tối ưu csdl cho các doanh nghiệp hay dùng với SAP được không ah?
em thấy khá giống cách tiếp cận của môn cơ sở dữ liệu phân tán ở trường em, thầy sẽ dùng 2 phương pháp đó là phân mảnh ngang và phân mảnh dọc để chia nhỏ dữ liệu ra
Mình có câu hỏi về tách mỗi bảng ở 1 database khác nhau: 1. JOIN bảng ở tầng ứng dụng nôm na là join bằng code ngôn ngữ lập trình đúng không? Mình có vài câu hỏi về việc tách 1 bảng ra ở nhiều database khác nhau. 1. 1 database có 1 bảng Comments 300GB thì có khác 1 database có 2 bảng Comments , mỗi bảng 150GB không? 2. Ở phút 7:54 mình thấy 2 bảng trong 1 database, anh nói các bảng sau khi tách có cùng tên, vậy 2 bảng trong 1 database này có cùng tên không? 3. Mình có thể chia theo cả chiều ngang và chiều dọc đúng không? Một câu hỏi thêm: anh có thể chia sẻ cách tìm kiếm thông tin về cấu trúc hệ thống, công nghệ sử dụng, ngôn ngữ mà 1 trang web, 1 ứng dụng,...sử dụng được không? Thông tin trong video anh tìm hay quá, mình cũng search tiếng Anh nhưng không có kết quả mong muốn. Xin cảm ơn anh.
Join ở tầng ứng dụng nghĩa là thông qua code tạo ra truy vấn, load vô bộ nhớ. Sau đó code đọc cái đó rồi tự xử lý hiểu nôm na là z. Mình đoán các framwork web hiện đại chắc có hỗ trợ chuyện đó khi giao tiếp với database. Cái này sâu quá nên cũng ko có thời gian tìm hiểu kĩ.
ơi cát chầm tít chầm tít ơi cát mao cát mao . bằng tình cảm yêu thương, chúc anh muôn đời bình an, chúc anh sống trong ánh sáng hào quang của 10 phương chư phật! kiến thức của anh hay quá thực ra kiến thức có nhưng anh là người tóm gọn và truyền lại kiến thức hay anh ạ
Cho em hỏi, chia các bảng vào từng server khác nhau như thế thì làm sao tạo khóa chính khóa ngoại được nhỉ, rồi với các công nghệ ORM như hibernate, JPA của spring boot phải adapt như thế nào, em là sinh viên nên em kiến thức của em còn hạn hẹp ạ, mong được giải đáp
bên em trước đây cũng đã phải tối ưu như vậy, đánh đổi lại bằng việc dữ liệu có thể không chính xác nữa, các kiểu filter, sort cũng sấp mặt và phải kết hợp các tech, sử dụng uuid thay cho id, Outsource thì sấp mặt chứ Prod thì em k biết, =)) hóng mọi người góp ý ạ
Với CSDL như mysql thì khi dữ liệu của db lên đến hàng TB là xử lý chậm, nếu giải pháp là sử dụng những csdl như oracle thì như thế nào(lý do họ vẫn chọn mysql có phải do chi phí không?)
dạ anh ơi, anh cho em hỏi xíu là đẩy phần join lên tầng application nghĩa là mình không join bằng lệnh mysql mà join bằng code chạy nhiều thread hoặc async rồi loop để join hay như thế nào ạ?. Em cảm ơn anh nhiều!
Cho em hỏi ngu là việc tách nhỏ DB theo từng năm ra từng server riêng vậy thì việc search theo từ khóa sẽ như thế nào? Làm sao người dùng nhập tìm kiếm tên bài viết mà zoo keeper biết tìm kiếm ở server DB nào và tối ưu như thế nào vậy anh?
việc tách DB ra nhiều DB nhỏ, lúc dự án nhỏ mình chưa thấy, khi dự án phình to thì mới thấy đc thì lúc này chia có vấn đề gì không vậy ad. Chưa kể nếu tách ra như vậy việc lấy data liên bảng sẽ rất khó (join) thì mình giải quyết thế nào vậy. Thanks bro
hệ thống càng lớn thì càng phải cân nhắc khi chuyển đổi anh em ah. Chuyển đổi nó có rất nhiều chi phí ẩn a rủi ro, đông thơi có cả yếu tố ảnh hưởng tới khách hàng khi chuyển đổi nữa, ví dụ: downtime
@@havanlong2206 tức là uuid thường mình sẽ tạo ra trước khi tách bảng rồi ấy bạn nhỉ. T đang nghĩ nếu baayh muốn tạo ra uuid cho 1 bảng chưa có thì mình sẽ kiểu kết hợp thời gian bản ghi đó được tạo + 1 vài ký tự random có ok ko nhỉ ??
cho mình hỏi nếu chia nhỏ cơ sở dữ liệu vậy thì ứng dụng cũng phải sửa lại phải không? làm sao để đảm bảo tính toàn vẹn của các tables trong môi trường phân tán
Ah, có 1 lưu ý rằng: khi thực hiện phân tán database sử dụng kỹ thuật sharding, nếu ứng dụng mà tìm kiếm không có sharding key là toạch nhé anh em (vì nó phải tìm ở tất cả các database)
thường những thông tin về cấu trúc cũng như concept mà các công ty công nghệ đang sử dụng có thể tìm kiếm ở đâu nhỉ, cũng muốn biết người ta đang áp dụng những gì mà tìm ra ít kết quả quá quá, cảm ơn anh
các nội dung này thường rải rác, đọc ở nhiều diễn đàn khác nhau như reddit, quora, một số thông tin mình có tổng hợp từ các chia sẻ trên linkedin từ các kỹ sư đang làm việc tại các Big tech anh em ah
đọc trong documentations của các db, chẳng hạn với mongodb thì docs có hết các cách triển khai hệ thống, sau đó bạn sẽ nắm đc các keyword để tìm hiểu cách cài đặt cụ thể từ người khác nữa. ko cần phải đọc mấy bài nói cách làm của cty này kia đâu vì có đọc cũng chả hiểu đc, quan trọng bạn phải nắm được lý thuyết nền tảng trc rồi làm dần từ đơn giản nhất. mấy khái niệm về partitioning hay sharding, indexing ko biết thì 🤷
@@HongHaiNguyenx đọc -> k hiểu -> tìm hiểu về các keyword nói như ông thì phải hiểu hết tất cả các công nghẹ trên đời rồi mới đi đọc mấy cái blog kiểu này chắc
@@minhquangngo8875 trc h t toàn làm vậy, ko thì sao bắt kịp 15 năm vừa qua. đúng là phải hiểu từng keyword đó, hồi mới ra trường t cũng phải đọc nhiều lắm, giờ cũng có ngừng đâu, vừa rồi còn làm audit source code dapp eth solidity mà cũng tự học đấy. bạn ko có kiến thức cơ bản thì có vào cty họ cũng ko thể đào tạo bạn đc.
tư duy chia nhỏ là gốc rễ của tối ưu. Bản thân mình cũng đã làm tối ưu nhiều năm, chỉ một số ít người (trong phạm vi những dự án mình từng làm) thật sự hiểu và làm được phần chia nhỏ này ngon nghẻ.
Về tư duy thì Partition cũng là tách nhỏ các Table thành những phần riêng biệt (để tăng tốc hiệu năng), tuy nhiên các Partition đó đều nằm trên 1 database và cùng thuộc 1 server. Tại lúc này nó vẫn bị giới hạn. Tư duy trong video mình nói là tách thành nhiều server riêng biệt.
Gửi mọi người Group Telegream Wecommit Public Community : www.wecommit.com.vn/wecommitcommunity ,anh em có thể trao đổi những câu hỏi , vấn đề khi xem Video và kết nối với tôi trong Group nhé (trường hợp click trực tiếp bị lỗi thì ae copy link ra browser nhé)
Trong video này, Anh Huy chỉ nói cách họ làm sao để giải quyết vấn đề mà không nói ra tên của phương pháp đó. Cách họ làm gọi là Sharding architecture. Zookeeper(directory based sharding), key-based, range-based sharding chỉ là những cách để chia database. Hy vọng anh có thêm nhiều videos chia sẽ nhung kiến trúc và cách họ áp dụng trong thực tế.
đúng chuyên gia DB nói chuyện nghe khác bọt thật, em thật sự hiếm khi nghe mấy ông thợ code youtube VN, có mỗi anh nên em xem.
Quả join ở phần ứng dụng thì bản chất cũng phải có dữ liệu đc query vào db . sau đó join xử lý dữ liệu dưới ứng dụng .
Nói chung bài viết cũng ý nghĩa .
Với lại em cũng từng làm các hệ thống lớn như vậy cũng chia nhỏ thêm nữa là query vào các database standby và chỉ insert vào master .
Tối ưu nữa là cahe là kinh điển và index partion hợp lý.
Có hệ thống hằng ngày hàng tuần tạo ra các bảng để phục vụ điều này thay vì partion
Ở Việt Nam thì đa phần là chỉ cần chia mức độ Read sang hệ thống dự phòng (Slave).
Nhưng ở các bài toán làm dữ liệu đa quốc gia, yêu cầu đọc ghi rất cao thì sẽ cần tới việc sử dụng kiến trúc phân tán như trong Video mình nói.
Thật ra thì trong mô hình trong video, các database đều được sử dụng Master - Slave luôn anh em nhé.
Chắc chưa chưa đủ lớn rồi :D
Mặc dù chưa hiểu lắm nhưng cảm ơn anh đã chỉ đường!
Tuyệt vời quá anh ơi. Video cực kỳ thực tế và hữu ích. Giá trị mang lại lớn hơn rất nhiều những clip kiểu tutorial getting started
Cảm ơn sự ủng hộ của anh em. Mình rất vui vì thấy nó mang lại giá trị cho anh em. Anh em đăng ký kênh để nhận thông báo các video mới nhất của mình nhé
Rất bổ ích. Mình nhớ chia nhỏ để nhẹ như làm excel. Còn xử lý joi thì chắc chọn một nơi trung gian và ngay trên giao diện ẩn. Bạn xem😄?
Bạn đã chia sẽ kiến thức thiết kế db quá hay. Rất cảm ơn bạn.
Em cảm ơn anh. Kênh của anh rất nhiều kiến thức hữu ích và thú vị. Anh có thể làm video về tối ưu csdl cho các doanh nghiệp hay dùng với SAP được không ah?
em thấy khá giống cách tiếp cận của môn cơ sở dữ liệu phân tán ở trường em, thầy sẽ dùng 2 phương pháp đó là phân mảnh ngang và phân mảnh dọc để chia nhỏ dữ liệu ra
Thầy Kỳ Thư à
đúng rồi đó em.
Những thứ học trên trường đều là các cấu thành để xây dựng nên những hệ thống lớn, phức tạp đấy.
Học chắc các kiến thức em nhé.
Cảm ơn anh, video rất hay và dễ hiểu, bổ ích
Mình có câu hỏi về tách mỗi bảng ở 1 database khác nhau:
1. JOIN bảng ở tầng ứng dụng nôm na là join bằng code ngôn ngữ lập trình đúng không?
Mình có vài câu hỏi về việc tách 1 bảng ra ở nhiều database khác nhau.
1. 1 database có 1 bảng Comments 300GB thì có khác 1 database có 2 bảng Comments , mỗi bảng 150GB không?
2. Ở phút 7:54 mình thấy 2 bảng trong 1 database, anh nói các bảng sau khi tách có cùng tên, vậy 2 bảng trong 1 database này có cùng tên không?
3. Mình có thể chia theo cả chiều ngang và chiều dọc đúng không?
Một câu hỏi thêm: anh có thể chia sẻ cách tìm kiếm thông tin về cấu trúc hệ thống, công nghệ sử dụng, ngôn ngữ mà 1 trang web, 1 ứng dụng,...sử dụng được không? Thông tin trong video anh tìm hay quá, mình cũng search tiếng Anh nhưng không có kết quả mong muốn.
Xin cảm ơn anh.
thay vì 1 thằng nó tìm comment trong 300GB thì bây h sẽ có 2 thằng tìm comment nhưng mỗi thằng chỉ cần tìm trong 150GB
Join ở tầng ứng dụng nghĩa là thông qua code tạo ra truy vấn, load vô bộ nhớ. Sau đó code đọc cái đó rồi tự xử lý hiểu nôm na là z. Mình đoán các framwork web hiện đại chắc có hỗ trợ chuyện đó khi giao tiếp với database. Cái này sâu quá nên cũng ko có thời gian tìm hiểu kĩ.
Hay quá anh ơi, hi vọng anh sẽ còn ra nhiều video về việc phân tích csdl của các hệ thống lớn thêm nữa. Thank bro!
Cảm ơn sự ủng hộ của anh em. Anh em đăng ký kênh nhé, thời gian tới mình có nhiều thứ hay ho sẽ chia sẻ cho mọi người
Anh Huy hoặc ai đó có thể cho tôi ví dụ làm sao để thực hiện JOIN tại application level? Xin cảm ơn
ơi cát chầm tít chầm tít ơi cát mao cát mao . bằng tình cảm yêu thương, chúc anh muôn đời bình an, chúc anh sống trong ánh sáng hào quang của 10 phương chư phật! kiến thức của anh hay quá thực ra kiến thức có nhưng anh là người tóm gọn và truyền lại kiến thức hay anh ạ
cảm ơn người anh em nhé
Thực tế triển khai chắc chắn là rất thử thách.
Mình nghĩ ứng dụng connect nhiều db sẽ tốn nhiều thời gian để lấy dữ liệu từ nguồn về.
bài toán tối ưu luôn có thử thách và rất thú vị anh em ah
Anh Huy có thể giải thích giúp em kỹ hơn phần join trên phần ứng dụng khi tách bảng ra nhiều server được không ạ. Em cảm ơn anh
Cho em hỏi, chia các bảng vào từng server khác nhau như thế thì làm sao tạo khóa chính khóa ngoại được nhỉ, rồi với các công nghệ ORM như hibernate, JPA của spring boot phải adapt như thế nào, em là sinh viên nên em kiến thức của em còn hạn hẹp ạ, mong được giải đáp
bên em trước đây cũng đã phải tối ưu như vậy, đánh đổi lại bằng việc dữ liệu có thể không chính xác nữa, các kiểu filter, sort cũng sấp mặt và phải kết hợp các tech, sử dụng uuid thay cho id, Outsource thì sấp mặt chứ Prod thì em k biết, =)) hóng mọi người góp ý ạ
Với CSDL như mysql thì khi dữ liệu của db lên đến hàng TB là xử lý chậm, nếu giải pháp là sử dụng những csdl như oracle thì như thế nào(lý do họ vẫn chọn mysql có phải do chi phí không?)
Việc chia nhỏ ntn thì giải quyết bài toán tìm kiếm như thế nào v anh?, vd tạo tài khoản mới email ko trùng, username ko trùng???
Giải thích rất tường minh, video hay lắm anh.
cảm ơn anh em.
Chúc anh em năm mới thật tuyệt vời nhé
Hay quá, anh làm thêm video về cái mem cache Redis đi anh
Join ở ứng dụng có cơ chế như thế nào vậy anh
cho em hỏi cách mình đồng bộ dữ liệu ở các server khác nhau nằm trên những vị trí địa lý khác nhau sao cho hiệu quả ạ, em cám ơn.
Quá hay.
Video hay a à
Rất bổ ích tks anh❤
làm thêm bài về telegram với a
Anh em đăng ký kênh nhé, sắp tới mình cũng còn nhiều nội dung thú vị chia sẻ cho mọi người.
Cảm ơn anh em đã quan tâm và ủng hộ nhé.
Hay quá a ❤
thank anh chia se
A Huy ơi, ban đâu Table chưa được partition db, nhưng sau này có nhiều data lên rồi thì mình có thể chia nhỏ được không ạ. E đang nói về Postgresql
thoái mái anh em nhé. Anh em chỉnh lại table partition sau cũng được.
A Huy có khoá học SQL online không ạ?
Anh em tham khảo khoá học này nhé Từ điển tối ưu 100x hiệu năng
Link: wecommit.com.vn/tu-dien-toi-uu-100x-hieu-nang/
ở đây tách các bảng ra server riêng là tương ứng với việc dưng lên 1 con service riêng ak anh?
Đúng rồi anh em, database trên server riêng biệt luôn nhé.
dạ anh ơi, anh cho em hỏi xíu là đẩy phần join lên tầng application nghĩa là mình không join bằng lệnh mysql mà join bằng code chạy nhiều thread hoặc async rồi loop để join hay như thế nào ạ?. Em cảm ơn anh nhiều!
Theo mình nghĩ là vẫn join trên mysql giống như các hệ thống c..ờ b..ạc online tà…i sỉ.,u chẳn lẻ thấy join trên application
Hay quá a🎉🎉🎉
cảm ơn anh em đã ủng hộ kênh của mình nhé
Cho em hỏi ngu là việc tách nhỏ DB theo từng năm ra từng server riêng vậy thì việc search theo từ khóa sẽ như thế nào? Làm sao người dùng nhập tìm kiếm tên bài viết mà zoo keeper biết tìm kiếm ở server DB nào và tối ưu như thế nào vậy anh?
phần này em tìm hiểu về lý thuyết của kỹ thuật sharding database sẽ thấy rõ hơn nhé
việc tách DB ra nhiều DB nhỏ, lúc dự án nhỏ mình chưa thấy, khi dự án phình to thì mới thấy đc thì lúc này chia có vấn đề gì không vậy ad. Chưa kể nếu tách ra như vậy việc lấy data liên bảng sẽ rất khó (join) thì mình giải quyết thế nào vậy. Thanks bro
cảm ơn anh em đã ủng hộ kênh của mình nhé
Cho e hỏi. Tại sao họ ko triển khai hadoop luôn mà lại phân tán kiểu phân nhỏ mà dùng tiếp mySQL?
hệ thống càng lớn thì càng phải cân nhắc khi chuyển đổi anh em ah. Chuyển đổi nó có rất nhiều chi phí ẩn a rủi ro, đông thơi có cả yếu tố ảnh hưởng tới khách hàng khi chuyển đổi nữa, ví dụ: downtime
Khi chia nhỏ bảng thành các bảng con cùng tên thì chỉ số ID nó đánh như thế nào ạ
dùng uuid thay cho id nha bạn, nếu như chưa triển khai uuid thì sẽ rất vất vả đây
@@havanlong2206 tức là uuid thường mình sẽ tạo ra trước khi tách bảng rồi ấy bạn nhỉ. T đang nghĩ nếu baayh muốn tạo ra uuid cho 1 bảng chưa có thì mình sẽ kiểu kết hợp thời gian bản ghi đó được tạo + 1 vài ký tự random có ok ko nhỉ ??
cho mình hỏi nếu chia nhỏ cơ sở dữ liệu vậy thì ứng dụng cũng phải sửa lại phải không? làm sao để đảm bảo tính toàn vẹn của các tables trong môi trường phân tán
Ah, có 1 lưu ý rằng: khi thực hiện phân tán database sử dụng kỹ thuật sharding, nếu ứng dụng mà tìm kiếm không có sharding key là toạch nhé anh em (vì nó phải tìm ở tất cả các database)
muốn thống kê báo cáo thì họ dùng công nghệ nào vậy ạ(e nghĩ họ dùng DWH)
các hệ thống lớn hiện tại sẽ có xu hướng xây dựng Data Lake và DWH anh em nhé
nếu được bạn làm video hướng dẫn deploy PostgREST và series lập trình PL/pgSQL nữa nha, mình cảm ơn
Các anh cho em hỏi là e muốn tìm kiếm 1 danh sách các công nghệ kiểu như zookeeper thì có website nào không ạ ? Em xin cám ơn ạ
Bạn thử xem cơ bản về hadoop và apache ecosystem xem
mình đang làm 1 chuỗi các video để chia sẻ về những công nghệ, kỹ thuật đang được ứng dụng thực tế hiện nay. Có thể sẽ giúp ích được cho anh em đấy.
thường những thông tin về cấu trúc cũng như concept mà các công ty công nghệ đang sử dụng có thể tìm kiếm ở đâu nhỉ, cũng muốn biết người ta đang áp dụng những gì mà tìm ra ít kết quả quá quá, cảm ơn anh
các nội dung này thường rải rác, đọc ở nhiều diễn đàn khác nhau như reddit, quora, một số thông tin mình có tổng hợp từ các chia sẻ trên linkedin từ các kỹ sư đang làm việc tại các Big tech anh em ah
đọc trong documentations của các db, chẳng hạn với mongodb thì docs có hết các cách triển khai hệ thống, sau đó bạn sẽ nắm đc các keyword để tìm hiểu cách cài đặt cụ thể từ người khác nữa. ko cần phải đọc mấy bài nói cách làm của cty này kia đâu vì có đọc cũng chả hiểu đc, quan trọng bạn phải nắm được lý thuyết nền tảng trc rồi làm dần từ đơn giản nhất. mấy khái niệm về partitioning hay sharding, indexing ko biết thì 🤷
@@HongHaiNguyenx đọc -> k hiểu -> tìm hiểu về các keyword
nói như ông thì phải hiểu hết tất cả các công nghẹ trên đời rồi mới đi đọc mấy cái blog kiểu này chắc
@@minhquangngo8875 trc h t toàn làm vậy, ko thì sao bắt kịp 15 năm vừa qua. đúng là phải hiểu từng keyword đó, hồi mới ra trường t cũng phải đọc nhiều lắm, giờ cũng có ngừng đâu, vừa rồi còn làm audit source code dapp eth solidity mà cũng tự học đấy. bạn ko có kiến thức cơ bản thì có vào cty họ cũng ko thể đào tạo bạn đc.
Fb thì sao ạ. Cũng chia vậy à bác
fb để một video khác mình sẽ phân tích với anh em nhé
Bổ ích
Cơ chế backup ntn nhỉ chắc backup phần cứng =))
đi kèm với từng database lại có sử dụng cơ chế dạng Master - slave. Đáp ứng hoàn toàn về tính sẵn sàng anh em ah
A có thể cụ thể phần JOIN ở ứng dụng thay vì ở database là như nào không anh ?
thay vì bạn dùng câu query join thì mình chuyển qua dùng where in
where in 2 phát ở database. Sau đó code nhận dữ liệu load vô ram rồi tự xử.
thanks anh
Cảm ơn sự ủng hộ của anh em nhé.
Anh em đăng ký kênh để sớm nhận thông báo các nội dung thú vị sắp tới nha.
trình bày rất là dài dòng, có thể rút gọn video từ 11p xuống 2p được . cái quan trọng nhất thì ko nói . tư duy chia nhỏ thì sinh viên năm 2 cũng biết
tư duy chia nhỏ là gốc rễ của tối ưu.
Bản thân mình cũng đã làm tối ưu nhiều năm, chỉ một số ít người (trong phạm vi những dự án mình từng làm) thật sự hiểu và làm được phần chia nhỏ này ngon nghẻ.
Mình thấy nói như này thấy hiểu hơn á
hờ hờ 😂
hệ thống mình như quần què mà hàng tháng vẫn chịu tải bằng nửa quora 🤣
ở đây k có quần què, xóa comment giờ. :)
nó khác gì partition nhỉ
Partition vẫn nằm trên cùng 1 server, không giải quyết được việc nghẽn hiệu năng
Về tư duy thì Partition cũng là tách nhỏ các Table thành những phần riêng biệt (để tăng tốc hiệu năng), tuy nhiên các Partition đó đều nằm trên 1 database và cùng thuộc 1 server. Tại lúc này nó vẫn bị giới hạn.
Tư duy trong video mình nói là tách thành nhiều server riêng biệt.
Phá vỡ cấu trúc nhằm mục đích tối ưu tốc độ