Thực đơn
trang chủTrình duyệt

So sánh mariadb và mysql. MariaDB thay thế để so sánh MySQL. Hỗ trợ công cụ lưu trữ

Nó đã sớm được Oracle mua lại). Đây là những nghi ngờ khá chính đáng mà tôi sẽ nói đến sau. Bên cạnh vai trò là "phiên bản nhẹ" của MySQL, MariaBD còn có một số tính năng mới mà một số người cho rằng nó tốt hơn MySQL.

Trước khi đi vào chi tiết về các tính năng này, tôi muốn nói về sơ đồ đánh số phiên bản của MariaDB. Thứ nhất, các phiên bản của nó giống với các phiên bản MySQL - ví dụ: MariaDB 5.1 sử dụng cùng cơ sở mã với MySQL 5.1. Khi các bản vá được cập nhật và thêm vào cây nguồn MySQL, MariaDB sẽ nhận được các bản vá tương tự bất cứ khi nào có thể (về lý thuyết, sẽ hợp nhất hàng tháng với mã MySQL). Nhưng nếu các tính năng mới và độc đáo liên tục được thêm vào, tôi tưởng tượng việc duy trì kiểu mã chẵn lẻ này đã trở thành một cơn ác mộng.

Nhóm phát triển MariaDB phải nhận thức được điều này vì họ đã quyết định sử dụng sơ đồ đánh số mới. Phiên bản mới nhất của MariDB (vẫn là phiên bản alpha) là Maria 10.0, theo sau là số thiết bị phụ:

Mysql -P 3406 -u root -p Nhập mật khẩu: ******** Chào mừng bạn đến với màn hình MariaDB. Các lệnh kết thúc bằng ; hoặc\g. Id kết nối MariaDB của bạn là 1 Phiên bản máy chủ: 10.0.2-MariaDB mariadb.org phân phối nhị phân Bản quyền (c) 2000, 2013, Oracle, Monty Program Ab và các phiên bản khác. Nhập "trợ giúp;" hoặc "\h" để được trợ giúp. Nhập "\c" để xóa câu lệnh đầu vào hiện tại. MariaDB [(không có)]> chọn phiên bản(); +------+ | phiên bản() | +------+ | 10.0.2-MariaDB | +------+ 1 hàng trong tập hợp (0,01 giây) MariaDB [(none)]>

Những người làm việc trên MariaDB đưa ra lời giải thích dài và khá dài dòng về lý do tại sao họ làm điều này - điều này vẫn khiến một số nhà phát triển thất vọng - nhưng thực tế nó là như vậy. Họ không thể tiếp tục bổ sung thêm các tính năng mới và liên tục khẳng định rằng đây là phiên bản nhanh hơn, tương thích hoàn toàn với MySQL.

Vậy những tính năng mới là gì? Chúng ta hãy nhìn vào một vài trong số họ.


Động cơ Cassandra

Một trong những tính năng độc đáo của MariaDB là công cụ kết nối với phiên bản máy chủ của Cassandra DBMS. Bản thân công cụ này chỉ đơn giản là một trung gian kết nối với máy chủ Cassandra chạy riêng. Cassandra là kho lưu trữ dữ liệu NoSQL ban đầu được tạo cho Facebook và sau đó trở thành dự án Apache; Mặc dù nó có thể được sử dụng trong các cụm mà không có một điểm lỗi nào, nhưng nó vẫn không tuân thủ ACID. Nói chung, nếu bạn định sử dụng Cassandra làm công cụ của mình, đừng mong đợi tốc độ hiệu suất tương tự như InnoDB hoặc ExtraBD.

Nhưng bạn có thể truy cập thông tin bằng MySQL bằng cách thêm giao diện giống SQL và cũng cho phép chọn, chèn, cập nhật, xóa và thậm chí tham gia ở một mức độ nào đó. Tuy nhiên, nhóm MariaDB lập luận rằng công cụ Cassandra tốt nhất không nên được sử dụng cho bất kỳ mục đích nào quan trọng hơn việc chỉ sử dụng dữ liệu.

Vì vậy, tính năng này có thể hữu ích nếu bạn... ừm... để tôi nghĩ... à...

Nếu bạn đang viết một ứng dụng phần mềm yêu cầu quyền truy cập vào dữ liệu trong Cassandra thì tốt hơn hết bạn nên sử dụng API Cassandra tích hợp sẵn thay vì MySQL. Tôi cho rằng nếu bạn đang gặp khó khăn với MySQL CLI và cần lấy một số dữ liệu thì Cassandra có thể hữu ích - nhưng nếu bạn định sử dụng nó, chẳng phải việc gặp khó khăn với Cassandra CLI sẽ dễ dàng hơn sao?

Vì vậy, tôi thực sự không chắc lắm về trường hợp sử dụng này, nhưng đó chính là điều đã làm giảm sự nhiệt tình của một số người trong cộng đồng blog đối với tính năng này.


Công cụ OQGraph

Tôi sẽ không nói quá nhiều về nó, vì ý tưởng cũng giống như trong Cassandra: công cụ này chỉ đơn giản là một giao diện cho công cụ tính toán Biểu đồ truy vấn mở (một kho lưu trữ để tổ chức các biểu đồ phức tạp). Điều này có thể hữu ích trong một số ứng dụng chuyên biệt, mặc dù việc điều chỉnh cấu trúc đồ thị theo định dạng SQL thoạt nhìn hơi lạ.

Một cải tiến lớn giúp MariaDB trở nên mạnh mẽ hơn là việc sử dụng XtraDB như một sự thay thế nhanh chóng cho InnoDB. Nhưng XtraDB bổ sung thêm các khả năng mở rộng mới mà các ứng dụng hiện đại cần—và đó chính là điểm khác biệt thực sự. Oracle tuyên bố rằng MySQL hiện có quy mô tốt hơn bao giờ hết. Điều đó có thể đúng, nhưng nó chỉ tốt khi động cơ của nó hoạt động tốt. Và nếu công cụ không mở rộng quy mô như trong thực tế thì MySQL sẽ không thể làm điều đó tốt hơn.


Chế độ ghi nguyên tử

Một trong những lý do chính khiến bạn nên chọn cơ sở dữ liệu quan hệ thay vì NoSQL thông thường là cơ sở dữ liệu quan hệ hoàn toàn tuân thủ ACID. Nói một cách đơn giản, nếu xảy ra lỗi thì không ai muốn toàn bộ dữ liệu biến mất. Và mặc dù lỗi trên máy tính của nhà phát triển không phải là chuyện thường xuyên xảy ra nhưng chúng vẫn xảy ra ở nhiều trung tâm CNTT. Hiện tại, công cụ ghi dữ liệu InnoDB/XtraDB tiêu chuẩn sử dụng bộ đệm đôi để đảm bảo ghi dữ liệu thành công trong trường hợp có bất kỳ lỗi nào. Tuy nhiên, khi làm việc với các thiết bị SSD tốc độ cao (hãy lấy điều này làm ví dụ), bộ đệm đôi có thể có tác động tiêu cực đến hiệu suất, khiến bạn không thể sử dụng hết tốc độ của SSD. Những giải pháp? Bạn có thể chọn một bộ đệm và sử dụng chế độ Atomic Writes. Hãy tự chịu rủi ro khi thử nó và tốt hơn nữa là không đưa vào sản xuất.

