Điểm:0

Cần trợ giúp quyết định công cụ lưu trữ MariaDB tốt nhất cho các trường hợp sử dụng và giới hạn phần cứng máy chủ của chúng tôi

lá cờ cn

Tôi làm việc cho một công ty nhỏ và chúng tôi đang cần một kho dữ liệu.

Cơ sở dữ liệu sản xuất của chúng tôi có khoảng 50Gb dữ liệu (hiện tại tăng ~10GB/năm), máy chủ của chúng tôi đang chạy vượt quá khả năng của nó một chút và chúng tôi nghĩ rằng chúng tôi có thể di chuyển một số dữ liệu lịch sử sang kho dữ liệu (có thể di chuyển khoảng một nửa trong số 50gb này ) để nó có thể chạy trơn tru trở lại.

Tất nhiên, kho dữ liệu sẽ có tất cả dữ liệu ETL'd cho nó, không chỉ dữ liệu lịch sử. Bằng cách này, chúng tôi cũng có thể lấy dữ liệu bảng điều khiển và báo cáo tốn kém đó từ DW thay vì máy chủ sản xuất.

Tôi dự định ETL dữ liệu tới DW và lưu trữ dữ liệu đó bằng sơ đồ bông tuyết, sau đó tôi dự định tạo một số kho dữ liệu để báo cáo và BI. Dữ liệu này sẽ được tạo bằng cách sử dụng các lược đồ sao, để làm cho mọi thứ đơn giản hơn (nhanh hơn?) Để truy vấn.

Chúng tôi có xu hướng sử dụng MariaDB cho nó, điều đó đưa tôi đến câu hỏi chính của mình, đó là công cụ lưu trữ nào áp dụng tốt nhất cho trường hợp của chúng tôi, innoDB hoặc ColumnStore.Và mức độ ảnh hưởng của quyết định này đối với kích thước của máy chủ mà nó sẽ chạy trên đó.

Tôi đoán, từ những gì tôi đã đọc cho đến nay, là ColumnStore có thể nhanh hơn và phù hợp hơn cho trường hợp sử dụng của chúng tôi, nhưng cũng sẽ cần phần cứng tốt hơn. Ngay bây giờ, chúng tôi không thể mua nhiều hơn một máy chủ có 4 lõi CPU và 32Gb RAM (công việc kinh doanh của chúng tôi đã bị ảnh hưởng nghiêm trọng bởi đại dịch toàn cầu. Chúng tôi đang cố gắng trở lại, nhưng chúng tôi vẫn chưa đạt được điều đó).

Vì vậy, với các thông số kỹ thuật máy chủ và trường hợp sử dụng ở trên, bạn vẫn khuyên bạn nên sử dụng ColumnStore trên innoDB chứ? Chúng tôi thậm chí còn cởi mở với các giải pháp khác ngoài MariaDB.

