Cái nào tốt hơn – Oracle hay Redis hoặc Cách biện minh cho việc lựa chọn nền tảng

“Điều này là cần thiết,” cô nói to mà không nói với ai. - Điều này là cần thiết! Đây chính xác là những gì nó nói: nhiệm vụ chính của một công ty là tạo ra lợi nhuận vì lợi ích của các cổ đông. Vâng, hãy nghĩ về nó! Họ không sợ bất cứ điều gì!

Yuliy Dubov, “Cái ác nhỏ hơn”

Khi nhìn thấy tiêu đề như vậy, có lẽ bạn đã quyết định rằng bài viết này là ngu ngốc hoặc mang tính khiêu khích. Nhưng đừng vội kết luận: nhân viên của các tập đoàn lớn, đặc biệt là các tập đoàn có sự tham gia của nhà nước, thường phải so sánh các nền tảng khác nhau, bao gồm cả những nền tảng hoàn toàn khác nhau - ví dụ như những nền tảng trong tiêu đề.

Cái nào tốt hơn – Oracle hay Redis hoặc Cách biện minh cho việc lựa chọn nền tảng

Tất nhiên, không ai so sánh các DBMS theo cách này, vì điểm mạnh và điểm yếu của chúng đều được biết rõ. Theo quy định, các nền tảng giải quyết một số vấn đề ứng dụng sẽ được so sánh. Trong bài viết, tôi sẽ trình bày phương pháp được sử dụng trong trường hợp này, sử dụng ví dụ về cơ sở dữ liệu làm chủ đề quen thuộc với độc giả Habr. Vì thế,

Động lực

Khi bạn bắt đầu một dự án giáo dục hoặc một dự án sở thích, động lực để chọn một nền tảng có thể rất đa dạng: “đây là nền tảng mà tôi biết rõ nhất”, “Tôi muốn tìm hiểu về nền tảng này”, “đây là tài liệu tốt nhất” ... Trong trường hợp là một công ty thương mại, tiêu chí lựa chọn là như nhau: tôi sẽ phải trả bao nhiêu và tôi sẽ nhận được gì với số tiền này.

Đương nhiên, bạn muốn trả ít hơn và nhận được nhiều hơn. Tuy nhiên, bạn cần phải quyết định điều gì quan trọng hơn - trả ít hơn hoặc nhận được nhiều hơn và chỉ định trọng số cho mỗi nút. Giả sử rằng đối với chúng tôi, giải pháp chất lượng cao quan trọng hơn giải pháp giá rẻ và chúng tôi chỉ định trọng số 40% cho nút “Chi phí” và 60% cho nút “Cơ hội”.

Cái nào tốt hơn – Oracle hay Redis hoặc Cách biện minh cho việc lựa chọn nền tảng

Ở các tập đoàn lớn, điều ngược lại thường đúng - tỷ trọng chi phí không giảm xuống dưới 50% và có thể hơn 60%. Trong ví dụ về mô hình, điều quan trọng là tổng trọng số của các nút con của bất kỳ nút cha nào phải là 100%.

Điều kiện cắt

Địa điểm db-engines.com Có khoảng 500 hệ thống quản lý cơ sở dữ liệu được biết đến. Đương nhiên, nếu bạn chọn một nền tảng mục tiêu trong số rất nhiều lựa chọn, bạn có thể kết thúc với một bài viết đánh giá chứ không phải một dự án thương mại. Để giảm không gian lựa chọn, các tiêu chí giới hạn được xây dựng và nếu nền tảng không đáp ứng các tiêu chí này thì nó sẽ không được xem xét.

Tiêu chí giới hạn có thể liên quan đến các tính năng công nghệ, ví dụ:

  • Đảm bảo ACID;
  • mô hình dữ liệu quan hệ;
  • Hỗ trợ ngôn ngữ SQL (lưu ý, điều này không giống với “mô hình quan hệ”);
  • khả năng mở rộng quy mô theo chiều ngang.