Một lần nữa, tính năng này rất thú vị nhưng không đủ để thuyết phục bạn từ bỏ MySQL và chuyển sang MariaDB.


So sánh hiệu suất của MySQL và MariaDB

Bây giờ tôi muốn bạn chú ý đến các thử nghiệm so sánh do nhóm MariaDB thực hiện và thêm một số nhận xét. Blog này đưa ra một điểm thú vị: nếu có ít hơn 16 luồng, MySQL hoạt động tốt và nếu có nhiều hơn - mặc dù tất nhiên, hiệu suất vẫn tiếp tục cải thiện đôi chút, nhưng không tốt bằng các phiên bản khác mà nó được so sánh (bao gồm cả MariaDB). - 5.5.28a và MariaDB-10.0.1; xem biểu đồ kiểm tra hiệu năng ở đầu bài viết này). Đây là một vấn đề khá phổ biến trong lập trình song song khi cố gắng nhắm mục tiêu vào nhiều lõi và luồng trong một lõi. Nếu các thuật toán được xây dựng là chính xác thì bạn sẽ cảm nhận được lợi ích khi số lượng lõi tăng lên. Vấn đề là bạn sẽ phải sử dụng 2 phương pháp trong lập trình song song của mình: 1) đa luồng trên một số lõi và 2) vector hóa. Những kỹ thuật này là hai mặt của lập trình đa lõi hiện tại và mã của bạn phải sử dụng chúng một cách chính xác.

Một trong những kết quả phổ biến nhất của việc mã hóa kém là bạn sẽ thấy hiệu suất tăng lên trong 8 hoặc 16 luồng đầu tiên, sau đó sẽ không có sự cải thiện nào. Nếu bạn gặp vấn đề như vậy thì rất có thể vấn đề nằm ở thuật toán. Và đây sẽ là trường hợp với siêu phân luồng hoặc luồng phần cứng. Đây chính xác là những gì chúng ta thấy trong các bài kiểm tra MySQL. Đối với tôi điều này có nghĩa là có vấn đề về mở rộng quy mô trong MySQL và đó là điều cần suy nghĩ. Trong cùng thử nghiệm đó, MariaDB cũng gặp một số vấn đề vì... năng suất giảm nhưng chỉ một chút; Tôi đoán điều này không áp dụng cho các thuật toán song song.

Tôi cũng không biết một số phiên bản phù hợp đến mức nào với các máy tính được sử dụng để chạy thử nghiệm. Khi biên dịch mã Intel, bạn muốn trình biên dịch tạo mã SIMD có kích thước phù hợp với máy đích. Nếu có sự không khớp, bạn sẽ không nhận được hiệu suất như mong đợi từ mã vector hóa của mình. Để thực hiện điều này một cách chính xác, bạn sẽ cần chèn các pragma cần thiết vào mã, sau đó viết chính xác các thuật toán vector hóa và cuối cùng chạy các tùy chọn trình biên dịch thích hợp. Tôi biết điều này nghe có vẻ ngu ngốc, nhưng tôi đã thấy các chương trình được xuất bản với các tùy chọn sai thường xuyên hơn bạn nghĩ. Trong mọi trường hợp, mã MySQL thuần túy không được tối ưu hóa để hỗ trợ đa lõi và vector hóa như MariaDB.

Điều tôi muốn thấy nhất là một phiên bản của MySQL hoặc MariaDB được biên dịch riêng cho bộ đồng xử lý Intel Xeon Phi, trong đó mã giảm tải cho bộ đồng xử lý 61 lõi và ai đó cố gắng tạo ra tất cả 244 luồng. Thật không may, tôi không có quyền truy cập vào một máy như vậy. Ngoài ra, nếu bạn muốn tìm hiểu thêm về vectơ hóa và mã hóa song song, hãy xem cuốn sách mới nhất của nhân viên Intel, James Jeffers và James Reinders, Lập trình hiệu suất cao cho Bộ đồng xử lý Intel Xeon Phi.


Bạn có nên chuyển đổi?

Rõ ràng các tính năng mới của MariaDB không hoàn toàn kỳ diệu - bạn có thể cần truy cập một số dữ liệu Cassandra, nhưng tôi nghi ngờ bạn sẽ sử dụng MySQL để làm điều đó. Điều tương tự cũng áp dụng cho các công cụ khác trên nền tảng này. Hiệu suất của MariaDB tốt hơn một chút trên máy tính đa lõi, tuy nhiên, tôi tin rằng MySQL có thể được cấu hình cho việc này.

Vậy bạn có nên chuyển sang MariaDB không?

Đầu tiên, hãy suy nghĩ về tất cả các rủi ro có thể xảy ra (các nhà quản lý cấp cao thích nghe về rủi ro và lợi ích). Nếu bạn chuyển sang MariaDB, bạn có thể sẽ sử dụng các tính năng chỉ có trong MariaDB (điều này khó có thể xảy ra vào thời điểm này) và sau đó bạn sẽ không thể chuyển về MySQL mà không cần nỗ lực nhiều. Nhưng tôi muốn đề xuất rằng đây không phải là một rủi ro như vậy, xét đến một số vấn đề lớn hơn.

Suy ngẫm tất cả các câu hỏi về Oracle và các kế hoạch cấp phép MySQL của nó. MySQL nguồn mở đi ngược lại các chương trình độc quyền và rất cạnh tranh. Chỉ riêng điều này thôi cũng là một lý do để suy nghĩ - liệu Oracle có làm bất cứ điều gì để can thiệp vào sự phát triển của MySQL không? Một số người cho rằng điều này đã xảy ra rồi.

Khả năng tương thích của MySQL và MariaDB thì sao? Nhóm MariaDB đang nỗ lực làm việc để làm cho cơ sở dữ liệu tương thích hoàn toàn với MySQL và họ tiếp tục khắc phục các lỗi trong mã nguồn. Tuy nhiên, các tính năng mới (cũng như cách đánh số phiên bản) cho thấy rằng, mặc dù đã nỗ lực hết sức nhưng hai nền tảng sẽ rất khác nhau.

Nếu Oracle bổ sung thêm một số tính năng mới vào MySQL mà MariaDB không hỗ trợ thì rõ ràng chúng sẽ không có sẵn cho bạn. Và nếu bạn sử dụng các tính năng mà MySQL không có, bạn sẽ không thể quay lại sử dụng nó vì bạn có lý do để chuyển sang nền tảng khác. MariaDB cho thấy mọi dấu hiệu cho thấy nó sẽ tồn tại trong một thời gian khá dài, điều này không xảy ra với MySQL. Nói cách khác, mặc dù các tính năng mới của MariaDB có thể không hữu ích với tất cả mọi người, nhưng theo tôi có quá đủ lý do để từ bỏ MySQL và chuyển hoàn toàn sang MariaDB.

Một lưu ý nhỏ trước khi tôi kết thúc. Một số blogger đã nêu quan điểm tốt về các thỏa thuận dịch vụ. Nếu bất kỳ ai trong công ty của bạn đã mua thỏa thuận dịch vụ từ Oracle để giúp bạn về MySQL, bạn có thể không muốn chuyển sang MariaDB để tránh các vấn đề tài chính và pháp lý phát sinh nếu bạn vi phạm thỏa thuận. Ngoài ra, tôi không thấy có lý do thuyết phục nào để tiếp tục sử dụng MySQL.

