11 cơ sở dữ liệu nguồn mở hàng đầu cho dự án tiếp theo của bạn

Dữ liệu là tất cả. Và bằng cách mở rộng, cơ sở dữ liệu cũng vậy. Dưới đây là một số tùy chọn mã nguồn mở tuyệt vời cho dự án kick-ass tiếp theo của bạn.


Đối với một thế giới bị thống trị quá lâu bởi các cơ sở dữ liệu như Oracle và SQL Server, dường như có vô số giải pháp hiện nay. Một phần lý do là sự đổi mới được thúc đẩy bởi Nguồn mở – các nhà phát triển thực sự tài năng muốn gãi ngứa và tạo ra thứ gì đó mà họ có thể khám phá.

Phần khác là sự xuất hiện của các mô hình kinh doanh mới, trong đó các doanh nghiệp duy trì phiên bản cộng đồng của sản phẩm để đạt được sự chia sẻ và lực kéo, đồng thời cung cấp dịch vụ bổ sung, thương mại.

Kết quả?

Nhiều cơ sở dữ liệu hơn một có thể theo kịp. Không có thống kê chính thức nào về vấn đề này, nhưng tôi chắc chắn rằng chúng tôi có hơn một trăm tùy chọn có sẵn ngày hôm nay nếu bạn kết hợp mọi thứ từ cơ sở dữ liệu đối tượng cụ thể đến các dự án không phổ biến từ các trường đại học.

Tôi biết, nó cũng làm tôi sợ. Quá nhiều lựa chọn – quá nhiều tài liệu để trải qua – và một cuộc đời quá ngắn ngủi. ��

Đó là lý do tại sao tôi quyết định viết bài viết này, trình bày mười cơ sở dữ liệu tốt nhất bạn có thể sử dụng để cải thiện các giải pháp của mình, cho dù là xây dựng cho chính bạn hay người khác.

Không có MySQL

Xin lưu ý: danh sách này không phải là sẽ có MySQL, mặc dù nó được cho là giải pháp cơ sở dữ liệu nguồn mở phổ biến nhất hiện có.

Tại sao? Đơn giản là vì MySQL có ở khắp mọi nơi – nó là thứ mà mọi người học được trước tiên, nó được hỗ trợ bởi hầu hết mọi CMS hoặc khung ngoài đó, và nó rất tốt cho hầu hết các trường hợp sử dụng. Nói cách khác, MySQL không cần phải được phát hiện ra. ��

Điều đó nói rằng, xin lưu ý rằng aren sau đây nhất thiết phải thay thế cho MySQL. Trong một số trường hợp, họ có thể, trong khi ở những người khác, họ lại là một giải pháp hoàn toàn khác cho một nhu cầu hoàn toàn khác. Đừng lo lắng, vì tôi cũng sẽ thảo luận về việc sử dụng chúng.

Lưu ý đặc biệt: khả năng tương thích

Trước khi chúng tôi bắt đầu, tôi cũng phải đề cập rằng khả năng tương thích là điều bạn cần lưu ý. Nếu bạn có một dự án, vì bất kỳ lý do gì, chỉ hỗ trợ một công cụ cơ sở dữ liệu cụ thể, các lựa chọn của bạn sẽ được đưa ra khá nhiều.

Chẳng hạn, nếu bạn đang chạy WordPress, bài viết này không có ích gì cho bạn. Tương tự, những trang web đang chạy trên JAMStack sẽ không thu được gì bằng cách tìm kiếm các lựa chọn thay thế quá nghiêm túc.

Nó phụ thuộc vào bạn để tìm ra phương trình tương thích. Tuy nhiên, nếu bạn có một bảng trống và kiến ​​trúc tùy thuộc vào bạn, đây là một số đề xuất gọn gàng.

PostgreSQL

Nếu bạn tấn công từ vùng đất PHP (WordPress, Magento, Drupal, v.v.), thì PostgreSQL sẽ âm thanh xa lạ với bạn. Tuy nhiên, giải pháp cơ sở dữ liệu quan hệ này đã có từ năm 1997 và là lựa chọn hàng đầu trong các cộng đồng như Ruby, Python, Go, v.v..