Có thể có tiêu chí chung:

  • sự sẵn có của hỗ trợ thương mại ở Nga;
  • mã nguồn mở;
  • tính sẵn có của nền tảng trong Sổ đăng ký của Bộ Viễn thông và Truyền thông đại chúng;
  • sự hiện diện của nền tảng trong một số xếp hạng (ví dụ: trong hàng trăm xếp hạng đầu tiên của db-engines.com);
  • sự hiện diện của các chuyên gia trên thị trường (ví dụ: dựa trên kết quả tìm kiếm tên của nền tảng trong sơ yếu lý lịch trên trang web hh.ru).

Rốt cuộc, có thể có các tiêu chí dành riêng cho doanh nghiệp:

  • sự sẵn có của các chuyên gia trong đội ngũ nhân viên;
  • khả năng tương thích với hệ thống giám sát X hoặc hệ thống dự phòng Y, dựa trên đó mọi hỗ trợ đều dựa trên...

Điều quan trọng nhất là có một danh sách các tiêu chí giới hạn. Nếu không, chắc chắn sẽ có một số chuyên gia (hoặc “chuyên gia”) nhận được sự tin tưởng đặc biệt từ ban lãnh đạo sẽ nói “tại sao bạn không chọn nền tảng Z, tôi biết nó là tốt nhất”.

Dự toán chi phí

Chi phí của giải pháp rõ ràng bao gồm chi phí giấy phép, chi phí hỗ trợ và chi phí thiết bị.

Nếu các hệ thống gần như cùng loại (ví dụ: Microsoft SQL Server và PostgreSQL), thì để đơn giản, chúng ta có thể giả định rằng số lượng thiết bị cho cả hai giải pháp sẽ gần như nhau. Điều này sẽ cho phép bạn không đánh giá thiết bị, từ đó tiết kiệm rất nhiều thời gian và công sức. Nếu bạn phải so sánh các hệ thống hoàn toàn khác nhau (ví dụ: Oracle so với Redis), thì rõ ràng là để đánh giá chính xác, cần phải thực hiện định cỡ (tính toán số lượng thiết bị). Định cỡ một hệ thống không tồn tại là một nhiệm vụ rất bạc bẽo, vì vậy họ vẫn cố gắng tránh những so sánh như vậy. Điều này rất dễ thực hiện: trong các điều kiện giới hạn, không mất dữ liệu và mô hình quan hệ được ghi hoặc ngược lại - tải 50 nghìn giao dịch mỗi giây.

Để đánh giá giấy phép, chỉ cần hỏi nhà cung cấp hoặc đối tác của họ về chi phí giấy phép cho một số lõi cố định và hỗ trợ trong một khoảng thời gian cố định là đủ. Theo quy định, các công ty đã có mối quan hệ chặt chẽ với các nhà cung cấp phần mềm và nếu bộ phận vận hành cơ sở dữ liệu không thể tự mình trả lời câu hỏi về chi phí thì chỉ cần một lá thư là đủ để có được thông tin này.

Các nhà cung cấp khác nhau có thể có các số liệu cấp phép khác nhau: theo số lượng lõi, khối lượng dữ liệu hoặc số lượng nút. Cơ sở dự phòng có thể miễn phí hoặc có thể được cấp phép giống như cơ sở chính. Nếu phát hiện ra bất kỳ sự khác biệt nào về số liệu, bạn sẽ phải mô tả chi tiết mô hình và tính toán chi phí giấy phép cho giá đỡ.

Một điểm quan trọng để so sánh chính xác là các điều kiện hỗ trợ giống nhau. Ví dụ: chi phí hỗ trợ của Oracle là 22% giá giấy phép mỗi năm, nhưng bạn không phải trả tiền cho hỗ trợ PostgreSQL. So sánh như vậy có đúng không? Không, bởi vì một lỗi không thể tự sửa được sẽ gây ra những hậu quả hoàn toàn khác: trong trường hợp đầu tiên, các chuyên gia hỗ trợ sẽ nhanh chóng giúp bạn khắc phục, nhưng trong trường hợp thứ hai, có nguy cơ làm dự án bị trì hoãn hoặc thời gian ngừng hoạt động của dự án đã hoàn thành. hệ thống trong một khoảng thời gian không xác định.

