Phương thức ưu tiên cho Chế độ xem Vật hoá (Bảng tóm tắt) với MySQL

Question

Tôi đang phát triển một dự án tại nơi tôi cần tạo và duy trì Bảng tóm tắt vì lý do hiệu suất. Tôi tin rằng cụm từ chính xác cho điều này là Lượt xem vật chất.

tôi có 2 lý do chính để làm điều này:

1. denormalization

   tôi bình thường hóa các bảng càng nhiều càng tốt. Vì vậy, có những tình huống mà tôi sẽ phải tham gia nhiều bảng để lấy dữ liệu. Chúng tôi làm việc với MySQL Cluster, có hiệu suất khá kém khi nói đến JOIN.

   Vì vậy, tôi cần tạo Bảng không chuẩn hóa có thể chạy nhanh hơn SELECT.

2. Tóm tắt dữ liệu

   Ví dụ, tôi có một bảng giao dịch với một vài triệu bản. Các giao dịch đến từ các trang web khác nhau. Ứng dụng cần tạo báo cáo sẽ hiển thị số lượng giao dịch hàng ngày hoặc hàng tháng và tổng số tiền doanh thu trên mỗi trang web. Tôi không muốn kịch bản báo cáo tính toán điều này mọi lúc, vì vậy tôi cần tạo Bảng tóm tắt sẽ có bảng phân tích theo [trang web, ngày].

   Đó chỉ là một ví dụ đơn giản. Có nhiều loại bảng tóm tắt khác nhau mà tôi cần để tạo và duy trì.

Trước đây tôi đã thực hiện những việc này bằng cách viết một số tập lệnh cron để giữ cho mỗi bảng tóm tắt được cập nhật. Nhưng trong dự án mới này, tôi hy vọng sẽ thực hiện một giải pháp thanh lịch và đúng đắn hơn.

Tôi thích một giải pháp dựa trên PHP, vì tôi không phải là quản trị viên máy chủ và tôi cảm thấy thoải mái nhất khi tôi có thể kiểm soát mọi thứ thông qua mã ứng dụng của mình.

---

Giải pháp mà tôi đã xem xét:

1. sao chép XEM của

   Nếu bảng kết quả có thể được biểu diễn dưới dạng một truy vấn SELECT duy nhất, tôi có thể tạo ra một VIEW . Vì chúng chậm, có thể có một cronjob sao chép VIEW này thành một bảng thực.

   Tuy nhiên, một số truy vấn SELECT này có thể chậm đến mức không thể chấp nhận ngay cả đối với cronjobs. Nó không phải là rất hiệu quả để tái tạo toàn bộ dữ liệu tóm tắt, nếu hàng cũ hơn thậm chí không được cập nhật nhiều.

2. Tuỳ chỉnh cronjobs cho mỗi Tóm tắt Bảng

   Đây là giải pháp tôi đã sử dụng trước đó, nhưng bây giờ tôi đang cố gắng để tránh nó nếu có thể. Nếu có nhiều bảng tóm tắt, nó có thể lộn xộn để duy trì.

