[dreamnight]

Originally Posted by ez-aqua

Mình làm với Azure SQL cloud, toàn version mới nhất nên ko biết nhiều với mấy version cũ, nhưng 2014 thì gay đấy, mình thấy cái hướng dẫn truncate partition trên nó ghi dành cho SQL Server 2016. Trên cloud thì vụ truncate partition mình từng test thử rồi, làm OK. Partition sinh ra để chuyên trị ba cái trò rebuild, reorganize 1 phần mà.

Cả columnstore mà xài tốt thì theo mình biết cũng phải từ 2016 trở lên. Nghe vậy thôi chứ mình chưa có trải nghiệm qua columnstore của SQL các version thấp.

Bảng 1.5 tỉ row thì chắc chắn phải là bảng fact rồi, mà nếu đã là bảng fact thì đâu ai link với nó đâu, sợ gì vụ foreign key nhỉ.

Cái vụ phải select ngày báo lỗi là chính xác báo lỗi gì vậy bác. Ko biết server mấy bạn ra sao chứ mình chơi trên cloud, plan cỡ trung thôi mà quất select into bảng tạm mấy chục triệu row còn được mà. Ít nhất cũng phải select được theo năm chứ nhỉ.

1355308

Azure SQL là nguyên 1 hệ thống to đùng nó nuôi thì lấy gì mà ko xử lý được 1.5 tỉ rows.

Chức năng partition hay columnstore có thể apply được trên database (sql server 2012 đã có), tuy nhiên vấn đề lớn phát sinh thêm đó là phải đợi nó scan full 1.5 tỉ row nhé. Mà vì con database server trên bị xiềng về hardware rồi (theo mình nghĩ cấu hình nó tầm 16Gb là cùng) thì chạy 1.5 tỉ row để apply partition ko nổi vì out memory ngay, nếu siết memory thì phải đợi cả hàng chục tiếng.

[minhbon]

Originally Posted by dreamnight

Azure SQL là nguyên 1 hệ thống to đùng nó nuôi thì lấy gì mà ko xử lý được 1.5 tỉ rows.

Chức năng partition hay columnstore có thể apply được trên database (sql server 2012 đã có), tuy nhiên vấn đề lớn phát sinh thêm đó là phải đợi nó scan full 1.5 tỉ row nhé. Mà vì con database server trên bị xiềng về hardware rồi (theo mình nghĩ cấu hình nó tầm 16Gb là cùng) thì chạy 1.5 tỉ row để apply partition ko nổi vì out memory ngay, nếu siết memory thì phải đợi cả hàng chục tiếng.

thím trả lời hoàn toàn chính xác, nó bị xiềng về hardware nên bị lỗi out of memory.

[alohomora]

Tạo job cho nó xóa từ từ vài trăm k rows mỗi 10p thì từ từ cũng xong thôi chứ nhỉ? Có gấp gáp không thím?

[minhbon]

Originally Posted by alohomora

Tạo job cho nó xóa từ từ vài trăm k rows mỗi 10p thì từ từ cũng xong thôi chứ nhỉ? Có gấp gáp không thím?

thanks thím, sau khi reduce xong thì chắc chắn sẽ phải có job reduce từ từ để tránh tình trang trong bài bị lặp lại. Đéo hiểu sao lúc build thì chả ai nghĩ đến cái việc này. Nó còn mấy cái bảng như thế nữa, đang phải dọn dần

[dreamnight]

Originally Posted by minhbon

thanks thím, sau khi reduce xong thì chắc chắn sẽ phải có job reduce từ từ để tránh tình trang trong bài bị lặp lại. Đéo hiểu sao lúc build thì chả ai nghĩ đến cái việc này. Nó còn mấy cái bảng như thế nữa, đang phải dọn dần

Đơn giản mà, thằng viết ra toàn Dev có phải DBA đâu mà biết ba cái vụ này. Dev giờ chỉ thấy CRUD dưới DB được là mừng rồi, còn DB nó growing thế nào ko care đâu. Nói thật cho tới bây giờ mình vẫn thấy nhiều hệ thống coi nhẹ DBA lắm, toàn code cho run trước đã rồi tính tới vụ án maintainance sau, mà DB lên PROD rồi khó fix lắm

[alohomora]

Originally Posted by dreamnight

Đơn giản mà, thằng viết ra toàn Dev có phải DBA đâu mà biết ba cái vụ này. Dev giờ chỉ thấy CRUD dưới DB được là mừng rồi, còn DB nó growing thế nào ko care đâu. Nói thật cho tới bây giờ mình vẫn thấy nhiều hệ thống coi nhẹ DBA lắm, toàn code cho run trước đã rồi tính tới vụ án maintainance sau, mà DB lên PROD rồi khó fix lắm