Bạn có thể cân bằng các điều kiện tính toán theo ba cách:

  1. Sử dụng Oracle mà không cần hỗ trợ (thực tế điều này không xảy ra).
  2. Mua hỗ trợ cho PostgreSQL - ví dụ: từ Postgres Professional.
  3. Hãy tính đến những rủi ro liên quan đến việc thiếu sự hỗ trợ.

Ví dụ: tính toán rủi ro có thể như sau: trong trường hợp cơ sở dữ liệu bị lỗi nghiêm trọng, thời gian ngừng hoạt động của hệ thống sẽ là 1 ngày làm việc. Dự kiến ​​lợi nhuận từ việc sử dụng hệ thống là 40 tỷ MNT/năm, tỷ lệ tai nạn ước tính là 1/400, do đó rủi ro thiếu hỗ trợ ước tính khoảng 100 triệu MNT/năm. Rõ ràng, “lợi nhuận dự kiến” và “tần suất tai nạn ước tính” là những giá trị ảo, nhưng thà có một mô hình như vậy còn hơn là không có mô hình nào.

Trên thực tế, hệ thống có thể quá quan trọng nên chi phí danh tiếng của thời gian ngừng hoạt động lâu dài là không thể chấp nhận được, vì vậy sẽ cần có sự hỗ trợ. Nếu thời gian ngừng hoạt động được cho phép thì việc từ chối hỗ trợ đôi khi có thể là một cách hay để tiết kiệm tiền.

Giả sử sau khi tính toán xong, chi phí vận hành nền tảng A trong 5 năm là 800 triệu MNT, chi phí vận hành nền tảng B là 650 triệu MNT và chi phí vận hành nền tảng C là 600 triệu MNT. Nền tảng C, với tư cách là người chiến thắng, nhận được toàn bộ điểm cho mức giá, trong khi nền tảng A và B nhận được ít hơn một chút, tương ứng với số lần chúng đắt hơn. Trong trường hợp này – lần lượt là 0.75 và 0.92 điểm.

Đánh giá cơ hội

Việc đánh giá các cơ hội được chia thành nhiều nhóm, số lượng trong số đó chỉ bị giới hạn bởi trí tưởng tượng của người thực hiện đánh giá. Lựa chọn tối ưu dường như là chia các khả năng thành các nhóm sẽ sử dụng các khả năng này; trong ví dụ của chúng tôi, đây là những nhà phát triển, quản trị viên và nhân viên bảo mật thông tin. Giả sử rằng trọng số của các hàm này được phân phối là 40:40:20.

Các chức năng phát triển bao gồm:

  • dễ dàng thao tác dữ liệu;
  • nhân rộng;
  • sự hiện diện của các chỉ số phụ.

Danh sách các tiêu chí cũng như trọng lượng của chúng rất chủ quan. Ngay cả khi giải quyết cùng một vấn đề, các danh sách, trọng số mục và câu trả lời này sẽ khác nhau đáng kể tùy thuộc vào thành phần nhóm của bạn. Ví dụ: Facebook sử dụng MySQL để lưu trữ dữ liệu và Instagram được xây dựng trên Cassandra. Không chắc các nhà phát triển của những ứng dụng này đã điền vào các bảng như vậy. Người ta chỉ có thể đoán rằng Mark Zuckerberg đã chọn một mô hình quan hệ chính thức, trả tiền cho nó bằng nhu cầu sử dụng sharding, trong khi Kevin Systrom xây dựng quy mô bằng cách sử dụng nền tảng, hy sinh khả năng truy cập dữ liệu dễ dàng.