Trên thực tế, nhiều nhà phát triển cuối cùng đã chuyển sang tốt nghiệp trực tuyến cho PostgreSQL về các tính năng mà nó cung cấp hoặc đơn giản là vì sự ổn định. Thật khó để thuyết phục ai đó trong một bài viết ngắn như thế này nhưng hãy nghĩ rằng PostgreSQL là một sản phẩm được thiết kế chu đáo không bao giờ làm bạn thất vọng.

Có rất nhiều máy khách SQL tốt có sẵn để kết nối với cơ sở dữ liệu PostgreSQL để quản trị và phát triển.

Các tính năng độc đáo

PostgreSQL có một số tính năng hấp dẫn so với các cơ sở dữ liệu quan hệ khác (cụ thể là MySQL), chẳng hạn như:

  • Các kiểu dữ liệu tích hợp cho Mảng, Phạm vi, UUID, Định vị địa lý, v.v..
  • Hỗ trợ riêng cho lưu trữ tài liệu (kiểu JSON), XML và lưu trữ khóa-giá trị (Hstore)
  • Nhân rộng đồng bộ và không đồng bộ
  • Scriptable bằng PL, Perl, Python và hơn thế nữa
  • Tìm kiếm toàn văn

Sở thích cá nhân của tôi là công cụ định vị địa lý (giúp loại bỏ nỗi đau khi làm việc với các ứng dụng dựa trên vị trí – hãy thử tìm tất cả các điểm lân cận theo cách thủ công và bạn sẽ hiểu ý tôi) và hỗ trợ cho mảng (nhiều dự án MySQL không muốn thay vào đó, lựa chọn thay thế cho các chuỗi được phân tách bằng dấu phẩy).

Khi nào nên sử dụng PostgreSQL

PostgreSQL luôn là lựa chọn tốt hơn bất kỳ công cụ cơ sở dữ liệu quan hệ nào khác. Đó là, nếu bạn đã bắt đầu một dự án mới và đã bị MySQL cắn trước đó, thì đó là thời điểm tốt để xem xét PostgreQuery. Tôi có những người bạn đã từ bỏ việc chiến đấu với các lỗi khóa giao dịch bí ẩn của MySQL và di chuyển vĩnh viễn. Nếu bạn quyết định như vậy, bạn đã thắng được phản ứng thái quá.

PostgreSQL cũng có một lợi thế rõ ràng nếu bạn cần một phần tiện ích NoQuery cho một mô hình dữ liệu lai. Vì lưu trữ tài liệu và khóa-giá trị được hỗ trợ nguyên bản, bạn không cần phải đi săn, cài đặt, học và duy trì một giải pháp cơ sở dữ liệu khác.

Khi nào không sử dụng PostgreSQL

PostgreSQL không có ý nghĩa khi mô hình dữ liệu của bạn không phải là mối quan hệ và / hoặc khi bạn có các yêu cầu kiến ​​trúc rất cụ thể. Ví dụ: hãy xem xét Analytics, nơi các báo cáo mới liên tục được tạo từ dữ liệu hiện có. Các hệ thống như vậy rất nặng và chịu đựng khi áp dụng một lược đồ nghiêm ngặt đối với chúng. Chắc chắn, PostgreSQL có một công cụ lưu trữ tài liệu, nhưng mọi thứ bắt đầu sụp đổ khi bạn xử lý các bộ dữ liệu lớn.

Nói cách khác, luôn luôn sử dụng PostgreSQL, trừ khi bạn biết 100% những gì bạn đang làm! ��

Kiểm tra này SQL & Khóa học dành cho người mới bắt đầu nếu thích tìm hiểu thêm.

MariaDB

MariaDB được tạo ra để thay thế cho MySQL, bởi cùng một người đã phát triển MySQL.

Bối rối?

Chà, thực ra, sau khi MySQL bị Oracle tiếp quản vào năm 2010 (bằng cách mua lại Sun microsystems, tình cờ, đó cũng là cách mà Oracle đến để kiểm soát Java), người tạo ra MySQL đã bắt đầu một dự án nguồn mở mới có tên MariaDB.

Tại sao tất cả các chi tiết nhàm chán này, bạn hỏi? Nó vì MariaDB được tạo ra từ cùng một cơ sở mã với MySQL (trong thế giới nguồn mở, điều này được biết đến với tên là for forking một dự án hiện có). Kết quả là, MariaDB được trình bày như là một sự thay thế trong trò chơi thả xuống của MySQL cho MySQL.