Phiên bản gốc của MySQL được phát triển bởi công ty MySQL AB của Phần Lan-Thụy Điển, được thành lập bởi Jvid Ahmark, Allan Larsson và Michael Monti. Phiên bản đầu tiên của MySQL xuất hiện vào năm 1995. Ban đầu nó được thiết kế cho mục đích sử dụng cá nhân, nhưng sau một vài năm, nó đã trở thành cơ sở dữ liệu cấp doanh nghiệp.

Vào tháng 1 năm 2008, Sun Microsystems mua lại MySQL AB với giá 1 tỷ USD. Ngay sau đó, Oracle mua Sun Microsystems với sự cho phép của Ủy ban Châu Âu, ban đầu họ lo ngại rằng quyết định như vậy sẽ gây tổn hại cho dự án MySQL miễn phí, vì đây là đối thủ cạnh tranh trực tiếp với hệ thống quản lý cơ sở dữ liệu của Oracle. Do không tin tưởng vào chiến lược phát triển của MySQL, một nhánh có tên MariaDB đã được tạo ra.

Nhiều năm trôi qua, MariaDB bắt đầu được sử dụng theo mặc định trong nhiều bản phân phối Linux. Nó được sử dụng để cung cấp năng lượng cho hầu hết các trang Internet. Trong bài viết này, chúng tôi sẽ cố gắng so sánh MySQL với MariaDB và tìm ra lý do tại sao cái thứ hai tốt hơn cái thứ nhất và khi nào cần MySQL gốc.

Không giống như nhiều dự án nguồn mở khác có nguồn gốc từ Sun Microsystems, Oracle vẫn đang phát triển MySQL. Sau khi nhiều nhà phát triển từ chức, người mới được thuê. Nhưng việc phát triển các phiên bản mới của MySQL đã bị đóng cửa. Mã nguồn chỉ có sẵn cho nhóm phát triển và chỉ được tải lên kho lưu trữ công cộng sau khi hoàn thành công việc. Mọi quyết định đều được thảo luận trong nội bộ công ty

MariaDB đang được phát triển hoàn toàn công khai, mọi giải pháp và ý tưởng mới liên quan đến phát triển đều có thể được thảo luận thoải mái trong bản tin email cũng như trong hệ thống báo cáo lỗi. Rất dễ dàng để giúp phát triển MariaDB; các bản vá từ người dùng cũng như từ nhà phát triển đều được chấp nhận. Nhìn chung, MariaDB đang phát triển tích cực hơn.

Do có thương hiệu nên MySQL vẫn có cộng đồng lớn nhưng ngày càng có nhiều dự án chuyển sang MariaDB. Các bản phân phối doanh nghiệp nổi tiếng như REHL 7 và SLES 12 đã sử dụng MariaDB, điều đó có nghĩa là trong cuộc chiến giữa MySQL và MariaDB, MariaDB sẽ thắng.

2. Tần suất phát hành

Chính sách của Oracle là phát hành bản cập nhật bảo mật cho tất cả các sản phẩm của mình ba tháng một lần. Nhưng phiên bản mới của MySQL dự kiến ​​sẽ được phát hành hai tháng một lần. Điều này thường dẫn đến các bản cập nhật sản phẩm và bản cập nhật bảo mật không được đồng bộ hóa.

Các nhà phát triển không có thời gian để đóng tất cả các thông báo lỗi và lỗ hổng, do đó cơ sở dữ liệu có thể dễ bị tấn công trong vài tháng. Một vấn đề khác với MySQL là các bản cập nhật bảo mật rất mơ hồ. Nếu quản trị viên không thể đơn giản cập nhật chương trình lên phiên bản mới thì việc tạo backport sẽ rất khó khăn.

MariaDB phát hành các bản cập nhật chương trình và cập nhật bảo mật một cách đồng bộ nên mọi lỗi đều được khắc phục kịp thời. Tất cả các CVE cố định đều được ghi lại và bất kỳ người dùng nào cũng có thể tìm hiểu những gì đã thay đổi trong phiên bản mới.

4. Tính năng và chức năng

Nhìn chung, MariaDB đang phát triển nhanh hơn và có nhiều tính năng hơn. Những tính năng này liên quan đến tối ưu hóa, cải thiện hiệu suất bộ nhớ và hơn thế nữa. Thông thường, theo thời gian, những khả năng này sẽ được di chuyển sang MySQL. Ví dụ: hỗ trợ GIS tương tự đã xuất hiện trong MariaDB sớm hơn trong MySQL. Trong số những thứ khác, MariaDB có nhiều cải tiến về hiệu suất cho Inodb, MyISAM và công cụ truy vấn, hỗ trợ GIS, thanh lý bảng, cột ảo và động, sao chép đa nguồn, vai trò và hơn thế nữa.

Nhưng MariaDB cũng có nhược điểm là nó không hỗ trợ một số tính năng mà MySQL có. Cụ thể, MariaDB không tương thích với cú pháp JSON của MySQL, các plugin ngram, MeCab, MySQL X không được hỗ trợ, cũng như các không gian bảng cho phép bạn gán dữ liệu cho nhiều bảng cùng một lúc. Nhưng các nhà phát triển đang tích cực làm việc để khắc phục những thiếu sót.

Đối với những người quan tâm đến các cụm MySQL, sẽ rất thú vị khi MariaDB sử dụng hệ thống sao chép Galera mới, hoạt động của nó khác với master-salve tiêu chuẩn. Galera đã được phát triển từ năm 2007, nhưng nó chưa bao giờ được đưa vào phiên bản chính thức của MySQL.

5. Hỗ trợ công cụ lưu trữ

Hệ thống quản lý cơ sở dữ liệu MariaDB hỗ trợ nhiều công cụ lưu trữ dữ liệu hơn. Hầu hết các công cụ này đều có sẵn dưới dạng plugin cho MySQL, nhưng trong MariaDB, chúng được đưa vào bản phát hành chính thức. Điều này có nghĩa là các động cơ được tích hợp đúng cách và sẽ hoạt động tốt. Dưới đây là danh sách các công cụ được hỗ trợ:

  • Aria;
  • XtraDB - phiên bản cải tiến của InnoDB;
  • FederatedX - phiên bản cải tiến của Federated;
  • OQGRAPH;
  • Nhân sưSE;
  • IBMDB2I;
  • TokuDB;
  • Cassandra;
  • KẾT NỐI;
  • SỰ LIÊN TIẾP;
  • nhện;
  • CộtStore;
  • MySIAM.

Hãy để tôi nhắc bạn rằng MySQL gốc theo mặc định chỉ hỗ trợ ba loại bảng - Aria, MySIAM và InnoDB. Đây là một khía cạnh quan trọng khi chọn MySQL hoặc MariaDB.

6. Tên và đánh số phiên bản

Những khác biệt này giữa MariaDB và MySQL không quá quan trọng, nhưng có lẽ chúng sẽ khiến ai đó quan tâm. Cái tên MySQL được đặt để vinh danh con gái đầu lòng của một trong những nhà phát triển - Michael Monti, tên cô ấy là My. Sự phát triển của MariaDB được tiếp tục bởi cùng một người và lần này chương trình được đặt theo tên của con gái út của ông, Maria.