djdomi avatar
lá cờ za
Điều này có trả lời câu hỏi của bạn không? [Bạn có thể giúp tôi lập kế hoạch năng lực không?](https://serverfault.com/questions/384686/can-you-help-me-with-my-abilities-planning)
lá cờ cn
Tôi nghĩ rằng câu hỏi của tôi cụ thể hơn là chỉ định kích thước cho một máy chủ. Tôi có ngân sách hạn chế và muốn biết giải pháp cơ sở dữ liệu nào sẽ hoạt động tốt hơn với ngân sách đó.
Điểm:2
lá cờ ua

Động cơ: InnoDB. Giai đoạn = Stage. (Chắc chắn, 1% trường hợp sử dụng sẽ tốt hơn với thứ khác, nhưng trường hợp của bạn dường như không cho thấy nhu cầu về một công cụ khác.)

Snowflake: Khủng khiếp, đặc biệt nếu bạn cần tìm kiếm trên một "phạm vi". Vui lòng cung cấp lược đồ (tốt hơn qua HIỂN THỊ TẠO BẢNG); Tôi sẽ cụ thể hơn. (Vậy thì tôi có thể đồng ý rằng Snowflake là tốt, nhưng tôi nghi ngờ điều đó.)

Lược đồ sao -- Tốt. Bình thường hóa các chuỗi chung: tốt. Bình thường hóa các giá trị 'liên tục' (ngày, số nguyên, số float): không hợp lệ. Nhưng mục đích là để tiết kiệm dung lượng đĩa, do đó tăng tốc một số truy vấn.

10GB/năm -- nghe có vẻ trung bình là "vài" hàng mỗi giây. Nặng, nhưng không nặng khủng khiếp. Đó là, quá trình xử lý ETL không giống như bạn cần trợ giúp.

Kho dữ liệu -- http://mysql.rjweb.org/doc.php/datawarehouse

Làm sạch dữ liệu cũ -- Đây là một trong số ít cách sử dụng cho PHÂN VÙNG. http://mysql.rjweb.org/doc.php/partitionmaint

Việc chia thành các bảng riêng biệt được lưu trữ trực tuyến -- có thể gây rắc rối nhưng mang lại rất ít lợi ích.

Báo cáo chi phí -> Bảng tổng hợp http://mysql.rjweb.org/doc.php/summarytables Bảng tóm tắt nhỏ hơn nhiều so với bảng Sự kiện; nó thậm chí có thể chấp nhận được để không chuẩn hóa.

Columnstore -- Một điểm cộng lớn là khả năng nén đáng kể mà nó mang lại. Nhưng tôi không thấy 50GB của bạn là lớn lắm. Một lợi ích khác của CS là tự động "lập chỉ mục" cho mọi cột. Tuy nhiên, chỉ một cột có thể được sử dụng để tra cứu hiệu quả ở hai cấp độ.

4 lõi -- rất nhiều cho InnoDB; nhiều lõi hơn sẽ hữu ích cho CS.

RAM 32 GB -- Chỉ với 50 GB dữ liệu và 10 GB/năm -- Nếu tất cả những gì bạn làm là xem dữ liệu của năm gần nhất, thì 32 GB là quá đủ. Nếu bạn thường xuyên quét hết 50GB, thì sẽ có rất nhiều I/O. Nếu bạn triển khai Bảng Tóm tắt, thì 32 GB là quá mức cần thiết cho hầu hết các hoạt động. (Bảng Tóm tắt có thể dưới 10 GB và quay trở lại phần đầu của dữ liệu; do đó rất dễ lưu vào bộ nhớ đệm.)

32GB + CS -- 50GB của bạn sẽ trở thành khoảng 5GB. (Nhưng tôi không biết liệu 32 có quá mức cần thiết hay không.)

Ổ cứng so vớiSSD -- SSD nhanh hơn đáng kể.

Điểm mấu chốt (và ngân sách) -- Các kỹ thuật được đề cập ở trên có thể giữ cho InnoDB trên 32GB hoạt động tốt trong vài năm.

lá cờ cn
Cảm ơn ý kiến ​​​​của bạn. Tôi đã hiểu rõ hơn về những gì tôi phải làm bây giờ. Đối với việc không sử dụng lược đồ bông tuyết, thay vào đó bạn sẽ đề xuất điều gì? Mục tiêu của tôi là để DW chứa mọi thứ từ cơ sở dữ liệu sản xuất của chúng tôi và sau đó, từ đó, tôi sẽ trích xuất một số bảng thực tế và thứ nguyên (cũng là bảng tóm tắt) để báo cáo và BI.
lá cờ ua
@HenriqueMiranda - re Snowflake: Cho tôi xem một ví dụ cụ thể để tôi có thể đưa ra một số nhận xét cụ thể. Một điều bạn nghĩ đến là `Sự thật` -> `Địa chỉ` -> `Thành phố` -> `Quốc gia`; thì việc tìm kiếm các hàng `Sự thật` cho một `quốc gia_id` nhất định thực sự lộn xộn và chậm chạp.
lá cờ cn
Tôi đồng ý, nhưng dữ liệu đó sẽ không được truy vấn thường xuyên. Hầu hết các truy vấn sẽ xảy ra trên các kho dữ liệu sử dụng lược đồ hình sao.
lá cờ ua
@HenriqueMiranda - Được rồi.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.