Đó là, nếu bạn sử dụng MySQL và muốn chuyển sang MariaDB, quá trình này dễ dàng đến mức bạn chỉ cần giành chiến thắng..

Thật không may, một cuộc di cư như vậy là một con đường một chiều. Quay trở lại từ MariaDB sang MySQL là không thể, và nếu bạn cố gắng sử dụng vũ lực, tham nhũng cơ sở dữ liệu vĩnh viễn được đảm bảo!

Các tính năng độc đáo

Mặc dù MariaDB về cơ bản là một bản sao của MySQL, nhưng nó không hoàn toàn đúng. Kể từ khi giới thiệu cơ sở dữ liệu, sự khác biệt giữa hai đã ngày càng lớn. Khi viết, việc áp dụng MariaDB cần phải là một quyết định sáng suốt từ phía bạn. Điều đó nói rằng, có rất nhiều điều mới đang diễn ra trong MariaDB có thể giúp bạn thực hiện quá trình chuyển đổi này:

  • Thực sự miễn phí và cởi mở: Vì không có tổ chức doanh nghiệp nào kiểm soát MariaDB, bạn có thể không bị cấp phép đột ngột và những lo lắng khác.
  • Một số tùy chọn khác của công cụ lưu trữ cho các nhu cầu chuyên biệt: ví dụ: công cụ Spider cho các giao dịch phân tán; CộtStore cho kho dữ liệu lớn; công cụ ColumnStore để lưu trữ song song, phân tán; Và nhiều nhiều hơn nữa.
  • Cải thiện tốc độ so với MySQL, đặc biệt là do công cụ lưu trữ Aria cho các truy vấn phức tạp.
  • Các cột động cho các hàng khác nhau trong một bảng.
  • Khả năng nhân rộng tốt hơn (ví dụ, nhân rộng đa nguồn)
  • Một số hàm JSON
  • Cột ảo

. . . Và nhiều nhiều hơn nữa. Nó làm kiệt sức để theo kịp tất cả các tính năng của MariaDB. ��

Khi nào nên sử dụng MariaDB

Bạn nên MariaDB nếu bạn muốn một sự thay thế thực sự của MySQL, muốn tiếp tục phát triển và đổi kế hoạch trở lại MySQL một lần nữa. Một trường hợp sử dụng tuyệt vời là việc sử dụng các công cụ lưu trữ mới trong MariaDB để bổ sung cho mô hình dữ liệu quan hệ hiện có của dự án của bạn.

Khi nào không sử dụng MariaDB

Khả năng tương thích với MySQL là mối quan tâm duy nhất ở đây. Điều đó nói rằng, nó trở thành một vấn đề ít hơn khi các dự án như WordPress, Joomla, Magento, v.v., đã bắt đầu hỗ trợ MariaDB. Lời khuyên của tôi là không nên sử dụng MariaDB để lừa một CMS không hỗ trợ nó, vì có nhiều thủ thuật dành riêng cho cơ sở dữ liệu sẽ dễ dàng đánh sập hệ thống.

Gián

Đội ngũ đằng sau CockroachDB dường như bao gồm các masochists. Với một tên sản phẩm như vậy, chắc chắn họ muốn biến mọi tỷ lệ cược với họ và vẫn giành chiến thắng?

Chà, không hẳn.

Ý tưởng đằng sau con gà trống con gà trống là nó là một loài côn trùng được chế tạo để sinh tồn. Bất kể điều gì xảy ra – động vật ăn thịt, lũ lụt, bóng tối vĩnh cửu, thức ăn thối rữa, ném bom, con gián tìm cách sống sót và nhân lên.

Ý tưởng là nhóm đằng sau CockroachDB (bao gồm các cựu kỹ sư của Google) đã thất vọng với những hạn chế của các giải pháp SQL truyền thống khi nói đến quy mô lớn. Đó là vì các giải pháp SQL trong lịch sử được cho là được lưu trữ trên một máy duy nhất (dữ liệu không lớn như vậy). Trong một thời gian dài, không có cách nào để xây dựng một cụm cơ sở dữ liệu chạy SQL, đó là lý do tại sao MongoDB thu hút được nhiều sự chú ý.