Đối với các phiên bản, ban đầu, cho đến phiên bản 5.6, các phiên bản MariaDB được đánh số đồng bộ với các phiên bản MySQL mà chúng dựa trên đó. Nhưng khi đã tích lũy đủ số lượng thay đổi và mã MariaDB bắt đầu được lấy làm cơ sở, người ta quyết định thay đổi số phiên bản thành 10. Kể từ thời điểm đó, việc đánh số MariaDB chỉ được thực hiện theo cách này.

kết luận

Trong bài viết này, chúng tôi đã so sánh MySQL và MariaDB. MariaDB tốt hơn nhiều so với MySQL ở hầu hết các khía cạnh, vì vậy không có gì ngạc nhiên khi hầu hết các bản phân phối Linux hiện nay đều sử dụng nó theo mặc định trong kho của chúng. Phiên bản gốc có thể chỉ cần thiết trong những trường hợp rất hiếm.

Bạn vẫn đang sử dụng MySQL phải không?
Và nhiều người đã chuyển sang cơ sở dữ liệu MariaDB từ lâu.
Hãy nhìn logo MariaDB có con dấu đẹp làm sao.

MySQL cũng có một chú cá heo khá đẹp

Một chút lịch sử của MariaDB từ Wikipedia.
MariaDB là một nhánh do cộng đồng phát triển của MySQL. Động lực cho việc tạo ra nó là nhu cầu đảm bảo trạng thái tự do của DBMS (theo giấy phép GPL), trái ngược với chính sách cấp phép mơ hồ của MySQL của Oracle.

Nhà phát triển chính của MariaDB là Michael Widenius, đồng thời là tác giả của phiên bản gốc của MySQL và là người sáng lập Monty Program AB.

Mục tiêu chính của dự án MariaDB là tạo ra một phiên bản DBMS tương thích hoàn toàn nhị phân với MySQL gốc, phiên bản này cũng sẽ có một số cải tiến đáng kể về mã ảnh hưởng đến hiệu suất.

MariaDB được thiết kế để thay thế MySQL, mô phỏng hoàn toàn hoạt động của MySQL (và thực tế là như vậy).

MariaDB hiện đang là một xu hướng đầy hứa hẹn, hãy nhìn vào bảng so sánh giữa MySQL và MariaDB (đặc biệt là nhánh 10.x)

Tôi lấy so sánh từ trang web chính thức của MariaDB, nơi bạn có thể xem xét các điểm chi tiết hơn. Mặc dù ngay cả khi không có điều này thì rõ ràng MariaDB 10.x vẫn dẫn đầu.

Ngày nay, nhiều bản phân phối Linux cài đặt MariaDB theo mặc định thay vì MySQL và bí mật ở đây rất đơn giản - MariaDB hỗ trợ cùng các định dạng lưu trữ dữ liệu, bảng và thậm chí cả các lệnh khởi chạy, v.v., tức là. việc di chuyển sang MariaDB thật dễ dàng và liền mạch. Việc cài đặt MariaDB cũng dễ dàng và đơn giản trên FreeBSD.

Ví dụ: loại bảng Aria được tối ưu hóa cho các thao tác chèn vào cơ sở dữ liệu (chúng nhanh hơn đáng kể so với trên MyISAM). Bảng Aria cũng được sử dụng trong MariaDB cho các quy trình nội bộ; tất cả các bảng tạm thời đều chạy trên Aria, giúp cải thiện hiệu suất đối với các truy vấn phức tạp.

Cụm từ: so sánh MariaDB và MySQL, cơ sở dữ liệu nào tốt hơn?, tốc độ hoạt động, cài đặt MariaDB

Và bây giờ đã nảy sinh sự lựa chọn DBMS để lưu trữ dữ liệu cơ bản. Tôi đã bắt đầu phát triển trên MySQL, nhưng bây giờ tôi không chắc chắn về lựa chọn này. Việc chuyển sang một DBMS khác ở giai đoạn này sẽ không thành vấn đề đối với tôi (tôi sử dụng PDO). Tôi chưa hiểu rõ ràng về "tải cao" là gì đối với DBMS. Chỉ là, theo tính toán của tôi, trong khoảng một năm nữa phần đế sẽ khá nặng (xem bên dưới)

Sự lựa chọn chính là giữa MySQL, PostgreSQL, MariaDB. Ngoài ra, tùy chọn Microsoft SQL Server trên Windows Azure cũng có thể thực hiện được nhưng không được khuyến nghị.

Tình hình là thế này:

  1. Không có truy vấn phức tạp tới cơ sở dữ liệu. THAM GIA tối đa từ hai bảng
  2. B ồ Hầu hết các yêu cầu đều được đọc
  3. Có một bảng quan trọng nhất và “chính” (cấu trúc bảng nằm bên dưới phần spoiler). Bảng sẽ tăng thêm khoảng 10-30 nghìn bản ghi mỗi ngày. Ghi dữ liệu vào bảng này là điều quan trọng nhất!
  4. B ồ Phần lớn các yêu cầu đọc sẽ được chuyển hướng đến bảng “chính”. Bảng này sẽ được tìm kiếm theo bất kỳ trường nào (trong những trường hợp cực kỳ hiếm gặp ~0,5% - nhiều trường cùng một lúc). Việc tìm kiếm phải được tiến hành nhanh chóng (bất chấp điểm số 3)
  5. Các chỉ mục rất có thể sẽ được thêm vào từng trường cho hai trường cùng một lúc (ID chủ sở hữu và Tên trường, vì ID chủ sở hữu sẽ được chỉ định trong tất cả các truy vấn). Sẽ cần tìm kiếm nhanh trong bất kỳ trường nào, nhưng đây không phải là nhiệm vụ ưu tiên. (Hoặc sử dụng Sphinx tốt hơn?)
  6. Tỷ lệ truy vấn lớn nhất (~80%) để đọc vào bảng “chính” là các lựa chọn đơn giản trên các chỉ mục từ và ID cá nhân có giới hạn = 20. Các truy vấn còn lại trên bất kỳ trường nào khác trên chỉ mục (chưa tồn tại) ownerID và Field Tên, cũng có giới hạn = 20
  7. Những thay đổi đối với dữ liệu trong các bản ghi của bảng “chính” sẽ cực kỳ hiếm khi xảy ra. Không có bản ghi nào sẽ bị xóa khỏi bảng.
  8. Hỗ trợ giao dịch và khóa ngoại là tùy chọn
  9. Chúng ta cần khả năng sao chép dữ liệu kiểu master-slave
  10. Khả năng phân chia ở cấp DBMS được hoan nghênh
  11. Độ tin cậy của cơ sở dữ liệu là cực kỳ quan trọng (tức là sự cố như MyISAM khi khôi phục thủ công sẽ ngay lập tức biến mất)
  12. Các trường mới có thể được thêm vào bảng “chính”. Tất nhiên, đây là một trường hợp cực kỳ hiếm khi xảy ra và không phải là yêu cầu quan trọng nhất, nhưng việc thêm một cột mới vào bảng có kích thước hàng chục GB là một quá trình rất dài đối với MySQL và tôi thực sự không muốn chuyển cột mới. các trường vào một bảng riêng biệt
  13. Tất cả điều này ban đầu sẽ chạy trên một máy chủ chuyên dụng như vậy
  14. Các bảng khác sẽ phát triển chậm và khả năng truy cập vào chúng sẽ khá hiếm, tôi không lo lắng về chúng. Tôi có dữ liệu được cập nhật thường xuyên đang chạy trong redis"e