3. MySQL Triggers

   Có thể thêm trigger cho bảng chính để mỗi khi có một INSERT, UPDATE hay DELETE, các bảng tóm tắt được cập nhật cho phù hợp.

   Sẽ không có cronjob và tóm tắt sẽ theo thời gian thực. Tuy nhiên, nếu có nhu cầu xây dựng lại một bảng tóm tắt từ đầu, nó sẽ phải được thực hiện với một giải pháp khác (có thể là # 1 ở trên).

4. Sử dụng ORM Móc/Triggers

   Tôi đang sử dụng học thuyết như ORM của tôi. Có một cách để thêm người nghe sự kiện sẽ kích hoạt công cụ trên INSERT/UPDATE/DELETE, do đó có thể cập nhật các bảng tóm tắt. Theo một nghĩa nào đó, giải pháp này tương tự như # 3 ở trên, nhưng tôi sẽ kiểm soát tốt hơn các trình kích hoạt này vì chúng sẽ được thực hiện trong PHP.

---

xét triển khai:

1. Hoàn Tái

   Tôi muốn tránh phải xây dựng lại các bảng tóm tắt, cho hiệu quả, và chỉ cập nhật cho dữ liệu mới. Nhưng trong trường hợp có sự cố, tôi cần khả năng xây dựng lại bảng tóm tắt từ đầu bằng cách sử dụng dữ liệu hiện có trên các bảng chính.

2. Bỏ qua UPDATE/DELETE trên Old liệu

   Một số tóm tắt có thể giả định rằng các bản ghi cũ sẽ không bao giờ được cập nhật hoặc xóa, nhưng chỉ có kỷ lục mới sẽ được chèn vào. Quá trình tóm tắt có thể tiết kiệm rất nhiều công sức bằng cách giả định rằng nó không cần phải kiểm tra các bản cập nhật trên dữ liệu cũ hơn.

   Nhưng tất nhiên điều này sẽ không áp dụng cho tất cả các bảng.

3. Giữ một Log

   Giả sử rằng tôi sẽ không có quyền truy cập vào, hoặc không muốn sử dụng các bản ghi MySQL nhị phân.

   Để tóm tắt dữ liệu mới, quá trình tóm tắt chỉ cần nhớ id khóa chính cuối cùng cho các bản ghi cuối cùng được tóm tắt. Lần sau nó chạy, nó có thể tóm tắt mọi thứ sau id đó. Tuy nhiên, để theo dõi các bản ghi cũ đã được cập nhật/xóa, nó cần một bản ghi khác để nó có thể quay trở lại và tóm tắt lại dữ liệu đó.

---

tôi sẽ đánh giá cao bất kỳ loại chiến lược, góp ý hay liên kết có thể giúp đỡ. Cảm ơn bạn!

Answer 1

Như đã nêu ở trên quan điểm vật hoá trong Oracle là khác với quan điểm được lập chỉ mục trong SQL Server. Họ rất mát mẻ và hữu ích.Xem http://download.oracle.com/docs/cd/B10500_01/server.920/a96567/repmview.htm để biết chi tiết

MySql không có hỗ trợ cho những điều này.

Một điều bạn đề cập nhiều lần là hiệu suất kém. Bạn đã kiểm tra thiết kế cơ sở dữ liệu của bạn để lập chỉ mục thích hợp và chạy các kế hoạch giải thích về các truy vấn để xem tại sao chúng chậm. Xem ở đây http://dev.mysql.com/doc/refman/5.1/en/using-explain.html. Đây là khóa học giả định rằng máy chủ của bạn được điều chỉnh đúng cách, bạn đã thiết lập và điều chỉnh mysql, ví dụ: bộ đệm đệm, v.v., v.v.

Đối với câu hỏi trực tiếp của bạn. Những gì bạn âm thanh như bạn muốn làm là một cái gì đó chúng ta thường xuyên trong một tình trạng kho dữ liệu. Chúng tôi có một cơ sở dữ liệu sản xuất và một DW có khả năng thu thập tất cả các loại thông tin, tập hợp và chuẩn bị trước để tăng tốc độ truy vấn. Điều này có thể là quá mức cần thiết cho bạn nhưng bạn có thể quyết định. Tùy thuộc vào độ trễ bạn xác định cho báo cáo của mình, tức là tần suất bạn cần, chúng tôi thường thực hiện quy trình ETL (tải biến đổi) theo định kỳ (hàng ngày, hàng tuần, v.v.) để điền DW từ hệ thống sản xuất. Điều này giữ tác động thấp trên hệ thống sản xuất và chuyển tất cả báo cáo sang một bộ máy chủ khác cũng làm giảm tải. Về phía DW, tôi thường thiết kế các lược đồ của mình khác nhau, tức là sử dụng lược đồ sao. (http://www.orafaq.com/node/2286) Các lược đồ hình sao có các bảng thực tế (những thứ bạn muốn đo) và kích thước (những thứ bạn muốn tổng hợp các biện pháp theo thời gian, địa lý, danh mục sản phẩm, v.v.) SQL Server chúng cũng bao gồm một công cụ bổ sung được gọi là SQL Server Analysis services (SSAS) để xem xét các bảng và kích thước thực tế, tính toán trước và xây dựng các khối dữ liệu OLAP trong các khối dữ liệu này bạn có thể xem chi tiết. Oracle thực hiện những điều hơi khác nhau nhưng kết quả là như nhau

Cho dù bạn muốn đi về tuyến đường thực sự phụ thuộc vào nhu cầu kinh doanh và bao nhiêu giá trị bạn nhận được từ phân tích dữ liệu. có khả năng quá mức cần thiết nếu bạn chỉ có một vài bảng tóm tắt nhưng một số khái niệm bạn có thể thấy hữu ích khi bạn nghĩ về mọi thứ. Nếu doanh nghiệp của bạn hướng đến một doanh nghiệp thông minh ution thì đây là một cái gì đó để xem xét.

PS Bạn thực sự có thể thiết lập DW để hoạt động trong "thời gian thực" bằng cách sử dụng một cái gì đó gọi là ROLAP nếu đó là nhu cầu kinh doanh. Microstrategy có một sản phẩm tốt hoạt động tốt cho việc này.

PPS Bạn cũng có thể muốn xem PowerPivot từ MS (http://www.powerpivot.com/learn.aspx) Tôi chỉ phát với nó vì vậy tôi không thể cho bạn biết cách hoạt động trên các tập dữ liệu rất lớn.

Answer 2

Flexviews (http://flexvie.ws) là một dự án dựa trên PHP/MySQL nguồn mở. Flexviews bổ sung thêm các khung nhìn vật chất có thể làm mới lại (như các khung nhìn vật chất hóa trong Oracle) thành MySQL, sử dụng các thủ tục PHP và lưu trữ.

Nó bao gồm FlexCDC, một tiện ích ghi dữ liệu thay đổi dựa trên PHP đọc nhật ký nhị phân và thủ tục lưu trữ Flexviews MySQL được sử dụng để xác định và duy trì chế độ xem.

Flexviews hỗ trợ kết nối (chỉ nối bên trong) và tập hợp sao cho nó có thể được sử dụng để tạo bảng tóm tắt. Hơn nữa, bạn có thể sử dụng Flexviews kết hợp với nhà thiết kế tổng hợp Mondrian's (một máy chủ ROLAP) để tạo các bảng tóm tắt mà công cụ ROLAP có thể tự động sử dụng.

Nếu bạn không có quyền truy cập vào nhật ký (nó có thể đọc từ xa, btw, vì vậy bạn không cần truy cập máy chủ, nhưng bạn cần SUPER privs) thì bạn có thể sử dụng 'COMPLETE' refresh with Flexviews. Điều này tự động tạo ra một bảng mới với 'CREATE TABLE ... AS SELECT' dưới một tên bảng mới. Sau đó nó sử dụng RENAME TABLE để trao đổi bảng mới cho một bảng, đổi tên cũ bằng một postfix _old. Cuối cùng nó giảm bảng cũ. Ưu điểm ở đây là SQL để tạo ra khung nhìn được lưu trữ trong cơ sở dữ liệu (flexviews.mview) và có thể được làm mới với một cuộc gọi API đơn giản để tự động hóa quá trình hoán đổi.