Ngay cả khi sao chép và phân cụm xuất hiện trong MySQL, PostgreSQL và MariaDB, điều đó vẫn đau đớn nhất. CoackroachDB muốn thay đổi điều đó, mang lại sự dễ dàng, phân cụm và tính sẵn sàng cao cho thế giới của SQL.

Khi nào nên sử dụng CockroachDB

Gián Kiến trúc sư hệ thống giấc mơ trở thành sự thật. Nếu bạn chửi bới SQL và đang mô phỏng các khả năng mở rộng của MongoDB, thì bạn sẽ yêu thích CockroachDB. Bây giờ bạn có thể nhanh chóng thiết lập một cụm, ném các truy vấn vào nó và ngủ yên vào ban đêm. ��

Khi nào không sử dụng CockroachDB

Thà ma quỷ bạn biết còn hơn quỷ bạn don. Điều đó có nghĩa là, nếu RDBMS hiện tại của bạn đang hoạt động tốt cho bạn và bạn nghĩ rằng bạn có thể quản lý các cơn đau quy mô mà nó mang lại, hãy gắn bó với nó. Đối với tất cả các thiên tài có liên quan, CockroachDB là một sản phẩm mới và bạn không muốn đấu tranh với nó sau này. Một lý do chính khác là khả năng tương thích SQL – nếu bạn đang thực hiện các công cụ SQL kỳ lạ và dựa vào nó cho những điều quan trọng, thì CockroachDB sẽ trình bày quá nhiều trường hợp cạnh theo ý thích của bạn.

Từ giờ trở đi, chúng tôi sẽ xem xét các giải pháp cơ sở dữ liệu không phải SQL (hoặc NoQuery, vì nó gọi là) cho các nhu cầu chuyên môn cao.

Neo4j

Một trong những phát triển quan trọng nhất trong thập kỷ gần đây là dữ liệu được kết nối. Thế giới xung quanh chúng ta không được phân chia thành các bảng và hàng và hộp – đó là một mớ hỗn độn khổng lồ với mọi thứ được kết nối với hầu hết mọi thứ khác.

Mạng xã hội là một ví dụ điển hình và việc xây dựng một mô hình dữ liệu tương tự bằng cách sử dụng SQL hoặc thậm chí cơ sở dữ liệu dựa trên tài liệu là một cơn ác mộng.

Điều đó vì cấu trúc dữ liệu lý tưởng cho các giải pháp này là biểu đồ, là một con thú hoàn toàn khác. Và để làm điều đó, bạn cần một cơ sở dữ liệu đồ thị như Neo4j.

Ví dụ trên được lấy trực tiếp từ trang web Neo4j và cho thấy sinh viên đại học được kết nối với các khoa và khóa học của họ như thế nào. Một mô hình dữ liệu như vậy là không thể đối với SQL, vì nó sẽ rất khó để tránh các vòng lặp vô hạn và tràn bộ nhớ.

Các tính năng độc đáo

Bản thân cơ sở dữ liệu là duy nhất và Neo4j là lựa chọn duy nhất để làm việc với biểu đồ. Kết quả là, bất kỳ tính năng nào nó có là duy nhất. ��

  • Hỗ trợ cho các ứng dụng giao dịch và phân tích biểu đồ.
  • Khả năng chuyển đổi dữ liệu để tiêu hóa dữ liệu dạng bảng quy mô lớn thành biểu đồ.
  • Ngôn ngữ truy vấn chuyên dụng (Cypher) để truy vấn cơ sở dữ liệu đồ thị
  • Các tính năng trực quan và khám phá

Nó có một điểm để thảo luận khi nào nên sử dụng Neo4j và khi nào thì không. Nếu bạn cần mối quan hệ dựa trên biểu đồ giữa dữ liệu của mình, bạn cần Neo4j. ��

MongoDB

MongoDB là cơ sở dữ liệu phi quan hệ đầu tiên tạo ra làn sóng lớn trong ngành công nghệ và tiếp tục thống trị một phần quan tâm công bằng.

Không giống như các cơ sở dữ liệu quan hệ, MongoDB là một cơ sở dữ liệu tài liệu, có nghĩa là nó lưu trữ dữ liệu theo từng khối, với các dữ liệu liên quan được gộp lại trong cùng một khối. Điều này được hiểu rõ nhất bằng cách tưởng tượng một tập hợp các cấu trúc JSON như thế này:

