MySQL DBA điển hình có thể quen thuộc với việc làm việc và quản lý cơ sở dữ liệu OLTP (Xử lý giao dịch trực tuyến) như một phần thói quen hàng ngày của họ. Bạn có thể quen với cách nó hoạt động và cách quản lý các hoạt động phức tạp. Mặc dù công cụ lưu trữ mặc định mà MySQL cung cấp đủ tốt cho OLAP (Xử lý phân tích trực tuyến) nhưng nó khá đơn giản, đặc biệt là những người muốn tìm hiểu trí thông minh nhân tạo hoặc những người xử lý dự báo, khai thác dữ liệu, phân tích dữ liệu.
Trong blog này, chúng ta sẽ thảo luận về MariaDB ColumnStore. Nội dung sẽ được điều chỉnh vì lợi ích của MySQL DBA, những người có thể ít hiểu hơn về ColumnStore và cách nó có thể áp dụng cho các ứng dụng OLAP (Xử lý Phân tích Trực tuyến).
OLTP so với OLAP
OLTP
Tài nguyên liên quan Phân tích với MariaDB AX - Kho dữ liệu Columnar mã nguồn mở Giới thiệu về Cơ sở dữ liệu chuỗi thời gian Kết hợp OLTP / Cơ sở dữ liệu Analytics Khối lượng công việc trong Galera Cluster bằng cách sử dụng các nô lệ không đồng bộHoạt động MySQL DBA điển hình để xử lý loại dữ liệu này là bằng cách sử dụng OLTP (Xử lý giao dịch trực tuyến). OLTP được đặc trưng bởi các giao dịch cơ sở dữ liệu lớn thực hiện chèn, cập nhật hoặc xóa. Cơ sở dữ liệu kiểu OLTP chuyên dùng để xử lý truy vấn nhanh và duy trì tính toàn vẹn của dữ liệu trong khi được truy cập trong nhiều môi trường. Hiệu quả của nó được đo bằng số lượng giao dịch mỗi giây (tps). Các bảng quan hệ cha-con (sau khi triển khai biểu mẫu chuẩn hóa) khá phổ biến để giảm bớt dữ liệu thừa trong bảng.
Các bản ghi trong bảng thường được xử lý và lưu trữ tuần tự theo hướng hàng và được lập chỉ mục cao với các khóa duy nhất để tối ưu hóa việc truy xuất hoặc ghi dữ liệu. Điều này cũng phổ biến đối với MySQL, đặc biệt là khi xử lý các chèn lớn hoặc ghi đồng thời cao hoặc chèn hàng loạt. Hầu hết các công cụ lưu trữ mà MariaDB hỗ trợ đều có thể áp dụng cho các ứng dụng OLTP - InnoDB (công cụ lưu trữ mặc định kể từ 10.2), XtraDB, TokuDB, MyRocks hoặc MyISAM / Aria.
Các ứng dụng như CMS, FinTech, Web Apps thường xử lý nhiều lần ghi và đọc và thường yêu cầu thông lượng cao. Để làm cho các ứng dụng này hoạt động thường đòi hỏi kiến thức chuyên môn sâu về tính khả dụng cao, khả năng dự phòng, khả năng phục hồi và phục hồi.
OLAP
OLAP đối phó với những thách thức tương tự như OLTP, nhưng sử dụng một cách tiếp cận khác (đặc biệt là khi xử lý truy xuất dữ liệu.) OLAP xử lý các bộ dữ liệu lớn hơn và phổ biến cho việc lưu trữ dữ liệu, thường được sử dụng cho các loại ứng dụng thông minh kinh doanh. Nó thường được sử dụng cho Quản lý Hiệu suất Kinh doanh, Lập kế hoạch, Lập ngân sách, Dự báo, Báo cáo Tài chính, Phân tích, Mô hình Mô phỏng, Khám phá Kiến thức và Báo cáo Kho dữ liệu.
Dữ liệu được lưu trữ trong OLAP thường không quan trọng bằng dữ liệu được lưu trữ trong OLTP. Điều này là do hầu hết dữ liệu có thể được mô phỏng đến từ OLTP và sau đó có thể được đưa vào cơ sở dữ liệu OLAP của bạn. Dữ liệu này thường được sử dụng để tải hàng loạt, thường cần cho các phân tích kinh doanh mà cuối cùng sẽ được hiển thị thành đồ thị trực quan. OLAP cũng thực hiện phân tích đa chiều dữ liệu kinh doanh và mang lại kết quả có thể được sử dụng cho các tính toán phức tạp, phân tích xu hướng hoặc mô hình hóa dữ liệu phức tạp.
OLAP thường lưu trữ dữ liệu liên tục bằng cách sử dụng định dạng cột. Tuy nhiên, trong MariaDB ColumnStore, các bản ghi được chia nhỏ dựa trên các cột của nó và được lưu trữ riêng thành một tệp. Theo cách này, việc truy xuất dữ liệu rất hiệu quả, vì nó chỉ quét cột có liên quan được tham chiếu trong truy vấn câu lệnh SELECT của bạn.
Hãy nghĩ về nó như thế này, xử lý OLTP xử lý các giao dịch dữ liệu hàng ngày và quan trọng chạy ứng dụng kinh doanh của bạn, trong khi OLAP giúp bạn quản lý, dự đoán, phân tích và tiếp thị sản phẩm của mình tốt hơn - các yếu tố cơ bản để có một ứng dụng kinh doanh.
MariaDB ColumnStore là gì?
MariaDB ColumnStore là một công cụ lưu trữ dạng cột có thể cắm được chạy trên Máy chủ MariaDB. Nó sử dụng kiến trúc dữ liệu phân tán song song trong khi vẫn giữ nguyên giao diện ANSI SQL được sử dụng trên danh mục máy chủ MariaDB. Công cụ lưu trữ này đã xuất hiện được một thời gian, vì nó ban đầu được chuyển từ InfiniDB (Một mã hiện không còn tồn tại vẫn có trên github.) Nó được thiết kế để mở rộng dữ liệu lớn (để xử lý petabyte dữ liệu), khả năng mở rộng tuyến tính và thực -thời gian phản hồi cho các truy vấn phân tích. Nó tận dụng các lợi ích I / O của lưu trữ dạng cột; nén, chiếu trong thời gian và phân vùng ngang &dọc để mang lại hiệu suất vượt trội khi phân tích các tập dữ liệu lớn.
Cuối cùng, MariaDB ColumnStore là xương sống của sản phẩm MariaDB AX của họ với tư cách là công cụ lưu trữ chính được sử dụng bởi công nghệ này.
MariaDB ColumnStore khác với InnoDB như thế nào?
InnoDB có thể áp dụng cho quá trình xử lý OLTP yêu cầu ứng dụng của bạn phản hồi theo cách nhanh nhất có thể. Nó hữu ích nếu ứng dụng của bạn đang xử lý bản chất đó. Mặt khác, MariaDB ColumnStore là một lựa chọn phù hợp để quản lý các giao dịch dữ liệu lớn hoặc các tập dữ liệu lớn liên quan đến các phép nối phức tạp, tổng hợp ở các cấp độ phân cấp thứ nguyên khác nhau, dự kiến tổng tài chính trong nhiều năm hoặc sử dụng các lựa chọn bình đẳng và phạm vi . Các cách tiếp cận này sử dụng ColumnStore không yêu cầu bạn lập chỉ mục các trường này, vì nó có thể hoạt động nhanh hơn đủ. InnoDB thực sự không thể xử lý loại hiệu suất này, mặc dù không có gì ngăn cản bạn thử điều đó có thể làm được với InnoDB, nhưng với một chi phí. Điều này yêu cầu bạn phải thêm các chỉ mục, điều này sẽ bổ sung một lượng lớn dữ liệu vào ổ lưu trữ của bạn. Điều này có nghĩa là có thể mất nhiều thời gian hơn để hoàn thành truy vấn của bạn và hoàn toàn có thể không hoàn thành nếu bị mắc kẹt trong một vòng lặp thời gian.
Kiến trúc cửa hàng cột MariaDB
Hãy xem kiến trúc MariaDB ColumStore bên dưới:
Hình ảnh lịch sự của MariaDB ColumnStore trình bày Trái ngược với kiến trúc InnoDB, ColumnStore chứa hai mô-đun biểu thị mục đích của nó là hoạt động hiệu quả trên một môi trường kiến trúc phân tán. InnoDB được thiết kế để mở rộng quy mô trên một máy chủ, nhưng mở rộng trên nhiều nút được kết nối với nhau tùy thuộc vào thiết lập cụm. Do đó, ColumnStore có nhiều cấp độ thành phần xử lý các quá trình được yêu cầu đến Máy chủ MariaDB. Hãy cùng tìm hiểu các thành phần này bên dưới:
- Mô-đun người dùng (UM):UM chịu trách nhiệm phân tích cú pháp các yêu cầu SQL thành một tập hợp các bước công việc nguyên thủy được tối ưu hóa được thực thi bởi một hoặc nhiều máy chủ PM. Do đó, UM chịu trách nhiệm về việc tối ưu hóa truy vấn và điều phối việc thực thi truy vấn bởi các máy chủ PM. Trong khi nhiều trường hợp UM có thể được triển khai trong triển khai nhiều máy chủ, một UM duy nhất chịu trách nhiệm cho từng truy vấn riêng lẻ. Một bộ cân bằng tải cơ sở dữ liệu, như MariaDB MaxScale, có thể được triển khai để cân bằng các yêu cầu bên ngoài một cách thích hợp với các máy chủ UM riêng lẻ.
- Mô-đun Hiệu suất (PM):PM thực hiện các bước công việc chi tiết nhận được từ UM theo cách đa luồng. ColumnStore cho phép phân phối công việc trên nhiều Mô-đun Hiệu suất. UM bao gồm quy trình MariaDB mysqld và quy trình ExeMgr.
- Bản đồ Extent:ColumnStore duy trì siêu dữ liệu về mỗi cột trong một đối tượng phân tán được chia sẻ được gọi là Bản đồ Extent Máy chủ UM tham chiếu Bản đồ Extent để giúp hỗ trợ tạo các bước công việc ban đầu chính xác. Máy chủ PM tham chiếu Bản đồ mở rộng để xác định các khối đĩa chính xác để đọc. Mỗi cột được tạo thành từ một hoặc nhiều tệp và mỗi tệp có thể chứa nhiều phạm vi. Hệ thống cố gắng phân bổ bộ nhớ vật lý liền kề càng nhiều càng tốt để cải thiện hiệu suất đọc.
- Bộ nhớ:ColumnStore có thể sử dụng bộ nhớ cục bộ hoặc bộ nhớ dùng chung (ví dụ:SAN hoặc EBS) để lưu trữ dữ liệu. Việc sử dụng bộ nhớ dùng chung cho phép tự động xử lý dữ liệu sang một nút khác trong trường hợp máy chủ PM bị lỗi.
Dưới đây là cách MariaDB ColumnStore xử lý truy vấn,
- Khách hàng đưa ra một truy vấn tới Máy chủ MariaDB đang chạy trên Mô-đun Người dùng. Máy chủ thực hiện thao tác với bảng cho tất cả các bảng cần thiết để đáp ứng yêu cầu và nhận được kế hoạch thực thi truy vấn ban đầu.
- Sử dụng giao diện công cụ lưu trữ MariaDB, ColumnStore chuyển đổi đối tượng bảng máy chủ thành các đối tượng ColumnStore. Sau đó, các đối tượng này được gửi đến các quy trình của Mô-đun người dùng.
- Mô-đun Người dùng chuyển đổi kế hoạch thực thi MariaDB và tối ưu hóa các đối tượng đã cho thành một kế hoạch thực thi ColumnStore. Sau đó, nó xác định các bước cần thiết để chạy truy vấn và thứ tự chạy chúng.
- Sau đó, Mô-đun người dùng tham khảo Bản đồ mức độ để xác định Mô-đun hiệu suất nào cần tham khảo cho dữ liệu mà nó cần, sau đó thực hiện Loại bỏ mức độ mở rộng, loại bỏ bất kỳ Mô-đun hiệu suất nào khỏi danh sách chỉ chứa dữ liệu nằm ngoài phạm vi mà truy vấn yêu cầu.
- Sau đó, Mô-đun người dùng sẽ gửi lệnh đến một hoặc nhiều Mô-đun hiệu suất để thực hiện các hoạt động I / O của khối.
- Mô-đun hiệu suất hoặc các mô-đun thực hiện lọc vị từ, xử lý kết hợp, tổng hợp dữ liệu ban đầu từ bộ nhớ cục bộ hoặc bên ngoài, sau đó gửi dữ liệu trở lại Mô-đun người dùng.
- Mô-đun người dùng thực hiện tổng hợp tập hợp kết quả cuối cùng và tạo tập hợp kết quả cho truy vấn.
- Mô-đun Người dùng / ExeMgr thực hiện bất kỳ tính toán chức năng cửa sổ nào, cũng như bất kỳ phân loại cần thiết nào trên tập kết quả. Sau đó, nó trả về tập kết quả cho máy chủ.
- Máy chủ MariaDB thực hiện bất kỳ chức năng danh sách lựa chọn nào, thao tác ORDER BY và LIMIT trên tập kết quả.
- Máy chủ MariaDB trả về tập hợp kết quả cho máy khách.
Mô hình thực thi truy vấn
Hãy tìm hiểu thêm một chút về cách ColumnStore thực thi truy vấn và khi nào nó tác động.
ColumnStore khác với các công cụ lưu trữ MySQL / MariaDB tiêu chuẩn như InnoDB vì ColumnStore đạt được hiệu suất bằng cách chỉ quét các cột cần thiết, sử dụng phân vùng do hệ thống duy trì và sử dụng nhiều luồng và máy chủ để mở rộng thời gian phản hồi truy vấn. Hiệu suất được hưởng khi bạn chỉ bao gồm các cột cần thiết cho việc truy xuất dữ liệu của mình. Điều này có nghĩa là dấu hoa thị tham lam (*) trong truy vấn đã chọn của bạn có tác động đáng kể so với SELECT
Tương tự như với InnoDB và các công cụ lưu trữ khác, kiểu dữ liệu cũng có ý nghĩa về hiệu suất đối với những gì bạn đã sử dụng. Nếu giả sử bạn có một cột chỉ có thể có các giá trị từ 0 đến 100 thì hãy khai báo cột này dưới dạng tinyint vì cột này sẽ được biểu diễn bằng 1 byte thay vì 4 byte cho int. Điều này sẽ giảm 4 lần chi phí I / O. Đối với các loại chuỗi, ngưỡng quan trọng là char (9) và varchar (8) hoặc lớn hơn. Mỗi tệp lưu trữ cột sử dụng một số byte cố định cho mỗi giá trị. Điều này cho phép tra cứu nhanh vị trí của các cột khác để tạo thành hàng. Hiện tại, giới hạn trên cho việc lưu trữ dữ liệu dạng cột là 8 byte. Vì vậy, đối với các chuỗi dài hơn mức này, hệ thống duy trì một phạm vi 'từ điển' bổ sung nơi các giá trị được lưu trữ. Sau đó, tệp phạm vi cột sẽ lưu trữ một con trỏ vào từ điển. Vì vậy, việc đọc và xử lý một cột varchar (8) đắt hơn một cột char (8) chẳng hạn. Vì vậy, nếu có thể, bạn sẽ nhận được hiệu suất tốt hơn nếu bạn có thể sử dụng các chuỗi ngắn hơn, đặc biệt nếu bạn tránh tra cứu từ điển. Tất cả các kiểu dữ liệu TEXT / BLOB trong 1.1 trở đi đều sử dụng từ điển và thực hiện tra cứu nhiều khối 8KB để truy xuất dữ liệu đó nếu được yêu cầu, dữ liệu càng dài thì càng nhiều khối được truy xuất và tác động hiệu suất tiềm năng càng lớn.
Trong một hệ thống dựa trên hàng, việc thêm các cột dư thừa sẽ làm tăng chi phí truy vấn tổng thể nhưng trong hệ thống cột, chi phí chỉ xảy ra nếu cột được tham chiếu. Do đó nên tạo các cột bổ sung để hỗ trợ các đường dẫn truy cập khác nhau. Ví dụ:lưu trữ phần đầu của trường trong một cột để cho phép tra cứu nhanh hơn nhưng cũng lưu trữ giá trị dạng dài dưới dạng một cột khác. Quét trên mã ngắn hơn hoặc cột phần đầu sẽ nhanh hơn.
Các phép nối truy vấn đã sẵn sàng tối ưu hóa cho các phép nối quy mô lớn và tránh sự cần thiết phải có chỉ mục và chi phí xử lý vòng lặp lồng nhau. ColumnStore duy trì thống kê bảng để xác định thứ tự tham gia tối ưu. Các cách tiếp cận tương tự chia sẻ với InnoDB như nếu phép nối quá lớn đối với bộ nhớ UM, nó sẽ sử dụng phép nối dựa trên đĩa để hoàn thành truy vấn.
Đối với tổng hợp, ColumnStore phân phối đánh giá tổng hợp nhiều nhất có thể. Điều này có nghĩa là nó chia sẻ trên UM và PM để xử lý các truy vấn đặc biệt là hoặc số lượng rất lớn các giá trị trong (các) cột tổng hợp. Đếm chọn (*) được tối ưu hóa nội bộ để chọn số lượng byte lưu trữ ít nhất trong một bảng. Điều này có nghĩa là nó sẽ chọn cột CHAR (1) (sử dụng 1 byte) trên cột INT chiếm 4 byte. Việc triển khai vẫn tôn trọng ngữ nghĩa ANSI trong đó số lượng được chọn (*) sẽ bao gồm các giá trị rỗng trong tổng số so với một lựa chọn rõ ràng (COL-N) loại trừ các số rỗng trong số lượng.
Thứ tự theo và giới hạn hiện được thực hiện ở cuối quá trình máy chủ mariadb trên bảng tập hợp kết quả tạm thời. Điều này đã được đề cập trong bước # 9 về cách ColumnStore xử lý truy vấn. Vì vậy, về mặt kỹ thuật, kết quả được chuyển đến Máy chủ MariaDB để sắp xếp dữ liệu.
Đối với các truy vấn phức tạp sử dụng truy vấn con, về cơ bản nó giống cách tiếp cận được thực thi theo trình tự và được quản lý bởi UM, giống như với các hàm Window do UM xử lý nhưng nó sử dụng quy trình sắp xếp chuyên dụng nhanh hơn, vì vậy về cơ bản nó nhanh hơn.
Việc phân vùng dữ liệu của bạn do ColumnStore cung cấp. ColumnStore sử dụng Bản đồ Extent để duy trì các giá trị tối thiểu / tối đa của dữ liệu cột và cung cấp phạm vi hợp lý để phân vùng và loại bỏ nhu cầu lập chỉ mục. Extent Maps cũng cung cấp phân vùng bảng theo cách thủ công, dạng xem cụ thể hóa, bảng tóm tắt và các cấu trúc và đối tượng khác mà cơ sở dữ liệu dựa trên hàng phải triển khai cho hiệu suất truy vấn. Có một số lợi ích nhất định đối với các giá trị theo cột khi chúng có thứ tự hoặc bán theo thứ tự vì điều này cho phép phân vùng dữ liệu rất hiệu quả. Với các giá trị tối thiểu và tối đa, toàn bộ bản đồ phạm vi sau bộ lọc và loại trừ sẽ bị loại bỏ. Xem trang này trong sách hướng dẫn của họ về Loại bỏ Mức độ. Điều này thường hoạt động đặc biệt tốt đối với dữ liệu chuỗi thời gian hoặc các giá trị tương tự tăng theo thời gian.
Cài đặt MariaDB ColumnStore
Cài đặt MariaDB ColumnStore có thể đơn giản và dễ hiểu. MariaDB có một loạt ghi chú ở đây mà bạn có thể tham khảo. Đối với blog này, môi trường mục tiêu cài đặt của chúng tôi là CentOS 7. Bạn có thể truy cập liên kết này https://downloads.mariadb.com/ColumnStore/1.2.4/ và xem các gói dựa trên môi trường hệ điều hành của bạn. Xem các bước chi tiết bên dưới để giúp bạn tăng tốc:
### Note: The installation details is ideal for root user installation
cd /root/
wget https://downloads.mariadb.com/ColumnStore/1.2.4/centos/x86_64/7/mariadb-columnstore-1.2.4-1-centos7.x86_64.rpm.tar.gz
tar xzf mariadb-columnstore-1.0.7-1-centos7.x86_64.rpm.tar.gz
sudo yum -y install boost expect perl perl-DBI openssl zlib snappy libaio perl-DBD-MySQL net-tools wget jemalloc
sudo rpm -ivh mariadb-columnstore*.rpm
Sau khi hoàn tất, bạn cần chạy postConfigure lệnh để cuối cùng cài đặt và thiết lập MariaDB ColumnStore của bạn. Trong cài đặt mẫu này, có hai nút tôi đã thiết lập chạy trên máy vagrant:
csnode1:192.168.2.10
csnode2:192.168.2.20
Cả hai nút này đều được xác định trong / etc / hosts tương ứng của nó và cả hai nút đều được nhắm mục tiêu được thiết lập để kết hợp Người dùng và Mô-đun Hiệu suất của nó trong cả hai máy chủ. Việc cài đặt ban đầu hơi đơn giản. Do đó, chúng tôi chia sẻ cách bạn có thể cấu hình nó để bạn có cơ sở. Xem chi tiết bên dưới để biết quy trình cài đặt mẫu:
[[email protected] ~]# /usr/local/mariadb/columnstore/bin/postConfigure -d
This is the MariaDB ColumnStore System Configuration and Installation tool.
It will Configure the MariaDB ColumnStore System and will perform a Package
Installation of all of the Servers within the System that is being configured.
IMPORTANT: This tool requires to run on the Performance Module #1
Prompting instructions:
Press 'enter' to accept a value in (), if available or
Enter one of the options within [], if available, or
Enter a new value
===== Setup System Server Type Configuration =====
There are 2 options when configuring the System Server Type: single and multi
'single' - Single-Server install is used when there will only be 1 server configured
on the system. It can also be used for production systems, if the plan is
to stay single-server.
'multi' - Multi-Server install is used when you want to configure multiple servers now or
in the future. With Multi-Server install, you can still configure just 1 server
now and add on addition servers/modules in the future.
Select the type of System Server install [1=single, 2=multi] (2) >
===== Setup System Module Type Configuration =====
There are 2 options when configuring the System Module Type: separate and combined
'separate' - User and Performance functionality on separate servers.
'combined' - User and Performance functionality on the same server
Select the type of System Module Install [1=separate, 2=combined] (1) > 2
Combined Server Installation will be performed.
The Server will be configured as a Performance Module.
All MariaDB ColumnStore Processes will run on the Performance Modules.
NOTE: The MariaDB ColumnStore Schema Sync feature will replicate all of the
schemas and InnoDB tables across the User Module nodes. This feature can be enabled
or disabled, for example, if you wish to configure your own replication post installation.
MariaDB ColumnStore Schema Sync feature, do you want to enable? [y,n] (y) >
NOTE: MariaDB ColumnStore Replication Feature is enabled
Enter System Name (columnstore-1) >
===== Setup Storage Configuration =====
----- Setup Performance Module DBRoot Data Storage Mount Configuration -----
There are 2 options when configuring the storage: internal or external
'internal' - This is specified when a local disk is used for the DBRoot storage.
High Availability Server Failover is not Supported in this mode
'external' - This is specified when the DBRoot directories are mounted.
High Availability Server Failover is Supported in this mode.
Select the type of Data Storage [1=internal, 2=external] (1) >
===== Setup Memory Configuration =====
NOTE: Setting 'NumBlocksPct' to 50%
Setting 'TotalUmMemory' to 25%
===== Setup the Module Configuration =====
----- Performance Module Configuration -----
Enter number of Performance Modules [1,1024] (1) > 2
*** Parent OAM Module Performance Module #1 Configuration ***
Enter Nic Interface #1 Host Name (csnode1) >
Enter Nic Interface #1 IP Address or hostname of csnode1 (unassigned) > 192.168.2.10
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm1' (1) >
*** Performance Module #2 Configuration ***
Enter Nic Interface #1 Host Name (unassigned) > csnode2
Enter Nic Interface #1 IP Address or hostname of csnode2 (192.168.2.20) >
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () > 2
===== Running the MariaDB ColumnStore MariaDB Server setup scripts =====
post-mysqld-install Successfully Completed
post-mysql-install Successfully Completed
Next step is to enter the password to access the other Servers.
This is either user password or you can default to using a ssh key
If using a user password, the password needs to be the same on all Servers.
Enter password, hit 'enter' to default to using a ssh key, or 'exit' >
===== System Installation =====
System Configuration is complete.
Performing System Installation.
Performing a MariaDB ColumnStore System install using RPM packages
located in the /root directory.
----- Performing Install on 'pm2 / csnode2' -----
Install log file is located here: /tmp/columnstore_tmp_files/pm2_rpm_install.log
MariaDB ColumnStore Package being installed, please wait ... DONE
===== Checking MariaDB ColumnStore System Logging Functionality =====
The MariaDB ColumnStore system logging is setup and working on local server
===== MariaDB ColumnStore System Startup =====
System Configuration is complete.
Performing System Installation.
----- Starting MariaDB ColumnStore on local server -----
MariaDB ColumnStore successfully started
MariaDB ColumnStore Database Platform Starting, please wait .......... DONE
System Catalog Successfully Created
Run MariaDB ColumnStore Replication Setup.. DONE
MariaDB ColumnStore Install Successfully Completed, System is Active
Enter the following command to define MariaDB ColumnStore Alias Commands
. /etc/profile.d/columnstoreAlias.sh
Enter 'mcsmysql' to access the MariaDB ColumnStore SQL console
Enter 'mcsadmin' to access the MariaDB ColumnStore Admin console
NOTE: The MariaDB ColumnStore Alias Commands are in /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]# . /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]#Sau khi cài đặt và thiết lập xong, MariaDB sẽ tạo một thiết lập chính / phụ cho việc này, vì vậy bất cứ thứ gì chúng tôi đã tải từ csnode1, nó sẽ được sao chép sang csnode2.
Bán phá giá Dữ liệu lớn của bạn
Sau khi cài đặt, bạn có thể không có dữ liệu mẫu nào để thử. IMDB đã chia sẻ dữ liệu mẫu mà bạn có thể tải xuống trên trang web của họ https://www.imdb.com/interfaces/. Đối với blog này, tôi đã tạo một tập lệnh thực hiện mọi thứ cho bạn. Hãy xem tại đây https://github.com/paulnamuag/columnstore-imdb-data-load. Chỉ cần làm cho nó có thể thực thi, sau đó chạy tập lệnh. Nó sẽ làm mọi thứ cho bạn bằng cách tải xuống các tệp, tạo lược đồ, sau đó tải dữ liệu vào cơ sở dữ liệu. Nó đơn giản như vậy.
Chạy các truy vấn mẫu của bạn
Bây giờ, hãy thử chạy một số truy vấn mẫu.
MariaDB [imdb]> select count(1), 'title_akas' table_name from title_akas union all select count(1), 'name_basics' as table_name from name_basics union all select count(1), 'title_crew' as table_name from title_crew union all select count(1), 'title_episode' as table_name from title_episode union all select count(1), 'title_ratings' as table_name from title_ratings order by 1 asc;
+----------+---------------+
| count(1) | table_name |
+----------+---------------+
| 945057 | title_ratings |
| 3797618 | title_akas |
| 4136880 | title_episode |
| 5953930 | title_crew |
| 9403540 | name_basics |
+----------+---------------+
5 rows in set (0.162 sec)MariaDB [imdb]> select count(*), 'title_akas' table_name from title_akas union all select count(*), 'name_basics' as table_name from name_basics union all select count(*), 'title_crew' as table_name from title_crew union all select count(*), 'title_episode' as table_name from title_episode union all select count(*), 'title_ratings' as table_name from title_ratings order by 2;
+----------+---------------+
| count(*) | table_name |
+----------+---------------+
| 9405192 | name_basics |
| 3797618 | title_akas |
| 5953930 | title_crew |
| 4136880 | title_episode |
| 945057 | title_ratings |
+----------+---------------+
5 rows in set (0.371 sec)Về cơ bản, nó nhanh hơn và nhanh hơn. Có những truy vấn mà bạn không thể xử lý giống như khi chạy với các công cụ lưu trữ khác, chẳng hạn như InnoDB. Ví dụ:tôi đã thử chơi xung quanh và thực hiện một số truy vấn ngu ngốc và xem nó phản ứng như thế nào và kết quả là:
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select a.titleId from title_akas) limit 25;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'title_akas' are not joined.Do đó, tôi đã tìm thấy MCOL-1620 và MCOL-131 và nó trỏ đến thiết lập biến infinidb_vtable_mode. Xem bên dưới:
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'b, sub-query' are not joined.Nhưng đặt infinidb_vtable_mode =0 , có nghĩa là nó coi truy vấn là chế độ xử lý từng hàng chung và tương thích cao. Một số thành phần mệnh đề WHERE có thể được ColumnStore xử lý, nhưng các phép nối được xử lý hoàn toàn bởi mysqld bằng cách sử dụng cơ chế nối vòng lặp lồng nhau. Xem bên dưới:
MariaDB [imdb]> set infinidb_vtable_mode=0;
Query OK, 0 rows affected (0.000 sec)MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
+-----------+---------------+--------+-----------+-------------+---------------+
| titleId | title | region | id | primaryName | profession |
+-----------+---------------+--------+-----------+-------------+---------------+
| tt0082880 | Vaticano Show | ES | nm0594213 | Velda Mitzi | miscellaneous |
| tt0082880 | Il pap'occhio | IT | nm0594213 | Velda Mitzi | miscellaneous |
+-----------+---------------+--------+-----------+-------------+---------------+
2 rows in set (13.789 sec)Tuy nhiên, phải mất một lúc vì nó giải thích rằng nó được xử lý hoàn toàn bởi mysqld. Tuy nhiên, tối ưu hóa và viết các truy vấn tốt vẫn là cách tiếp cận tốt nhất và không ủy thác mọi thứ cho ColumnStore.
Ngoài ra, bạn có một số trợ giúp để phân tích các truy vấn của mình bằng cách chạy các lệnh như SELECT calSetTrace (1); hoặc SELECT calGetStats (); . Bạn có thể sử dụng tập hợp các lệnh này, ví dụ, tối ưu hóa các truy vấn thấp và kém hoặc xem kế hoạch truy vấn của nó. Hãy xem tại đây để biết thêm chi tiết về cách phân tích các truy vấn.
Quản trị ColumnStore
Sau khi bạn đã thiết lập đầy đủ MariaDB ColumnStore, nó sẽ đi kèm với công cụ có tên mcsadmin mà bạn có thể sử dụng để thực hiện một số tác vụ quản trị. Bạn cũng có thể sử dụng công cụ này để thêm một mô-đun khác, gán hoặc di chuyển đến các Cơ sở dữ liệu từ PM sang PM, v.v. Hãy xem hướng dẫn của họ về công cụ này.
Về cơ bản, bạn có thể làm như sau, chẳng hạn như kiểm tra thông tin hệ thống:
mcsadmin> getSystemi
getsysteminfo Mon Jun 24 12:55:25 2019
System columnstore-1
System and Module statuses
Component Status Last Status Change
------------ -------------------------- ------------------------
System ACTIVE Fri Jun 21 21:40:56 2019
Module pm1 ACTIVE Fri Jun 21 21:40:54 2019
Module pm2 ACTIVE Fri Jun 21 21:40:50 2019
Active Parent OAM Performance Module is 'pm1'
Primary Front-End MariaDB ColumnStore Module is 'pm1'
MariaDB ColumnStore Replication Feature is enabled
MariaDB ColumnStore set for Distributed Install
MariaDB ColumnStore Process statuses
Process Module Status Last Status Change Process ID
------------------ ------ --------------- ------------------------ ----------
ProcessMonitor pm1 ACTIVE Thu Jun 20 17:36:27 2019 6026
ProcessManager pm1 ACTIVE Thu Jun 20 17:36:33 2019 6165
DBRMControllerNode pm1 ACTIVE Fri Jun 21 21:40:31 2019 19890
ServerMonitor pm1 ACTIVE Fri Jun 21 21:40:33 2019 19955
DBRMWorkerNode pm1 ACTIVE Fri Jun 21 21:40:33 2019 20003
PrimProc pm1 ACTIVE Fri Jun 21 21:40:37 2019 20137
ExeMgr pm1 ACTIVE Fri Jun 21 21:40:42 2019 20541
WriteEngineServer pm1 ACTIVE Fri Jun 21 21:40:47 2019 20660
DDLProc pm1 ACTIVE Fri Jun 21 21:40:51 2019 20810
DMLProc pm1 ACTIVE Fri Jun 21 21:40:55 2019 20956
mysqld pm1 ACTIVE Fri Jun 21 21:40:41 2019 19778
ProcessMonitor pm2 ACTIVE Thu Jun 20 17:37:16 2019 9728
ProcessManager pm2 HOT_STANDBY Fri Jun 21 21:40:26 2019 25211
DBRMControllerNode pm2 COLD_STANDBY Fri Jun 21 21:40:32 2019
ServerMonitor pm2 ACTIVE Fri Jun 21 21:40:35 2019 25560
DBRMWorkerNode pm2 ACTIVE Fri Jun 21 21:40:36 2019 25593
PrimProc pm2 ACTIVE Fri Jun 21 21:40:40 2019 25642
ExeMgr pm2 ACTIVE Fri Jun 21 21:40:44 2019 25715
WriteEngineServer pm2 ACTIVE Fri Jun 21 21:40:48 2019 25768
DDLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
DMLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
mysqld pm2 ACTIVE Fri Jun 21 21:40:32 2019 25467
Active Alarm Counts: Critical = 1, Major = 0, Minor = 0, Warning = 0, Info = 0Kết luận
MariaDB ColumnStore là một công cụ lưu trữ rất mạnh mẽ để xử lý OLAP và dữ liệu lớn của bạn. Đây hoàn toàn là mã nguồn mở, rất thuận lợi để sử dụng so với việc sử dụng cơ sở dữ liệu OLAP độc quyền và đắt tiền hiện có trên thị trường. Tuy nhiên, có những lựa chọn thay thế khác để thử như ClickHouse, Apache HBase hoặc cstore_fdw của Citus Data. Tuy nhiên, cả hai đều không sử dụng MySQL / MariaDB nên nó có thể không phải là lựa chọn khả thi của bạn nếu bạn chọn sử dụng các biến thể MySQL / MariaDB.