Chức năng quản trị bao gồm:

  • khả năng của hệ thống dự phòng;
  • dễ dàng giám sát;
  • dễ dàng quản lý dung lượng – đĩa và nút;
  • khả năng sao chép dữ liệu.

Xin lưu ý rằng các câu hỏi phải được diễn đạt một cách định lượng. Bạn thậm chí có thể đồng ý về cách đánh giá một chức năng cụ thể. Ví dụ: hãy thử xếp hạng các công cụ sao lưu bằng cách sử dụng ví dụ về các công cụ được cung cấp cùng với Oracle DBMS:

Công cụ
Bình luận
Đánh giá

imp/exp
Tải lên và tải dữ liệu
0.1

bắt đầu/kết thúc sao lưu
Sao chép các tập tin
0.3

RMAN
Khả năng sao chép gia tăng
0.7

ZDLRA
Chỉ sao chép tăng dần, phục hồi điểm nhanh nhất
1.0

Nếu không có tiêu chí đánh giá rõ ràng, bạn nên yêu cầu một số chuyên gia đưa ra xếp hạng và sau đó tính trung bình cho chúng.

Cuối cùng, chúng tôi chỉ liệt kê các chức năng bảo mật thông tin:

  • sự sẵn có của các chính sách quản lý mật khẩu;
  • khả năng kết nối các công cụ xác thực bên ngoài (LDAP, Kerberos);
  • hình mẫu về quyền truy cập;
  • năng lực kiểm toán;
  • mã hóa dữ liệu trên đĩa;
  • mã hóa trong quá trình truyền qua mạng (TLS);
  • bảo vệ dữ liệu từ quản trị viên.

Kiểm tra năng suất

Riêng biệt, tôi muốn cảnh báo không nên sử dụng kết quả của bất kỳ thử nghiệm tải nào không phải do bạn thực hiện làm đối số.

Thứ nhất, cấu trúc dữ liệu và cấu hình tải của ứng dụng đang được thử nghiệm có thể khác biệt đáng kể so với vấn đề bạn sắp giải quyết. Khoảng 10-15 năm trước, các nhà cung cấp cơ sở dữ liệu thích khoe khoang kết quả đạt được trong các bài kiểm tra TPC, nhưng hiện nay, có vẻ như không ai coi trọng những kết quả này.

Thứ hai, hiệu năng của hệ thống phụ thuộc khá nhiều vào nền tảng mà mã ban đầu được viết cho và thử nghiệm được thực hiện trên thiết bị nào. Tôi đã thấy nhiều thử nghiệm so sánh Oracle với PostgreSQL. Kết quả bao gồm từ tính ưu việt vô điều kiện của một hệ thống đến tính ưu việt vô điều kiện tương đương của hệ thống khác.

Và cuối cùng, thứ ba, bạn không biết gì về người thực hiện bài kiểm tra. Cả hai bằng cấp đều quan trọng, ảnh hưởng đến chất lượng thiết lập hệ điều hành và nền tảng, cũng như động lực, điều này ảnh hưởng đến kết quả kiểm tra nhiều hơn tất cả các yếu tố khác cộng lại.

Nếu hiệu suất là yếu tố quan trọng, hãy tự mình tiến hành kiểm tra, tốt nhất là với sự trợ giúp của những người sẽ cấu hình và bảo trì hệ thống sản xuất.

Kết quả

Cuối cùng, kết quả của tất cả công việc đã thực hiện sẽ là một bảng tính trong đó tất cả các ước tính được kết hợp, nhân lên và tổng hợp:

Cái nào tốt hơn – Oracle hay Redis hoặc Cách biện minh cho việc lựa chọn nền tảng

Như bạn hiểu, bằng cách thay đổi thang đo và điều chỉnh xếp hạng, bạn có thể đạt được bất kỳ kết quả mong muốn nào, nhưng đó lại là một câu chuyện hoàn toàn khác...

Nguồn: www.habr.com

Thêm một lời nhận xét