Cấu trúc của bảng “chính” TẠO BẢNG NẾU KHÔNG TỒN TẠI `client` (`id` bigint(11) NOT NULL AUTO_INCREMENT, `personalID` int(11) NOT NULL, `ownerID` int(11) NOT NULL, `fromID` int(11) NOT NULL DEFAULT "4", `fromDomain` varchar(255) NOT NULL, `datetime` datetime NOT NULL, `status` int(11) NOT NULL DEFAULT "0", `pay` tinyint(1) NOT NULL DEFAULT "0", ` PaymentType` tinyint(4) NOT NULL DEFAULT "1", `wmSum` float NOT NULL DEFAULT "0", `wmCommission` float NOT NULL DEFAULT "20", `sysNumber` varchar(14) NOT NULL, `sysNumberLastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `sysNumberStatus` varchar(250) NOT NULL, `timezone` float NOT NULL, `comment` varchar(500) NOT NULL, `countryID` int(11) NOT NULL, `postIndex` varchar(6) NOT NULL , `khu vực` varchar(500) KHÔNG NULL, `city` varchar(500) KHÔNG NULL, `địa chỉ` varchar(500) KHÔNG NULL, `fio` varchar(500) KHÔNG NULL, `phone` varchar(15) KHÔNG NULL , `email` varchar(255) NOT NULL, `price` float NOT NULL, `quantity` int(11) NOT NULL MẶC ĐỊNH "1", `label` varchar(30) NOT NULL, `tag` int(11) NOT NULL, `ip` varchar(15) NOT NULL, `referer` varchar(200) NOT NULL, PRIMARY KEY (`id`), KEY `from` (`ownerID`,`fromID`), KEY `pay` (` đã trả`), KEY `status` (`status`), KEY `label` (`label`), KEY `sysNumberLastUpdate` (`sysNumberLastUpdate`), KEY `personalID` (`ownerID`,`personalID`)) ENGINE= Bộ ký tự mặc định của InnoDB=utf8;

tái bút Tôi yêu cầu những người muốn đưa tôi lên Google thậm chí không được trả lời. Tôi không thể tìm thấy thông tin so sánh các phiên bản hiện tại của các DBMS khác nhau và nghiên cứu các khả năng, ưu và nhược điểm của PostgreSQL, Microsoft SQL Server và MariaDB là một nhiệm vụ rất dài đối với một người chưa từng làm việc với chúng. Và tôi không phải là một chuyên gia về MySQL, và một dự án lớn như vậy là điều mới mẻ đối với tôi và các khả năng của MySQL khác nhau giữa các phiên bản. Điều duy nhất tôi biết chắc chắn là các bảng như MyISAM trong MySQL chắc chắn không phù hợp với tôi

  • Câu hỏi được hỏi hơn ba năm trước
  • 39797 lượt xem

Điều gì sẽ xảy ra khi công ty Oracle, vốn bị những người ủng hộ phần mềm nguồn mở căm ghét và thậm chí vô cùng phẫn nộ, đã mua lại Mặt trời đau khổ từ lâu, đồng thời là MySQL yêu quý của chúng ta? Sự kết thúc của một sản phẩm huyền thoại? Có lẽ. Nhưng bây giờ có nhiều phát triển chức năng hơn và hoàn toàn tương thích!

MySQL, nó chỉ là một "cơ bắp". Tôi cá rằng đây là DBMS duy nhất có sẵn theo mặc định trên dịch vụ lưu trữ của bạn. Công cụ yêu thích của các diễn đàn và blog hoạt động trên đó. Đây thực sự là tiêu chuẩn thực tế cho bất kỳ sản phẩm web nào. Và trong các dự án của bạn, rất có thể bạn sẽ sử dụng nó. Có hàng triệu trang web trên Internet truy vấn và lưu trữ dữ liệu trong cơ sở dữ liệu bằng MySQL. Và mọi chuyện thật đơn giản và rõ ràng cho đến khi Sun cùng với cơ bắp yêu thích của nó bất ngờ bị Tập đoàn Oracle mua lại. Cho rằng sản phẩm chính sau này là DBMS mạnh mẽ cùng tên, cộng đồng rất lo lắng về số phận tương lai của MySQL. Và không vô ích. Tất nhiên, Oracle đã đưa ra một tuyên bố rằng mọi thứ đều ổn: dự án sẽ tiếp tục phát triển. Nhưng nhiều người cảm thấy khó tin. Suy cho cùng, ngay cả việc phát hành nhanh phiên bản 5.5 mà nhiều người chờ đợi cũng không mang lại kết quả khả quan: những lỗi cũ vẫn còn đó. Đây đúng là tình trạng đó phải không? Nhưng song song với MySQL gốc, các dự án thay thế đã được phát triển từ lâu để tương thích với DBMS gốc, nhưng thậm chí còn vượt qua nó về nhiều mặt. Và đây là những gì chúng ta sẽ nói đến bây giờ.

Công cụ cơ sở dữ liệu - nó là gì?

Để đơn giản hóa các khái niệm một chút, cơ sở dữ liệu là một trình bao bọc xung quanh một công cụ lưu trữ dữ liệu. Nó chịu trách nhiệm nhận và quản lý các yêu cầu, bộ nhớ đệm và các chức năng dịch vụ khác, đảm bảo hoạt động với API cấp thấp của công cụ. Đến lượt nó, nó thực sự lưu trữ dữ liệu (trên đĩa hoặc trong bộ nhớ), hoạt động với hệ điều hành và đảm bảo cung cấp các mẫu cần thiết theo yêu cầu từ máy chủ. Nếu trước đây DBMS (sự kết hợp “máy chủ + công cụ”) là nguyên khối thì bây giờ tất cả các hệ thống đều sử dụng cấu trúc có plugin. Công cụ trong một tổ chức như vậy chỉ đơn giản là một mô-đun và bản thân máy chủ không phụ thuộc vào hệ thống lưu trữ dữ liệu. Các phiên bản mới nhất của MySQL cổ điển cũng sử dụng kiến ​​trúc plugin. Do đó, công cụ InnoDB tích hợp sẵn (mặc dù thường là phiên bản lỗi thời) có thể dễ dàng được thay thế bằng mô-đun từ dự án khác, điều này thường sẽ tốt hơn. Trong các phát triển thay thế cho cơ bắp, bao gồm MariaDB hoặc Drizzle, tất cả các công cụ ban đầu đều được thiết kế dưới dạng plugin. Tôi sẽ cố gắng giới thiệu ngắn gọn về các công cụ lưu trữ dữ liệu hiện đại trong các DBMS tương thích với MySQL.

  • InnoDB- công cụ chính dành cho cơ bắp, cuối cùng đã được đặt mặc định kể từ phiên bản 5.5. Hỗ trợ giao dịch, sao chép, khóa hàng. Khá chống lại sự thất bại.
  • MyISAM- một công cụ rất có vấn đề không chịu được sự cố máy chủ. Nó không hỗ trợ các giao dịch, nhưng nó có thể tự hào về các chỉ mục và tốc độ toàn văn bản. Trong một thời gian dài, nó là tiêu chuẩn cho tất cả các phiên bản MySQL và do đó nó vẫn là phiên bản phổ biến nhất.
  • Aria- thay thế MyISAM với hỗ trợ giao dịch và quản lý bộ nhớ được cải thiện. Công cụ này đảm bảo tính toàn vẹn dữ liệu và không thua kém về tốc độ so với MyISAM.
  • CVS- một công cụ chuyên dụng dành cho các trường hợp cần lưu trữ và xử lý các mảng dữ liệu chuỗi lớn được phân tách bằng dấu phẩy.
  • Liên kết/Liên kếtX- công cụ này chuyên phân phối dữ liệu một cách minh bạch trên một số máy chủ (vật lý) ở cấp độ bảng.
  • PBXT- một công cụ mới được thiết kế để thay thế InnoDB, thực hiện hỗ trợ đầy đủ cho các giao dịch, đa phiên bản và xử lý tự động các bế tắc. Công cụ được tối ưu hóa cho một số lượng lớn các giao dịch đồng thời.
  • Hố đen- một công cụ dịch vụ, về cơ bản là /dev/null cho DBMS và không thực sự tạo ra bất kỳ thao tác ghi nào vào đĩa. Được sử dụng để nhân bản.
  • Lưu trữ- một động cơ hoạt động nhanh nhất có thể để ghi âm. Được sử dụng trong trường hợp cần lưu trữ lượng lớn dữ liệu. Việc nén được sử dụng để tăng hiệu quả lưu trữ, dẫn đến tốc độ truy xuất bị chậm. Công cụ này rất phù hợp để lưu trữ lâu dài nhật ký và thông tin dịch vụ khác.
  • XtraDB- mở rộng và khắc phục một số vấn đề trong InnoDB từ Percona.
  • HỢP NHẤT- một công cụ tương tự như Federated để chia dữ liệu trong một bảng thành nhiều bảng khác nhau.
  • KÝ ỨC- một công cụ được sử dụng để lưu trữ dữ liệu không phải trên đĩa mà trong bộ nhớ. Thông tin từ cơ sở dữ liệu chỉ khả dụng khi máy chủ đang chạy, nhưng điều này giúp tăng hiệu suất rất nhiều.
  • BlitzDB- một sự thay thế khác cho MyISAM với hiệu suất tốt nhờ bộ nhớ đệm dòng tích hợp và tự động phục hồi sau lỗi. Động cơ không hỗ trợ giao dịch.
  • N.D.B.- tuy nhiên, một động cơ cho cụm có rất nhiều vấn đề và hiệu suất kém đến mức đáng buồn.
  • Chim ưng- công cụ huyền thoại của MySQL AB, được phát triển từ thời Sun, khi nó được quyết định thay thế InnoDB của Oracle.
  • Nhân sưSE- công cụ toàn văn từ người tạo ra máy chủ tìm kiếm Sphinx. Tùy chọn tốt nhất để tìm kiếm và lập chỉ mục toàn văn bản theo các quy tắc của tiếng Nga. Dễ dàng xử lý hàng terabyte dữ liệu, đồng thời cung cấp tất cả các khả năng của cơ sở dữ liệu hiện đại.

Điều quan trọng là khả năng tương thích

Vì vậy, chúng tôi đã nhận nhiệm vụ khó khăn là tìm kiếm giải pháp thay thế MySQL. Nhưng nếu chúng ta thay đổi nó thì thành gì? Đừng chạy xung quanh và hét lên "Cơ bắp của bạn tệ quá - hãy lấy con voi, đó là PostgreSQL." Sẽ không làm việc! Ngày nay, rất nhiều mã được viết với sự hỗ trợ của MySQL nên việc viết lại hoặc tìm kiếm mã thay thế sẽ tốn kém hơn. Và theo nghĩa đen - thường thì đơn giản là không thể duy trì trong giới hạn chi phí tài chính hợp lý. Thật tốt nếu chúng ta đang nói về một diễn đàn hoặc blog đơn giản (thường chúng hỗ trợ nhiều hệ thống cùng một lúc). Nhưng điều gì sẽ xảy ra nếu đó là thứ gì đó tự chế hoặc được thiết kế riêng cho khả năng của MySQL? Mọi thứ ở đây thật khó khăn. Vì vậy, nhiệm vụ của chúng tôi là bảo tồn cơ bắp (nghĩa là tương thích hoàn toàn với MySQL), nhưng tăng cường chúng để không phụ thuộc vào huấn luyện viên trưởng và steroid của ông ấy.

Bản thân các nhà phát triển và nhà tư tưởng của MySQL không phải là những kẻ ngốc và bản thân họ đã thấy trước tình hình rằng sau khi bị tiếp quản, mọi người sẽ gặp khó khăn. Một số người trong số họ thậm chí còn quyết định rời công ty và tìm ra dự án của riêng mình, lấy mã cơ bắp khi đó vẫn còn rảnh rỗi. Nhờ đó, hiện nay có một số sản phẩm thú vị dựa trên mã của máy chủ ban đầu, nhưng với những cải tiến và thay đổi lớn về mọi thứ mà các nhà phát triển có thể có được. Trước hết, những người đam mê đã giải phóng mình khỏi gánh nặng của công cụ InnoDB, quyền sở hữu từ lâu của cùng một Oracle. Để thay thế nó, một số công cụ đã được triển khai và có sẵn trong MariaDB.

Kiến trúc MySQL - hiện là hướng dẫn thiết kế DBMS vĩ đại một thời

MariaDB

Lịch sử của máy chủ này bắt nguồn từ năm 2008, khi một trong những nhà phát triển chính của MySQL, nhận ra rằng anh ta bị ràng buộc chặt chẽ bởi khuôn khổ do người chủ đặt ra, đã nghỉ việc và thành lập công ty riêng của mình, bắt đầu khắc phục những tổn thương bẩm sinh của MySQL. Tôi đang nói về công cụ MyISAM mặc định cần được thay đổi và các lỗi nghiêm trọng khiến việc sửa chữa mất một khoảng thời gian không thể chấp nhận được. Điều gì đã xảy ra với những người tạo ra MariaDB? Một sản phẩm tuyệt vời giống hệt phiên bản gốc của MySQL ở cấp độ giao thức, định dạng tệp và ngôn ngữ SQL. Điều này mang đến cơ hội chuyển đổi dễ dàng: không làm mất dữ liệu hoặc thay đổi logic của mã hiện có.

“Nhưng tôi sẽ nhận được những phần thưởng gì từ quá trình chuyển đổi?” bạn hỏi. Đổi lại, chúng ta có được tốc độ nhanh hơn và những tính năng mới có thể không bao giờ có trong cơ bắp. Ví dụ: công cụ tìm kiếm Sphinx được tích hợp vào chính máy chủ, không cần phải cài đặt riêng, khả năng quản lý dữ liệu và sao lưu nâng cao, v.v.

Phải nói rằng rất nhiều công ty rất lớn (bao gồm cả những gã khổng lồ như Google và Facebook) đã sử dụng MariaDB từ lâu. Có một bộ bản vá đặc biệt trôi nổi trên mạng, sau khi được áp dụng vào mã nguồn của cơ ban đầu sẽ giải quyết được nhiều vấn đề. Tuy nhiên, đừng mong đợi chúng xuất hiện trên máy chủ chính thức - nếu chúng không được vinh danh trong nhiều năm thì khó có thể giải quyết được ở phiên bản tiếp theo. Các nhà phát triển MariaDB vẫn không bị ràng buộc bởi các quy tắc công ty và hạn chế tiếp thị, vì vậy các bản vá lỗi và sửa lỗi mới được chấp nhận khá nhanh chóng.

Nếu cơ ban đầu nằm trên hai trụ cột - công cụ lưu trữ dữ liệu InnoDB và MyISAM, thì MariaDB sẽ sử dụng công cụ lưu trữ dữ liệu của chính nó, đóng vai trò thay thế nâng cao. Công cụ Aria đã thay thế MyISAM và trên thực tế hoạt động hiệu quả hơn nhiều nhờ bộ nhớ đệm từng dòng và định dạng đóng gói dữ liệu được tối ưu hóa. Trong khi MyISAM ban đầu hoạt động nhanh do từ chối giao dịch, điều đó có nghĩa là có thể mất dữ liệu, thì Aria vừa mạnh mẽ vừa an toàn. Nhờ các định dạng lưu trữ thông tin được cải tiến, MariaDB phục hồi sau các lỗi nhanh hơn nhiều mà không yêu cầu các quy trình xác minh dữ liệu riêng biệt sau sự cố. Công cụ InnoDB của Oracle đã được thay thế bằng XtraDB, được phát triển bởi một công ty cơ sở dữ liệu khác là Percona. Loại thứ hai được biết đến với các bản dựng MySQL với các bản vá tích hợp từ Google cũng như các công cụ quản trị nâng cao. Nhóm có một lịch sử bất thường (bạn có thể đọc thêm ở thanh bên) và hiện đang tích cực tạo ra một cơ bắp mới. Để tương thích ngược với MySQL, công cụ XtraDB trong MariaDB thậm chí còn được gọi giống hệt nhau, đó là InnoDB. Nhưng bạn cần hiểu rằng trên thực tế chỉ có tên được giữ nguyên để không nhầm lẫn phần mềm với các mã nhận dạng bất thường.

Dự án đầu tiên của công ty trẻ Oracle là phát triển một hệ thống kế toán, do các sĩ quan tình báo ủy quyền, mà tại một cuộc thi, các công ty khác đã yêu cầu 2.000.000 đô la, và Larry Ellison trẻ tuổi đã kiêu ngạo chỉ ra số tiền chỉ là 300.000 đô la. là một thất bại, nhưng công ty đã nhận được vốn ban đầu và bắt đầu đi lên.

Động cơ bổ sung

Điều đáng nói về XtraDB một cách chi tiết hơn: theo nhiều chuyên gia, đây là công cụ cơ sở dữ liệu số một trên thế giới. Hơn nữa, nó làm cho InnoDB của Oracle trông giống như một InnoDB nhỏ bé :). Tính năng chính là sự hỗ trợ đã được chờ đợi từ lâu cho các hệ thống đa lõi và đa bộ xử lý, điều mà MySQL không muốn (hoặc không thể?) tự hào. Các bản vá lỗi của Google đã giải quyết vấn đề này từ lâu, nhưng, như mọi khi, họ không buồn đưa chúng vào công cụ ban đầu, vì vậy MySQL về mặt hiệu suất thua xa bất kỳ điểm chuẩn nào. Các nhà phát triển XtraDB đã cải thiện đáng kể chiến lược sử dụng I/O ổ đĩa, chiến lược này trước đây đã hạn chế hiệu suất do quá trình chuyển dữ liệu từ bộ nhớ đệm vào đĩa bị chậm lại. Giờ đây, các tùy chọn tương ứng có thể được kiểm soát tinh vi từ cài đặt, cho phép các quản trị viên đặc biệt nâng cao tự điều chỉnh hiệu suất của daemon mà không cần chuyển sang các chuyên gia cơ sở dữ liệu đắt tiền. Hơn nữa, số liệu thống kê chi tiết về hiệu suất của động cơ có sẵn, điều này phủ nhận sự cần thiết của phần mềm thương mại đắt tiền để phân tích hiệu suất cơ sở dữ liệu. Chỉ cần một lệnh: HIỂN THỊ TRẠNG THÁI INNODB ĐỘNG CƠ. Và một điểm quan trọng là tốc độ phục hồi sau thất bại: nếu điều đó xảy ra, quá trình phục hồi sẽ không chỉ nhanh mà còn gần như phản ứng, thường nhanh hơn tới mười lần so với trong MySQL. Và còn nhiều điều nhỏ nhặt khác: bộ đệm ghi, điểm kiểm tra thích ứng và số lượng giao dịch mở tăng lên. Tất cả điều này sẽ cho phép máy chủ hoạt động tốt trong điều kiện rất tải.

Nếu điều này vẫn chưa đủ đối với bạn và bạn gật đầu với Firebird hoặc PosgreSQL, gợi ý rằng có hỗ trợ đầy đủ cho mô hình giao dịch và thậm chí cả MVCC (Kiểm soát đồng thời đa phiên bản - một mô hình dữ liệu cạnh tranh dựa trên phiên bản, cho phép cập nhật và đọc mà không cần chặn cùng một hàng dữ liệu) - hãy thư giãn. MariaDB có công cụ PBXT, trong một số trường hợp thậm chí còn mát hơn tất cả những công cụ trên. Tuy nhiên, cần phải nói ngay rằng nó không quá phổ biến và bạn cần biết cách nấu nó! PBXT được thiết kế chủ yếu cho một số lượng lớn các giao dịch ghi hoặc thay đổi dữ liệu, hỗ trợ khôi phục nhanh và có thể giải quyết các tình huống phức tạp với việc chặn và bế tắc. Ví dụ: nếu bạn muốn tạo một bộ lưu trữ nhật ký, thì bạn sẽ có một số lượng lớn thao tác ghi vào bảng, nhưng tương đối ít thao tác đọc. Đồng thời, nếu ai đó vẫn muốn thực hiện lựa chọn từ cơ sở dữ liệu, anh ta sẽ nhận được dữ liệu gần đây nhất mà không can thiệp vào việc ghi dữ liệu mới. Và đối với những kẻ thực sự hư hỏng, có công cụ FederatedX, có thể phân phối bảng dữ liệu trên một số máy chủ vật lý, cũng như OQGRAPH, được tối ưu hóa để lưu trữ các cấu trúc, đồ thị và cây phân cấp. Một cách tiếp cận lý tưởng để tạo một bản sao của Facebook và nơi bạn cần làm việc với biểu đồ xã hội về mối quan hệ giữa mọi người, biểu đồ này không phù hợp lắm với mô hình cơ sở dữ liệu thông thường.

Điện toán đám mây

Các nhà phát triển của một dự án khác - Drizzle - đã đi theo một con đường hơi khác và quyết định xem xét lại hoàn toàn vị trí của cơ sở dữ liệu trong cơ sở hạ tầng của một dự án điển hình. Chúng tôi nhớ lại những gì đang là mốt hiện nay: điện toán đám mây, Bộ đệm Google Proto, khả năng mở rộng, đa lõi, v.v. Và chúng tôi nghĩ: cơ sở dữ liệu cũng phải di chuyển cùng với các công nghệ hiện đại và không bị bỏ lại phía sau, bất kể nó đang chạy gì - công cụ blog hay hệ thống CRM của công ty lớn. Trong im lặng, người ta đã quyết định đơn giản hóa chức năng của MySQL ban đầu, loại bỏ các tính năng kéo dài từ bản phát hành này sang bản phát hành khác, điều mà trên thực tế rất ít người cần. Hệ thống đã mất hỗ trợ cho các ổ cắm UNIX (điều này, mặc dù còn gây tranh cãi, là một giải pháp hoàn toàn có thể chấp nhận được do nó tập trung vào môi trường đám mây) và phiên bản dành cho Windows. Mưa phùn không có bất kỳ cơ sở dữ liệu dịch vụ nào và nhiều thứ thông thường khác. Nhưng sau đó có gì?

Mưa phùn, nhờ kiến ​​trúc vi nhân và plugin đơn giản, có thể làm được rất nhiều việc

Và có một kiến ​​trúc với vi nhân, chứa tất cả các hoạt động cơ bản và hỗ trợ giao thức, cũng như hệ thống plugin cho phép bạn mở rộng hệ thống theo bất kỳ hướng nào và ở bất kỳ độ sâu nào. Một trong những thành phần chính của hệ thống là giao thức nhị phân của Google - Protocol Buffer. Nó được sử dụng để mô tả cả bảng và dữ liệu, đồng thời cũng được sử dụng để sao chép. Điểm nhấn chính trong quá trình phát triển là hỗ trợ tối đa đa luồng và đa xử lý, vì vậy khả năng mở rộng là thành tựu chính của các nhà phát triển. Hỗ trợ cho cả giao thức MySQL tiêu chuẩn và phiên bản riêng của nó được triển khai - thông qua thư viện libdrizzle và trình điều khiển cho hầu hết các ngôn ngữ phổ biến, bao gồm Perl, PHP, Python và Lua. Nếu muốn, bạn có thể sử dụng thư viện máy khách mà không cần đến máy chủ: trong trường hợp này, bạn sẽ có quyền truy cập không đồng bộ hiệu quả vào MySQL yêu thích của mình. Vì cùng một công ty cũng đã phát triển hệ thống Gearman nên Drizzle đã tích hợp sẵn tính năng hỗ trợ đăng nhập vào môi trường phân tán, bộ nhớ đệm gốc trong memcache và thậm chí cả các tính năng nâng cao như sao chép thông qua hệ thống nhắn tin như RabbitMQ (bao gồm cả công nghệ WebSocket mới). Drizzle sử dụng phiên bản đặc biệt của InnoDB làm công cụ lưu trữ dữ liệu chính, được thiết kế lại đáng kể và bổ sung một bộ bản vá của bên thứ ba. Động cơ XtraDB và PBXT cũng có sẵn. Nếu các phiên bản đầu tiên của Drizzle dựa trên MySQL 5.0 thì giờ đây DBMS ban đầu chỉ còn lại rất ít. Đây là một mã gần như được viết lại hoàn toàn với sự quan tâm tối thiểu đến những người thân cũ. Hiện tại, quá trình phát triển Drizzle đang ở trạng thái tích cực và bản phát hành ổn định đầu tiên được lên kế hoạch vào mùa xuân.

Xu hướng NoSQL

Bạn có thể biết về cái mới. Về bản chất, đây là sự từ chối máy chủ cơ sở dữ liệu truyền thống với các bảng và truy vấn SQL của nó, đồng thời chuyển sang sơ đồ lưu trữ dữ liệu khóa-giá trị đơn giản nhất. Để triển khai tính năng sau, các loại dữ liệu nâng cao như danh sách/băm (trong Redis) hoặc, ví dụ: định dạng JSON (trong MongoDB) thường được sử dụng. Nhưng điều gì ngăn cản bạn vượt qua con trăn và con nhím, một mặt sử dụng tất cả sức mạnh và công nghệ đã được chứng minh qua nhiều năm của cơ sở dữ liệu và công cụ của chúng, mặt khác, một giao thức đơn giản hóa và việc loại bỏ một lớp rườm rà dưới dạng xử lý ngôn ngữ truy vấn SQL? Không có gì ngăn cản được những người thừa kế nghiêm khắc của samurai: những người Nhật Bản đến từ Yoshinori Matsunobu đã tạo ra plugin HandlerSocket, biến công cụ InnoDB tiêu chuẩn thành bộ lưu trữ NoSQL nâng cao mà không can thiệp vào công việc của SQL thông thường. Tốc độ hoạt động rất ấn tượng: lên tới 750.000 thao tác mỗi giây! Không có gì ngạc nhiên khi Percona ngay lập tức áp dụng plugin này và đưa nó vào bản dựng máy chủ của họ. Mát mẻ! Tuy nhiên, mặt khác, làm cách nào khác, nếu không phải là một chiếc nạng, bạn có thể gọi một giải pháp bắt chước những gì một cơ sở dữ liệu bình thường như Drizzle thực hiện ngay lập tức do kiến ​​trúc bên trong của nó?

Rút ra kết luận

Nếu bạn lo lắng về sự phát triển của MySQL, bạn không thích các chính sách của Oracle và bạn có lý khi lo sợ rằng ngày mai bạn sẽ bị buộc phải trả tiền cho chức năng miễn phí ngày hôm qua, hãy nhìn xung quanh. Cộng đồng phản ứng với việc mua MySQL là khởi đầu cho sự suy tàn của công nghệ từng đưa web hiện đại lên tầm cao không thể đạt tới nhờ ngăn xếp LAMP (Linux-Apache-MySQL-PHP). Các nhà phát triển chính đã bắt đầu phát triển các nhánh của riêng họ, một số trong đó đã vượt trội so với MySQL cũ. Họ có nhiều nhân vật mang tính biểu tượng và một cộng đồng cởi mở đằng sau họ. Sau khi thực hiện mọi thứ một cách khôn ngoan, các nhà phát triển đã cố gắng duy trì khả năng tương thích bên ngoài 100% với các ứng dụng và giao thức. Do đó, tất cả những ai muốn cài đặt một máy chủ mới sẽ không bị hỏng: dữ liệu sẽ được lưu và các ứng dụng sẽ không phải viết lại. Nhiều người sẽ không nhận thấy bất kỳ sự khác biệt nào cả, ngoại trừ tốc độ và độ tin cậy được tăng lên.

Bây giờ bạn có thể thay thế máy chủ cơ sở dữ liệu của mình để các ứng dụng hiện tại thậm chí sẽ không cảm thấy sự khác biệt, đồng thời đạt được tốc độ, độ tin cậy cao hơn nhiều và nhiều tính năng không có sẵn trong cơ bản ban đầu. MariaDB với một bộ công cụ là một lựa chọn tuyệt vời để bắt đầu. Chà, nếu bạn đang nghĩ đến một dự án hoành tráng với số lượng lớn máy chủ và hàng gigabyte dữ liệu, hãy xem Drizzle. Với tư cách là một sản phẩm phần mềm và máy chủ cơ sở dữ liệu, đây là một sự phát triển rất hứa hẹn và chắc chắn sẽ thành công trong năm nay. Nếu bạn muốn sự ổn định và hỗ trợ từ các chuyên gia cơ sở dữ liệu tốt nhất, đừng ngại rời bỏ Oracle và tìm đến Percon. Họ đang tặng miễn phí phiên bản DBMS của họ - sửa lỗi nhiều nhất có thể và bổ sung các tính năng để tăng hiệu suất của MySQL gốc mà không ảnh hưởng đến khả năng tương thích. Bạn vẫn ngồi trên cơ cũ đó à? Sau đó chúng tôi sẽ đến với bạn!