dev giờ dùng Entity Framework thì chả cần quan tâm đến indexing luôn ấy chứ, khi nào scale lớn lớn tí lại tính sau

[alohomora]

Rốt cục là thớt dùng cách gì vậy? Chia sẻ lên anh em còn học hỏi nào.

[sju_G@']

1. Một ngày insert tầm 500k row là tương đối nhiều. Có nhất thiết phải dùng SQL database để lưu không? Vì bạn bảo đây là bản lưu report. Mình cũng không biết report về gì nhưng từ con số 500k row/ngày thì nghe vẻ con số khá tương tự việc logging. Nếu report của bạn mà chỉ dùng ở mức hạn chế, ví dụ query theo ngày hay theo tháng, thì theo mình lưu vào blob store trên clould cho rẻ. Vì SQL tính giá thành đắt, dùng nó cho dữ liệu có index thôi.

2. Có một solution khác #2 một chút. Là tạo một bảng mới cấu trúc y hệt bảng cũ. Yeu cầu cần sửa code một chút. Khi write thì write vào bảng mới, khi read thì read từ bảng mới, nếu không thấy thì read từ bảng cũ. Chạy job đến ngày hết hạn thì xoá bớt dữ liệu, hoặc canh đến ngày hết hạn thì truncate bảng cũ đi

3. Cái job chạy lập lịch để xoá bớt dữ liệu: mình thấy rất phí resource, mỗi ngày insert 500k row và expect là cũng sẽ có 500k row của một ngày nào đó trong quá khứ bị xoá. Cảm giác database của thím đang bị stress vì cái hoạt động insert/delete report, performance của cả engine bị drag down vì thằng này - mặc dù nó có thể ko phải là business chính. Theo mình thì nên cô lập cái chức năng report hoặc re-design lại cái thiết kế reporting. Nhiều writes dư thừa quá...

[ez-aqua]

Lạm bàn một chút về mấy vụ database này. Theo mình thấy 1 ngày 500.000 dòng thì nghe nhiều đấy, nhưng kinh nghiệm của mình quy ra columnstore thì không nhiều đâu, mới chỉ bằng 1 nửa của 1 full rowgroup à. Mình ước tính cả database 10 năm 1,5 tỉ dòng kia mà dã columnstore index, không có rowstore index nào khác thì chỉ ~100 -> 200 GB là cùng.

Cỡ này không đến mức phang cả cái giải pháp data lake trên blob/data lake storage đâu. 500.000 dòng 1 ngày theo mình là quá nhỏ so với cái hệ này. Mình thấy chỉ nên nghĩ đến data lake khi data dự tính có chừng > 500GB dữ liệu file parquet. (Mình ước tính phải khoảng tương đương vài chục tỉ dòng).

Không biết là do mình có làm sai, không biết cách dùng hay gì ko nhưng theo kinh nghiệm của mình thì trên 1 dataset nhỏ vài triệu row đến vài chục triệu row, SQL Server thực hiện aggregate bằng columnstore index scan sẽ nhanh hơn dùng Spark aggregate trên 1 file parquet. .

Khi mà data lớn lên hẳn nữa rồi, bắt buộc phải tìm giải pháp mới, mà chơi trên cloud Azure thì có thể nghĩ đến kiểu giải pháp kiểu như Azure Synapse Analytic. Mấy cái này nó kiểu chả khác gì SQL bình thường nhưng có siêu scale khổng lồ. Tuy nhiên thì nó đắt đỏ khủng khiếp. Còn ba cái quỷ chơi theo kiểu data lake này, storage thì siêu rẻ, nhưng còn phải kéo theo 1 tầng query, xử lý kiểu Hadoop Hive, Spark hoặc mấy cái như Azure Data Lake Analytic. Được cái là scale gần như vô hạn. Mà cái này hơi bị hiếm với khó xài, kiếm được analyst biết xài để còn mine được data hơi bị khó, còn engineer thì cũng chẳng mấy người rành để mà thiết kế điều khiển. 1355308

Tất nhiên ta có thể mix như các data mart quan trọng, chính yếu, đã được cô đọng lên, analyst chơi nhiều thì giữ trên 1 cái RDBMS. Còn đối với kiểu mấy cái nho nhỏ, kiểu event, log...số lượng cực lớn thì giữ trong data lake cũng khá đẹp, khi cần thì dùng mấy cái như Spark ad-hoc query vào.