Ở đây, không giống như cấu trúc dựa trên bảng, chi tiết liên hệ và mức truy cập của người dùng nằm trong cùng một đối tượng. Tìm nạp đối tượng người dùng tự động tìm nạp dữ liệu được liên kết và ở đó, không có khái niệm nào về việc tham gia. Đây là một đoạn giới thiệu chi tiết hơn về MongoDB.

Các tính năng độc đáo

MongoDB có một số vấn đề nghiêm trọng (tôi gần như muốn viết ra kick kick ass ass để truyền tải tác động, nhưng nó sẽ không phù hợp trên một trang web công cộng, có lẽ) đã khiến một số kiến ​​trúc sư dày dạn từ bỏ vùng đất quan hệ mãi mãi:

  • Một lược đồ linh hoạt cho các trường hợp sử dụng chuyên biệt / không thể đoán trước.
  • Vô lý đơn giản shending và clustering. Bạn chỉ cần thiết lập cấu hình cho một cụm và quên nó đi.
  • Thêm hoặc xóa một nút khỏi một cụm là đơn giản.
  • Khóa giao dịch phân tán. Tính năng này đã bị thiếu trong các phiên bản trước nhưng cuối cùng đã được giới thiệu.
  • Nó được tối ưu hóa để ghi rất nhanh, làm cho nó rất phù hợp với dữ liệu phân tích dưới dạng hệ thống lưu trữ.

Nếu tôi có vẻ như là người phát ngôn của MongoDB, tôi xin lỗi, nhưng nó khó có thể vượt qua những lợi thế của MongoDB. Chắc chắn, mô hình dữ liệu NoQuery ban đầu rất kỳ lạ và một số không bao giờ hiểu được nó, nhưng đối với nhiều kiến ​​trúc sư, nó hầu như luôn chiến thắng một lược đồ dựa trên bảng.

Khi nào nên sử dụng MongoDB

MongoDB là một cầu nối chéo tuyệt vời từ thế giới nghiêm ngặt có cấu trúc của SQL đến một thế giới vô định hình, gần như khó hiểu của NoQuery. Nó vượt trội trong việc phát triển các nguyên mẫu, vì ở đó, đơn giản là không có lược đồ nào phải lo lắng và khi bạn thực sự cần mở rộng quy mô. Có, bạn có thể sử dụng dịch vụ SQL trên đám mây để loại bỏ các vấn đề mở rộng DB, nhưng cậu bé rất tốn kém!

Cuối cùng, có những trường hợp sử dụng trong đó các giải pháp dựa trên SQL vừa giành được. Chẳng hạn, nếu bạn đang tạo một sản phẩm như Canva, nơi người dùng có thể tạo các thiết kế phức tạp tùy ý và có thể chỉnh sửa chúng sau này, chúc may mắn với cơ sở dữ liệu quan hệ!

Khi nào không sử dụng MongoDB

Việc thiếu hoàn toàn lược đồ mà MongoDB cung cấp có thể hoạt động như một hố tar cho những người không biết về những gì họ làm. Dữ liệu không khớp, dữ liệu chết, các trường trống không nên trống – tất cả điều này và nhiều hơn nữa là có thể. MongoDB về cơ bản là một kho lưu trữ dữ liệu của Google, và nếu bạn chọn nó, mã ứng dụng phải chịu trách nhiệm rất nhiều trong việc duy trì tính toàn vẹn dữ liệu.

Nếu bạn là một nhà phát triển, thì bạn sẽ tìm thấy cái này hữu ích.

Suy nghĩ lại

Như tên của nó đi, Suy nghĩ lại Hãy suy nghĩ lại về ý tưởng và khả năng của cơ sở dữ liệu khi nói đến các ứng dụng thời gian thực.

Khi một cơ sở dữ liệu được cập nhật, ứng dụng không có cách nào để ứng dụng biết. Cách tiếp cận được chấp nhận là để ứng dụng kích hoạt thông báo ngay khi có một bản cập nhật, được đẩy lên phía trước thông qua một cây cầu phức tạp (PHP -> Redis -> Nút -> Socket.io là một ví dụ).

Nhưng điều gì sẽ xảy ra nếu các bản cập nhật có thể được đẩy trực tiếp từ cơ sở dữ liệu lên giao diện người dùng?!

