katoshi
Senior Member
MySQL nha
số rows thì nhiều vl nhé. Tôi sẽ test vs mẫu 1tr và 10tr vs 50tr.
Cột thì cỡ <10 thôi.
Tôi select trên field có index & 1 lệnh có join đơn giản nữa.
VD: SELECT id, age,gender from user WHERE age >2 chẳng hạn
thảo luận Vấn đề về separate Repository/Service/Controller
- Người tạo chủ đề soledad86
- Ngày bắt đầu
số rows thì nhiều vl nhé. Tôi sẽ test vs mẫu 1tr và 10tr vs 50tr.
Cột thì cỡ <10 thôi.
Tôi select trên field có index & 1 lệnh có join đơn giản nữa.
VD: SELECT id, age,gender from user WHERE age >2 chẳng hạn
quandaso
Senior Member
Sao lại chuyển đề tài sang sql rồi =]]
Nói vụ này nói chung select * ko phải lúc nào cũng tệ.
Nhưng ông nào bảo chỉ tốn có tí memory là sai rồi nhé, ví dụ tôi có db images chứa raw image bên trong, mỗi image cỡ 1->5 MB. Tôi cần map 10k record để export excel chẳng hạn. Lúc đấy SELECT* chả vỡ mồm à
Nói vụ này nói chung select * ko phải lúc nào cũng tệ.
Nhưng ông nào bảo chỉ tốn có tí memory là sai rồi nhé, ví dụ tôi có db images chứa raw image bên trong, mỗi image cỡ 1->5 MB. Tôi cần map 10k record để export excel chẳng hạn. Lúc đấy SELECT* chả vỡ mồm à
katoshi
Senior Member
chơi luôn . :3
katoshi
Senior Member
Đồng ý là select * ko phải tệ ở tất cả trường hợpSao lại chuyển đề tài sang sql rồi =]]
Nói vụ này nói chung select * ko phải lúc nào cũng tệ.
Nhưng ông nào bảo chỉ tốn có tí memory là sai rồi nhé, ví dụ tôi có db images chứa raw image bên trong, mỗi image cỡ 1->5 MB. Tôi cần map 10k record để export excel chẳng hạn. Lúc đấy SELECT* chả vỡ mồm à
Nhưng ông kia chém quá mà.
Dám phán 0ms ko phân biệt trường hợp luôn mà. ko cần raw images ( vì ai mà làm thế) , chỉ cần field đó là image_urls thôi cũng thấy đc
quandaso
Senior Member
Ai bảo ko ai làm thế, ảnh bên y tế vẫn lưu raw image bình thường nhé. Nó hơi ngu si nhưng đc cái quản lí nó dễ, phân quyền các kiểu nữa
katoshi
Senior Member
Rồi, đồng ý.
Vẫn có người làm, nhưng cách làm tôi đánh giá là hơi ngu.
gaveezy
Senior Member
4nh7i3m
Senior Member
@katoshi @quandaso tôi sẽ vui hơn khi các anh đọc kỹ bài viết của tôi và theo dõi các bài viết trước của tôi xem tôi đang cố gắng nói về cái gì. Vui lòng đừng bỏ qua ngữ cảnh của bài viết vì như thế chúng ta sẽ chẳng đi về đâu. Hãy để tôi còn hứng mà nói chuyện với các anh.
Thay vì cố gắng hiểu cái ý của tôi thì các anh chỉ thích thú với việc bới móc người khác hơn là chia sẻ kiến thức.
Còn nếu các anh muốn extreme case với việc các anh nhét binary dữ liệu vào dòng thì chúng ta sẽ mở rộng thảo luận về việc này với extreme case này. Còn tôi đang nói là về những case bình thường và thông thường nhất. Mà mục đích ban đầu chỉ là tôi giải thích tại sao phải cần service để wrap repo. Các anh đừng lái quá xa.
Bé rì ga.
Thay vì cố gắng hiểu cái ý của tôi thì các anh chỉ thích thú với việc bới móc người khác hơn là chia sẻ kiến thức.
Còn nếu các anh muốn extreme case với việc các anh nhét binary dữ liệu vào dòng thì chúng ta sẽ mở rộng thảo luận về việc này với extreme case này. Còn tôi đang nói là về những case bình thường và thông thường nhất. Mà mục đích ban đầu chỉ là tôi giải thích tại sao phải cần service để wrap repo. Các anh đừng lái quá xa.
Bé rì ga.
4nh7i3m
Senior Member
Cám ơn bạn. Bạn cho cái definition của table là đẹp. Nếu được cho kiểu Server nữa để mọi người dễ tham khảo.
gaveezy
Senior Member
mình nói ở trên bảng tầm 15 cột đấy, không có cột nào dài đâu, tối đa VARCHAR(128) thôi, cấu hình thì CloudSQL instance yếu nhất (môi trường DEV)
4nh7i3m
Senior Member
@gaveezy: Rồi cám ơn bạn rất nhiều luôn. Như vậy tôi đã bị đập vào mặt là execution lệch 5ms và fetch time là 20ms. Như tôi chém gió là 0ms thì là "xạo lìn" (không phải tôi cố tình "xạo lìn" mà tôi test trên database tôi có đếch hiểu sao nó có 0ms (execution time) thôi. Tôi đã lựa cái bảng to nhất tôi có rồi).
Giờ tôi đợi tiếp anh @katoshi với anh @quandaso chứng minh tiếp là lệch khoảng bao nhiêu ms nũa.
Vậy đúng như ý tôi muốn hỏi và chứng minh giữa select * với select fied
@Edit: Tôi tìm ra lỗi của tôi rồi. Trên tool nó hiện 00:00:00 mà tôi đọc thành 00:00:00.0000. Xin lỗi anh em tức là có lệch vài ms. Nhưng tôi vẫn để bài viết như cũ không sửa nhé.
Giờ tôi đợi tiếp anh @katoshi với anh @quandaso chứng minh tiếp là lệch khoảng bao nhiêu ms nũa.
Vậy đúng như ý tôi muốn hỏi và chứng minh giữa select * với select fied
@Edit: Tôi tìm ra lỗi của tôi rồi. Trên tool nó hiện 00:00:00 mà tôi đọc thành 00:00:00.0000. Xin lỗi anh em tức là có lệch vài ms. Nhưng tôi vẫn để bài viết như cũ không sửa nhé.
Sửa lần cuối:
quandaso
Senior Member
Vài giây là sao, đối với tôi vài giây lệch là hệ thống treo cmnr, thậm chí response trả về > 100ms thôi đã là không được rồi. Khi hệ thống nó scale lên 15M/20M request trên ngày ông sẽ hiểu dù 20ms nó đã đáng giá như nào.
Tôi ko biết ông đã vận hành hệ thống bao giờ chưa, nếu chưa tôi quay lại cái video cho ông mở rộng tầm mắt, khi select * 1 triệu bản ghi và select id nó khác nhau nhiều như thế nào
4nh7i3m
Senior Member
@quandaso Tôi đã nói ở trên nếu ông bỏ ý mà bới lông tìm vết cố tình bỏ ý thì tôi không nói nữa vì đó là tốn thời gian của tôi.
Tôi chỉ nói vấn đề trả về full entity trong repo là bình thường với câu lệnh select * from table where id vì nó không lệch nhiều để mà cần phải select field và phức tạp hóa code lên để thực hiện các lệnh select fields. Chỉ trừ các hàm cho report thì mới cần như thế mà tôi cũng đã ghi ở trên rõ ràng.
Còn ông và ông kia thì cố tình bẻ câu nói của tôi đi thành select * from table và select fields from table để chứng tỏ tôi "ngu" không biết gì thì ok fine. Các anh hoàn toàn chính xác! Như ông làm cái ví dụ limit 1.000.000 để làm gì? Tôi có nói là câu lệnh "select * from table limit 1000000" với "select fields from table limit 100000" là lệch nhau ít đâu?
Tôi chỉ nói vấn đề trả về full entity trong repo là bình thường với câu lệnh select * from table where id vì nó không lệch nhiều để mà cần phải select field và phức tạp hóa code lên để thực hiện các lệnh select fields. Chỉ trừ các hàm cho report thì mới cần như thế mà tôi cũng đã ghi ở trên rõ ràng.
Còn ông và ông kia thì cố tình bẻ câu nói của tôi đi thành select * from table và select fields from table để chứng tỏ tôi "ngu" không biết gì thì ok fine. Các anh hoàn toàn chính xác! Như ông làm cái ví dụ limit 1.000.000 để làm gì? Tôi có nói là câu lệnh "select * from table limit 1000000" với "select fields from table limit 100000" là lệch nhau ít đâu?
Tôi không biết anh dùng time ở đây là time gì? Nhưng không, tôi không làm được như anh. Mà cả thằng Azure và Google Cloud tôi đang xài cũng đếch làm được như thế vì tùy trường hợp có nhanh có chậm chứ tôi không có cái timeout 100ms ở các project mà tôi đang làm. Nếu được anh cho tôi xin thông tin của anh. Để tôi liên lạc đội recuriter bên VN có thể công ty tôi làm sẽ rất thích anh đấy. Mịa tụi HR nó toàn la kiếm không ra người giỏi mà tôi lên đây toàn là siêu nhơn không.
Nipin
Member
gớm anh to mồm quá cho nên tôi vào đây kháy anh phát, chứ mấy bạn đầu thớt chắc tôi cũng lười lãng phí thời gian
gần đây tôi khuyến khích công ty thằng bạn đổi từ aws sang ovh cho rẻ. kết quả là cái database của nó bị ransomware sau hai nốt nhạc.
nguyên nhân cho các bạn tự nhận expert tự đoán
thực ra sửa thì đơn giản vãi ra, trang chủ của mongodb nó có luôn, nhưng tới 2020 vẫn còn người dính ransomware của mongodb thì đủ biết là nó vẫn là vấn đề. // các bạn có thể google 2 từ khoá kết hợp để xem kết quả
người ta dùng cái cũ (sql) không phải là sợ đổi cái mới, mà nhiều khi đơn giản là vì cái trước họ hiểu rõ hết từ trước ra sau, gặp hết các phốt rồi họ tự tin, cái mới hơn họ chưa chuẩn bị sẵn sàng cho nên họ lưỡng lự không muốn chuyển thôi.
có phải chỉ là đổi sang cái giải pháp mới đâu, còn việc fine-tune thế nào cho nó ra full potential, ra lỗi thì fix thế nào recover ra sao, optimize ra sao migrate thế nào... cả đống thứ nữa, trong khi cái sql bản chất nó chả có lỗi vẹo gì tại sao phải đổi.
mà nói ngược lại, tuy sql nó superior hơn cơ mà chỉ vì nó khó hơn chút cho nên vô số thằng cố đấm ăn xôi dùng nosql dù đíu hợp tôi gặp còn nhiều hơn. thuyết phục kiểu gì cũng không nghe
mỗi cái rdbms nó behavior khác nhau, thậm chí mỗi version khác nhau, cái này đã từng là vấn đề, stackoverflow vẫn còn vài thread. tất nhiên có thể ý anh bảo là bây giờ mấy cái rdbms phổ biến hiện đại nó đều optimize cho case này rồi thì tôi đồng ý, cơ mà anh đíu thể loại trừ trường hợp thằng dev vẫn phải maintain cái db version cũ từ đời tống đúng không.
gớm anh nói là anh test bằng cái gì, bằng cái máy bàn của anh cpu 5Ghz ssd pcie4 500k random iops hay cái hdd cọc cạch cổ lỗ sĩ nào đó trên server xeon 2Ghz? tất nhiên giờ server nó cũng giàu rồi ssd đầy rẫy amd rome có hết, cơ mà lại lần nữa anh dùng dẫn chứng anedotical, rất không ổn. mà thư viện orm cho phép select some fields cũng thiếu gì, tuỳ nhu cầu mà select full hay pluck một vài cái đủ nhu cầu thôi.
serialize/deserialize cũng không phải là cost free, đặc biệt nếu dính vào mấy cái text field hoặc blob field to.
à mà nitpick tí thôi chứ xem kết luận thì không sai mấy trừ vụ nosql
)cơ mà tôi cũng là người ủng hộ dùng ORM của mấy ngôn ngữ bậc đủ cao (không phải là của c# hay java rẻ rách) mấy cái đủ cao này nó hỗ trợ hết việc generate query ngon cho các bạn rồi, có dùng raw sql thì tôi cũng chỉ dùng fragment trong một cái query builder bằng chained function sẵn chứ đíu bao giờ có chuyện tôi viết raw sql từ đầu tới cuối.
phải viết raw sql lằng nhằng thì quan điểm của tôi là do thiết kế db ngu hoặc là do dùng ngôn ngữ ngu
4nh7i3m
Senior Member
@Nipin: Anh gì ơi, tôi cũng chả biết anh đang chửi hay khen tôi nữa. Anh viết rõ dài nhưng tôi đọc không hiểu anh muốn nói gì. Chắc là chửi tôi ngu viết code không tối ưu (chắc vậy) hay là sao? Vì anh nêu các trường hợp server cũ, máy cũ, mạng yếu, đi làm bị sếp chửi về nhà bị vợ la...
Anh thì kêu tôi không có kinh nghiệm làm với hệ thống 20 triệu request mỗi ngày. Trên 100ms là time out luôn. Cứ đừng nói chờ vài giây.
Anh thì nói không phù hợp với các hệ thống cũ. Có thể chạy lâu hơn vài giây.
Trong khi tôi hỏi các anh siêu nhơn chỉ cho tôi làm sao tối ưu cái hàm GetUserById với N trường hợp cần các fields khác nhau thì các anh như là không thấy ấy?
Thôi tôi xin phép chào các anh. Tôi đi đây.
Anh thì kêu tôi không có kinh nghiệm làm với hệ thống 20 triệu request mỗi ngày. Trên 100ms là time out luôn. Cứ đừng nói chờ vài giây.
Anh thì nói không phù hợp với các hệ thống cũ. Có thể chạy lâu hơn vài giây.
Trong khi tôi hỏi các anh siêu nhơn chỉ cho tôi làm sao tối ưu cái hàm GetUserById với N trường hợp cần các fields khác nhau thì các anh như là không thấy ấy?
Thôi tôi xin phép chào các anh. Tôi đi đây.
Nipin
Member
Tôi chửi việc anh đưa luận điểm không đủ chặt chẽ.
À chửi thêm cái nosql nữa.
Còn lại thì anh đúng.
Sent from HUAWEI COR-L29 using vozFApp
Nipin
Member
nói chung các anh mang benchmark ra khè nhau hài vãi, làm gì thì đầu tiên cũng phải đưa spec cái máy mình đang test mình ra, nói rõ mình test trong hoàn cảnh nào người ta mới biết được.
chứ anh dùng cái quantum machine xong bảo thuật toán O(2^n) của tao chạy mất 0ms thì có ý nghĩa quái gì?
chứ anh dùng cái quantum machine xong bảo thuật toán O(2^n) của tao chạy mất 0ms thì có ý nghĩa quái gì?
Sửa lần cuối:
quandaso
Senior Member
Time của tôi là time response cho client/user.
Vì sao thì select 1M thì có 2 lí do:
1. Benchmark chuẩn thì phải select nhiều mới thấy sự khá biệt
2. Thực tế ông nói thì đúng, ko ai select 1M/lần, nhưng mà đối với hệ thống high traffic thì 1M request/giờ là điều hay xảy ra. Giả sử hệ thống là giao dịch liên quan đến tiền đi, lúc đấy ông sẽ ko thể dùng memcache/redis được. Lúc đấy thì phải select liên tọi, lúc đó thì phải tối ưu cho từng câu query, từng dòng lệnh một là tối quan trọng. Đương nhiên tôi sẽ phải chọn cách select nhanh hơn, dù vài chục ms.
p/s: Tớ ko cần HR nào gọi nhé
, trình cũng gà nên ko dám đi pv bao giờ
Nipin
Member
select một cái column được index với select cả row hiển nhiên là thằng đầu nhanh hơn (trừ khi về sau fetch cả row để làm việc khác) thằng select row (bằng
cơ mà tôi cũng đếch hiểu các bạn cãi nhau gì thật, thôi bỏ qua đi.
nói cái này là để nói bây giờ nó có column-oriented database rồi, khá thú vị, bạn nào thấy đúng nhu cầu có thể tìm hiểu
edit: à cái db mà tôi nói là clickhouse, đọc thấy khá hay mặc dù dính vụ immutable làm hạn chế nhiều thứ, không thay thế hoàn toàn mấy cái khác được.
Sent from HUAWEI COR-L29 using vozFApp
* hoặc một vài field)... do nó đọc dữ liệu từ hai chỗ khác nhau, một thằng đọc từ index, thằng kia phải scan tất. cơ mà tôi cũng đếch hiểu các bạn cãi nhau gì thật, thôi bỏ qua đi.
nói cái này là để nói bây giờ nó có column-oriented database rồi, khá thú vị, bạn nào thấy đúng nhu cầu có thể tìm hiểu
edit: à cái db mà tôi nói là clickhouse, đọc thấy khá hay mặc dù dính vụ immutable làm hạn chế nhiều thứ, không thay thế hoàn toàn mấy cái khác được.
Sent from HUAWEI COR-L29 using vozFApp
Sửa lần cuối:
Chủ đề tương tự