Vâng, đó là lời hứa của RethinkDB. Vì vậy, nếu bạn chuẩn bị tạo một ứng dụng thời gian thực (trò chơi, thị trường, phân tích, v.v.), hãy suy nghĩ lại DB đáng để xem xét.

Redis

Khi nói đến cơ sở dữ liệu, nó rất dễ bỏ qua sự tồn tại của Redis. Điều đó vì Redis là một cơ sở dữ liệu trong bộ nhớ và chủ yếu được sử dụng trong các chức năng hỗ trợ như bộ nhớ đệm.

Học cơ sở dữ liệu này là một công việc mười phút (theo nghĩa đen!) và đó là một kho lưu trữ khóa-giá trị đơn giản lưu trữ các chuỗi có thời gian hết hạn (tất nhiên có thể được đặt thành vô hạn). Những gì Redis mất trong các tính năng nó bù đắp cho tiện ích và hiệu suất. Vì nó sống hoàn toàn trong RAM, nên đọc và ghi cực kỳ nhanh (vài trăm nghìn thao tác mỗi giây không phải là chưa từng thấy).

Redis cũng có một tinh vi hệ thống quán rượu, Điều này làm cho cơ sở dữ liệu này của Google hấp dẫn gấp đôi.

Nói cách khác, nếu bạn có một dự án có thể hưởng lợi từ bộ nhớ đệm hoặc có một số thành phần phân tán, Redis là lựa chọn đầu tiên.

SQLite

Vâng, tôi đã hứa rằng chúng tôi đã hoàn thành cơ sở dữ liệu quan hệ, nhưng SQLite quá dễ thương để bỏ qua.

SQLite là một thư viện C nhẹ cung cấp một công cụ lưu trữ cơ sở dữ liệu quan hệ. Mọi thứ trong cơ sở dữ liệu này nằm trong một tệp duy nhất (có phần mở rộng .sqlite) mà bạn có thể đặt ở bất kỳ đâu trong hệ thống tệp của mình. Và đó là tất cả những gì bạn cần để sử dụng nó! Có, không có phần mềm máy chủ nào để cài đặt và không có dịch vụ nào để kết nối với.

Các tính năng hữu ích

Mặc dù SQLite là một giải pháp thay thế nhẹ cho cơ sở dữ liệu như MySQL, nhưng nó có một cú đấm khá mạnh. Một số tính năng gây sốc của nó là:

  • Hỗ trợ đầy đủ cho các giao dịch, với CAM KẾT, ROLLBACK và BEGIN.
  • Hỗ trợ cho 32.000 cột mỗi bảng
  • Hỗ trợ JSON
  • Hỗ trợ THAM GIA 64 chiều
  • Truy vấn con, tìm kiếm toàn văn, v.v..
  • Kích thước cơ sở dữ liệu tối đa 140 terabyte!
  • Kích thước hàng tối đa là 1 gigabyte!
  • Nhanh hơn 35% so với tệp I / O

Khi nào nên sử dụng SQLite

SQLite là một cơ sở dữ liệu cực kỳ chuyên biệt, tập trung vào một cách tiếp cận vô nghĩa, hoàn hảo. Nếu ứng dụng của bạn tương đối đơn giản và bạn không muốn gặp rắc rối với cơ sở dữ liệu đầy đủ, SQLite là một ứng cử viên nặng ký. Điều này có ý nghĩa đặc biệt đối với các ứng dụng CMS và ứng dụng demo cỡ nhỏ đến trung bình.

Khi nào không sử dụng SQLite

Mặc dù ấn tượng, SQLite không bao gồm tất cả các tính năng của SQL tiêu chuẩn hoặc công cụ cơ sở dữ liệu yêu thích của bạn. Thiếu cụm, thủ tục lưu trữ và phần mở rộng tập lệnh bị thiếu. Ngoài ra, ở đó, không có máy khách nào kết nối, truy vấn và khám phá cơ sở dữ liệu. Cuối cùng, khi kích thước ứng dụng tăng lên, hiệu suất sẽ giảm.

Cassandra

Trong khi nhiều người tuyên bố rằng sự kết thúc đã gần kề với Java, thì thỉnh thoảng cộng đồng lại thả một quả bom và làm câm lặng các nhà phê bình. Cassandra là một ví dụ như vậy.

Cassandra thuộc về những gì mà người Viking gọi là gia đình cơ sở dữ liệu. Sự trừu tượng hóa lưu trữ trong Cassandra là một cột chứ không phải là một hàng. Ý tưởng ở đây là lưu trữ tất cả dữ liệu trong một cột vật lý với nhau trên đĩa, giảm thiểu thời gian tìm kiếm.

Các tính năng độc đáo

Cassandra được thiết kế với một trường hợp sử dụng cụ thể trong tâm trí – xử lý các tải nặng và không dung sai cho thời gian chết. Chúng trở thành điểm bán hàng độc đáo của nó.

  • Hiệu suất viết cực nhanh. Cassandra được cho là cơ sở dữ liệu nhanh nhất hiện có khi xử lý tải nặng.
  • Khả năng mở rộng tuyến tính. Đó là, bạn có thể tiếp tục thêm bao nhiêu nút vào một cụm mà bạn muốn và sẽ có sự gia tăng bằng không về độ phức tạp hoặc độ giòn của cụm.
  • Dung sai phân vùng chưa từng có. Đó là, ngay cả khi nhiều nút trong cụm Cassandra bị hỏng, cơ sở dữ liệu được thiết kế để tiếp tục thực hiện mà không mất tính toàn vẹn.
  • Gõ tĩnh

Khi nào nên sử dụng Cassandra

Ghi nhật ký và phân tích là hai trong số các trường hợp sử dụng tốt nhất cho Cassandra. Nhưng điều đó không phải là tất cả – điểm hấp dẫn là khi bạn cần xử lý các kích thước dữ liệu thực sự lớn (Apple có triển khai Cassandra xử lý hơn 400 petabyte dữ liệu trong khi tại Netflix, nó xử lý 1 nghìn tỷ yêu cầu mỗi ngày) với thời gian ngừng hoạt động. Tính sẵn sàng cao là một trong những đặc điểm nổi bật của Cassandra.

Khi nào không sử dụng Cassandra

Sơ đồ lưu trữ cột của Cassandra cũng có nhược điểm của nó. Mô hình dữ liệu khá bằng phẳng và nếu bạn cần tổng hợp, thì Cassandra sẽ bị hụt. Hơn nữa, nó đạt được tính sẵn sàng cao bằng cách hy sinh tính nhất quán (hãy nhớ định lý CAP cho các hệ thống phân tán), điều này làm cho nó ít phù hợp hơn với các hệ thống cần độ chính xác đọc cao.

Thời đại

Các phát triển mới đòi hỏi các loại cơ sở dữ liệu mới và Internet of Things (IoT) là một trong những hiện tượng như vậy. Một trong những cơ sở dữ liệu nguồn mở tốt nhất cho điều đó là Thời đại.

Khung thời gian là một kiểu mà cơ sở dữ liệu của dòng thời gian gọi là cơ sở dữ liệu. Nó khác với cơ sở dữ liệu truyền thống vào thời điểm đó là trục chính của mối quan tâm và việc phân tích và trực quan hóa các bộ dữ liệu lớn là ưu tiên hàng đầu. Cơ sở dữ liệu chuỗi thời gian hiếm khi thấy một sự thay đổi trong dữ liệu hiện có; một ví dụ là số đọc nhiệt độ được gửi bởi cảm biến trong nhà kính – dữ liệu mới tiếp tục được tích lũy mỗi giây, điều đáng quan tâm cho phân tích và báo cáo.

Tại sao không chỉ sử dụng cơ sở dữ liệu truyền thống với trường dấu thời gian? Vâng, có hai lý do chính cho điều đó:

  • Cơ sở dữ liệu mục đích chung không được tối ưu hóa để làm việc với dữ liệu dựa trên thời gian. Với cùng một lượng dữ liệu, cơ sở dữ liệu đa năng sẽ chậm hơn nhiều.
  • Cơ sở dữ liệu cần xử lý một lượng lớn dữ liệu khi dữ liệu mới tiếp tục chảy vào và xóa dữ liệu hoặc thay đổi lược đồ; sau này, không phải là một lựa chọn.

Các tính năng độc đáo

Timescale DB có một số tính năng thú vị khác biệt với các cơ sở dữ liệu khác trong cùng thể loại:

  • Nó được xây dựng trên PostgreSQL, được cho là cơ sở dữ liệu quan hệ nguồn mở tốt nhất hiện có. Nếu dự án của bạn đang chạy PostgreSQL, Timescale sẽ trượt ngay vào.
  • Truy vấn được thực hiện thông qua cú pháp SQL quen thuộc, giảm thời gian học.
  • Tốc độ ghi cực kỳ nhanh – hàng triệu lần chèn mỗi giây không cần đến.
  • Hàng tỷ hàng hoặc petabyte dữ liệu – nó không phải là vấn đề lớn đối với Timescale.
  • Tính linh hoạt thực sự với lược đồ – chọn từ quan hệ hoặc schemaless theo nhu cầu của bạn.

Nó không có ý nghĩa gì khi nói về việc nên sử dụng hay không sử dụng Timescale DB. Nếu IoT là miền của bạn hoặc bạn có thể theo các đặc điểm cơ sở dữ liệu tương tự, Timescale đáng để xem.

CouchDB

CouchDB là một giải pháp cơ sở dữ liệu nhỏ gọn nằm lặng lẽ trong một góc và có một phần nhỏ nhưng chuyên dụng. Nó được tạo ra để đối phó với các vấn đề mất mạng và giải quyết dữ liệu cuối cùng, đây là một vấn đề lộn xộn đến nỗi các nhà phát triển thay vì chuyển đổi công việc hơn là giải quyết nó.

Về cơ bản, bạn có thể nghĩ về cụm CouchDB như một tập hợp phân tán các nút lớn và nhỏ, một số trong số đó được dự kiến ​​là ngoại tuyến. Ngay khi một nút xuất hiện trực tuyến, nó sẽ gửi dữ liệu trở lại cụm, được xử lý chậm và cẩn thận, cuối cùng sẽ có sẵn cho toàn bộ cụm.

Các tính năng độc đáo

CouchDB là một cái gì đó của một giống duy nhất khi nói đến cơ sở dữ liệu.

  • Khả năng đồng bộ hóa dữ liệu ngoại tuyến
  • Các phiên bản chuyên dụng cho trình duyệt di động và web (PouchDB, CouchDB Lite, v.v.)
  • Độ tin cậy chống va chạm, thử nghiệm chiến đấu
  • Phân cụm dễ dàng với lưu trữ dữ liệu dư thừa

Khi nào nên sử dụng CouchDB

CouchDB được xây dựng cho khả năng chịu ngoại tuyến và vẫn chưa từng có về mặt này. Trường hợp sử dụng thông thường là các ứng dụng dành cho thiết bị di động trong đó một phần dữ liệu của bạn nằm trên phiên bản CouchDB trên điện thoại người dùng (vì đó là nơi nó được tạo). Điều thú vị là bạn không thể dựa vào thiết bị người dùng để được kết nối mọi lúc, điều đó có nghĩa là cơ sở dữ liệu phải có cơ hội và sẵn sàng giải quyết các cập nhật xung đột sau này. Điều này đạt được bằng cách sử dụng ấn tượng Giao thức nhân rộng Couch.

Khi nào không sử dụng CouchDB

Cố gắng sử dụng CouchDB bên ngoài trường hợp sử dụng dự định của nó sẽ dẫn đến thảm họa. Nó sử dụng cách lưu trữ nhiều hơn bất kỳ thứ gì khác ngoài đó, đơn giản vì nó cần duy trì các bản sao dữ liệu dư thừa và kết quả giải quyết xung đột. Kết quả là tốc độ ghi cũng chậm một cách đau đớn. Cuối cùng, CouchDB không phù hợp làm công cụ lược đồ cho mục đích chung, vì nó không chơi tốt với các thay đổi lược đồ.

Phần kết luận

Tôi đã phải loại bỏ nhiều ứng cử viên thú vị như Rịa, vì vậy danh sách này sẽ được coi là một hướng dẫn chứ không phải là một điều răn. Tôi hy vọng tôi có thể đạt được mục tiêu của mình với bài viết này – hiện tại không chỉ là một bộ sưu tập các khuyến nghị cơ sở dữ liệu, mà còn thảo luận ngắn gọn về nơi và cách chúng cần được sử dụng (và tránh!).

Nếu bạn tò mò muốn tìm hiểu cơ sở dữ liệu thì hãy xem Kẻ thù cho một số khóa học trực tuyến tuyệt vời.

THẺ

  • Cơ sở dữ liệu

  • Mã nguồn mở

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map