Hướng dẫn về NoSQL dành cho nhà phát triển

Nếu bạn đang theo dõi các xu hướng phát triển chương trình phụ trợ và Dữ liệu lớn, có thể bạn đã nhận thấy tin đồn xung quanh cơ sở dữ liệu NoSQL trong những năm gần đây. Một số người được truyền cảm hứng từ cách tiếp cận cơ sở dữ liệu này, trong khi những người khác cho rằng có một số thủ thuật ẩn giấu trong đó: các mô hình dữ liệu trong đó không giống như trong các cơ sở dữ liệu quan hệ thông thường, các giao diện lập trình ứng dụng khác thường và các ứng dụng thường không thể hiểu được. Trong bài viết này, tôi sẽ cho bạn biết lý do tại sao chúng được tạo ra ngay từ đầu, những cơ sở dữ liệu NoSQL này, chúng giải quyết những vấn đề gì và tại sao đột nhiên lại cần đến nhiều cơ sở dữ liệu khác nhau như vậy. Nếu mới làm quen với NoSQL, bạn có thể đặc biệt quan tâm đến phần cuối của bài viết, trong đó liệt kê các loại cơ sở dữ liệu NoSQL mà tôi nghĩ đáng để khám phá trước tiên để hiểu rõ hơn về lĩnh vực này.

Tại sao chúng ta đột nhiên cần một cơ sở dữ liệu mới?

Bạn có thể bối rối khi hỏi: cơ sở dữ liệu quan hệ có vấn đề gì? Vấn đề là họ đã làm việc rất tốt trong nhiều năm, nhưng bây giờ có một vấn đề mà họ không thể giải quyết được nữa. Theo một số dự đoán, năm 2018 nhân loại sẽ tạo ra 50.000 gigabyte dữ liệu mỗi giây. Đây là một lượng dữ liệu khổng lồ! Việc lưu trữ và xử lý nó đặt ra một thách thức kỹ thuật nghiêm trọng. Điều tệ hơn nữa là khối lượng này không ngừng tăng lên. Hóa ra, cơ sở dữ liệu quan hệ không phù hợp để làm việc với khối lượng dữ liệu thực sự lớn. Chúng được thiết kế để chạy trên một máy duy nhất và nếu bạn muốn xử lý nhiều yêu cầu hơn thì lựa chọn duy nhất là mua một máy tính có nhiều RAM hơn và bộ xử lý mạnh hơn. Thật không may, số lượng truy vấn mà một máy có thể xử lý bị hạn chế và đối với công việc phân tán trên nhiều máy, chúng ta cần một công nghệ cơ sở dữ liệu khác. Tất nhiên, một số độc giả sẽ cười khúc khích vào thời điểm này và nói rằng có hai phương pháp được sử dụng rộng rãi để sử dụng nhiều máy trong trường hợp cơ sở dữ liệu quan hệ: sao chép và phân chia. Điều đó đúng, nhưng những phương pháp này không đủ để giải quyết nhiệm vụ của chúng tôi. Sao chép đọc là một kỹ thuật trong đó mỗi bản cập nhật cơ sở dữ liệu được truyền đến các máy khác chỉ có thể xử lý các yêu cầu đọc. Trong trường hợp này, tất cả các thay đổi được thực hiện bởi một máy chủ, được gọi là nút chính, trong khi các máy chủ khác, được gọi là bản sao đọc, chỉ duy trì các bản sao của dữ liệu. Người dùng có thể đọc từ bất kỳ máy nào nhưng chỉ thay đổi dữ liệu thông qua nút chính. Đây là một phương pháp tiện lợi và rất phổ biến, nhưng nó chỉ cho phép bạn xử lý nhiều yêu cầu đọc hơn và không giải quyết được vấn đề xử lý khối lượng dữ liệu cần thiết theo bất kỳ cách nào. Sharding là một cách tiếp cận phổ biến khác sử dụng nhiều phiên bản của cơ sở dữ liệu quan hệ. Mỗi người trong số họ xử lý các hoạt động ghi và đọc cho một phần dữ liệu. Nếu cơ sở dữ liệu lưu trữ thông tin về khách hàng, chẳng hạn như sử dụng sharding, thì một máy có thể xử lý tất cả yêu cầu đối với khách hàng có tên bắt đầu bằng A, máy khác có thể lưu trữ tất cả dữ liệu đối với khách hàng có tên bắt đầu bằng B, v.v. Mặc dù phân đoạn cho phép bạn ghi lại nhiều dữ liệu hơn nhưng việc quản lý cơ sở dữ liệu như vậy thực sự là một cơn ác mộng: bạn phải căn chỉnh dữ liệu trên các máy và chia tỷ lệ cụm theo cả hai hướng nếu cần. Mặc dù về mặt lý thuyết có vẻ đơn giản nhưng để thực hiện đúng lại khá khó khăn.

Cơ sở dữ liệu quan hệ có thể được cải thiện?

Tôi nghĩ bạn đã tin rằng cơ sở dữ liệu quan hệ không phù hợp nhất với khối lượng dữ liệu được tạo ra trong thế giới hiện đại. Mặc dù vậy, bạn vẫn có thể thắc mắc tại sao chưa có ai tạo ra cơ sở dữ liệu quan hệ "tốt hơn" có thể chạy hiệu quả trên nhiều máy. Có vẻ như công nghệ này vẫn chưa được phát triển và cơ sở dữ liệu quan hệ phân tán sẽ sớm xuất hiện. Than ôi, điều này sẽ không xảy ra. Điều này là không thể về mặt toán học và không thể làm được gì về nó. Để hiểu lý do tại sao lại như vậy, bạn cần xem xét cái gọi là định lý CAP (hay còn gọi là định lý Brewer). Nó đã được chứng minh vào năm 1999 và nó tuyên bố rằng cơ sở dữ liệu phân tán chạy trên nhiều máy có thể có ba thuộc tính sau: Tính nhất quán - mọi thao tác đọc đều trả về kết quả của thao tác ghi tương ứng cuối cùng. Nếu hệ thống nhất quán thì sau khi ghi dữ liệu mới sẽ không thể đọc được dữ liệu cũ đã bị ghi đè. Tính khả dụng ( Tính khả dụng) - một hệ thống phân tán có thể phục vụ yêu cầu đến bất kỳ lúc nào và trả về phản hồi không có lỗi. Dung sai phân vùng - cơ sở dữ liệu tiếp tục đáp ứng các yêu cầu đọc và ghi ngay cả khi một số máy chủ của nó tạm thời không thể liên lạc với nhau. Lỗi tạm thời này được gọi là lỗi kết nối mạng và có thể do nhiều yếu tố gây ra, từ sự cố mạng vật lý do máy chủ chậm đến hư hỏng vật lý đối với thiết bị mạng. Tất cả các thuộc tính này chắc chắn rất tiện dụng và chúng tôi thực sự muốn có một cơ sở dữ liệu để kết hợp tất cả chúng. Không có nhà phát triển lành mạnh nào muốn từ bỏ khả năng truy cập mà không nhận được bất cứ điều gì. Thật không may, định lý CAP cũng phát biểu rằng không thể có cả ba thuộc tính cùng một lúc. Nhận ra điều này có thể không dễ dàng, nhưng nó có thể. Đầu tiên, nếu chúng ta cần một cơ sở dữ liệu phân tán thì nó phải “có khả năng chịu ngắt kết nối”. Điều này thậm chí không được thảo luận. Việc ngắt kết nối luôn xảy ra và cơ sở dữ liệu của chúng tôi vẫn phải hoạt động bất chấp điều này. Bây giờ hãy hiểu tại sao chúng ta không thể đạt được cả tính nhất quán và tính khả dụng. Hãy tưởng tượng chúng ta có một cơ sở dữ liệu đơn giản chạy trên hai máy: A và B. Bất kỳ người dùng nào cũng có thể ghi vào một trong hai máy, sau đó dữ liệu sẽ được sao chép sang máy kia. Bây giờ hãy tưởng tượng rằng các máy này tạm thời không thể liên lạc với nhau và máy B không thể gửi hoặc nhận dữ liệu từ máy A. Nếu trong khoảng thời gian này, máy B nhận được yêu cầu đọc từ máy khách, nó có hai tùy chọn:

1. Lấy lại dữ liệu cục bộ của bạn, ngay cả khi nó không phải là dữ liệu mới nhất. Trong trường hợp này, ưu tiên được dành cho tính khả dụng (để trả về ít nhất một số dữ liệu, ngay cả những dữ liệu đã lỗi thời).
2. Lỗi trả về. Trong trường hợp này, tính nhất quán được ưu tiên: máy khách sẽ không nhận được dữ liệu lỗi thời nhưng sẽ không nhận được bất kỳ dữ liệu nào cả.

Cơ sở dữ liệu quan hệ cố gắng thể hiện đồng thời các thuộc tính "tính nhất quán" và "tính sẵn sàng" và do đó không thể hoạt động trong môi trường phân tán. Việc cố gắng triển khai tất cả các khả năng của cơ sở dữ liệu quan hệ trong hệ thống phân tán sẽ không thực tế hoặc đơn giản là không khả thi . Mặt khác, cơ sở dữ liệu NoSQL đánh giá cao khả năng mở rộng và hiệu suất. Chúng thường thiếu các khả năng “cơ bản” như kết nối và giao dịch, và mô hình dữ liệu hóa ra hoàn toàn khác, thậm chí có thể còn hạn chế theo một cách nào đó. Tất cả điều này giúp bạn có thể lưu trữ khối lượng dữ liệu lớn hơn và xử lý nhiều truy vấn hơn bao giờ hết.

Cơ sở dữ liệu NoSQL cân bằng tính nhất quán và tính khả dụng như thế nào?

Đối với bạn, có vẻ như nếu bạn chọn cơ sở dữ liệu NoSQL, bạn sẽ luôn nhận được một số dữ liệu lỗi thời hoặc lỗi trong trường hợp có bất kỳ lỗi nào. Trong thực tế, tính sẵn có và tính nhất quán không phải là những lựa chọn duy nhất hiện có. Có rất nhiều lựa chọn có sẵn cho bạn lựa chọn. Cơ sở dữ liệu quan hệ không có các tùy chọn này, nhưng NoSQL cho phép bạn kiểm soát việc thực hiện truy vấn theo cách tương tự. Bằng cách này hay cách khác, chúng cho phép bạn đặt hai tham số khi thực hiện thao tác ghi hoặc đọc trong cơ sở dữ liệu NoSQL: W - có bao nhiêu máy trong cụm phải xác nhận lưu dữ liệu khi thực hiện thao tác ghi . Số lượng máy bạn ghi dữ liệu càng lớn thì việc đọc dữ liệu gần đây nhất trong thao tác đọc tiếp theo sẽ càng dễ dàng hơn nhưng cũng sẽ mất nhiều thời gian hơn. R – bạn muốn đọc dữ liệu từ bao nhiêu máy . Trong hệ thống phân tán, việc phân phối dữ liệu đến tất cả các máy trong một cụm có thể mất một chút thời gian, do đó một số máy chủ sẽ có dữ liệu mới nhất trong khi những máy chủ khác sẽ bị chậm. Số lượng máy đọc dữ liệu càng nhiều thì cơ hội đọc được dữ liệu hiện tại càng cao. Hãy xem xét một ví dụ thực tế. Nếu bạn có năm máy tính trong cụm của mình và bạn quyết định chỉ ghi dữ liệu vào một máy tính rồi đọc dữ liệu từ một máy tính được chọn ngẫu nhiên thì có 80% khả năng bạn sẽ đọc dữ liệu cũ. Mặt khác, điều này sẽ sử dụng tối thiểu tài nguyên. Vì vậy, nếu dữ liệu cũ phù hợp với bạn thì đó không phải là một lựa chọn tồi. Trong trường hợp này, tham số W và R bằng 1. Mặt khác, nếu bạn ghi dữ liệu vào cả năm máy trong cơ sở dữ liệu NoSQL, bạn có thể đọc dữ liệu từ bất kỳ máy nào và được đảm bảo luôn nhận được dữ liệu cập nhật. Thực hiện cùng một thao tác trên nhiều máy hơn sẽ mất nhiều thời gian hơn, nhưng nếu dữ liệu cập nhật quan trọng đối với bạn thì bạn có thể chọn tùy chọn này. Trong trường hợp này, W = R = 5. Số lần đọc và ghi tối thiểu cần thiết để đảm bảo tính nhất quán của cơ sở dữ liệu là bao nhiêu? Đây là một công thức đơn giản: R + W ≥ N + 1 , trong đó N là số lượng máy trong cụm. Điều này có nghĩa là với năm máy chủ, bạn có thể chọn R = 2 và W = 4 hoặc R = 3 và W = 3 hoặc R = 4 và W = 2. Trong trường hợp này, dữ liệu thuộc về máy nào không quan trọng được ghi, việc đọc sẽ luôn được thực hiện từ ít nhất một máy có dữ liệu cập nhật. Các cơ sở dữ liệu khác, chẳng hạn như DynamoDB, có những hạn chế khác nhau và chỉ cho phép ghi nhất quán. Mỗi phần dữ liệu được lưu trữ trên ba máy chủ và khi bất kỳ dữ liệu nào được ghi, nó sẽ được ghi vào hai trong số ba máy. Nhưng khi đọc dữ liệu, bạn có thể chọn một trong hai tùy chọn:

1. Đọc nhất quán nghiêm ngặt, trong đó dữ liệu được đọc từ hai trong số ba máy và luôn trả về dữ liệu được ghi gần đây nhất.
2. Một lần đọc nhất quán cuối cùng, trong đó một máy được chọn ngẫu nhiên để đọc dữ liệu. Tuy nhiên, điều này có thể tạm thời trả về dữ liệu lỗi thời.

Tại sao có nhiều cơ sở dữ liệu NoSQL đến vậy?

Nếu theo dõi những tin tức mới nhất về phát triển phần mềm, bạn có thể đã nghe nói về nhiều cơ sở dữ liệu NoSQL khác nhau, chẳng hạn như MongoDB, DynamoDB, Cassandra, Redis và nhiều cơ sở dữ liệu khác. Bạn có thể thắc mắc: tại sao chúng ta cần nhiều cơ sở dữ liệu NoSQL khác nhau đến vậy? Lý do rất đơn giản: các cơ sở dữ liệu NoSQL khác nhau được thiết kế để giải quyết các vấn đề khác nhau. Đây là lý do tại sao số lượng cơ sở dữ liệu cạnh tranh rất lớn. Cơ sở dữ liệu NoSQL được chia thành bốn loại chính:

Cơ sở dữ liệu hướng tài liệu

Các cơ sở dữ liệu này cung cấp khả năng lưu trữ các tài liệu lồng nhau phức tạp, trong khi hầu hết các cơ sở dữ liệu quan hệ chỉ hỗ trợ các hàng một chiều. Tính năng này có thể hữu ích trong nhiều trường hợp, chẳng hạn như khi cần lưu trữ thông tin về người dùng có nhiều địa chỉ trong hệ thống. Khi sử dụng cơ sở dữ liệu hướng tài liệu, trong trường hợp này bạn có thể chỉ cần lưu trữ một đối tượng phức tạp chứa một mảng địa chỉ, trong khi đó trong cơ sở dữ liệu quan hệ, bạn sẽ phải tạo hai bảng: một bảng cho thông tin người dùng và một bảng cho địa chỉ. Cơ sở dữ liệu hướng tài liệu thu hẹp khoảng cách giữa mô hình đối tượng và mô hình dữ liệu. Một số cơ sở dữ liệu quan hệ, chẳng hạn như PostgreSQL, hiện cũng hỗ trợ lưu trữ theo định hướng tài liệu, nhưng hầu hết các cơ sở dữ liệu quan hệ vẫn thiếu khả năng này.

Cơ sở dữ liệu khóa/giá trị

Cơ sở dữ liệu khóa/giá trị thường triển khai mô hình NoSQL đơn giản nhất. Về cơ bản, họ cung cấp cho bạn bảng băm phân tán , cho phép bạn ghi dữ liệu vào một khóa nhất định và đọc lại bằng cách sử dụng khóa đó. Cơ sở dữ liệu khóa/giá trị có khả năng mở rộng cao và có độ trễ thấp hơn đáng kể so với các cơ sở dữ liệu khác.

Cơ sở dữ liệu đồ thị

Nhiều lĩnh vực chủ đề, chẳng hạn như mạng xã hội hoặc thông tin về phim và diễn viên, có thể được biểu diễn dưới dạng biểu đồ. Mặc dù biểu đồ có thể được biểu diễn bằng cơ sở dữ liệu quan hệ nhưng việc này rất khó khăn và bất tiện. Nếu bạn cần dữ liệu đồ thị, tốt hơn nên sử dụng cơ sở dữ liệu đồ thị chuyên dụng, có thể lưu trữ thông tin về đồ thị trong một cụm phân tán và giúp triển khai các thuật toán trên đồ thị một cách hiệu quả.

Cơ sở dữ liệu cột

Sự khác biệt chính giữa cơ sở dữ liệu cột và các loại cơ sở dữ liệu khác là cách dữ liệu được lưu trữ trên đĩa. Cơ sở dữ liệu quan hệ tạo một tệp cho mỗi bảng và lưu trữ các giá trị cho tất cả các hàng một cách tuần tự. Cơ sở dữ liệu cột tạo một tệp cho mỗi cột trong bảng của bạn. Cấu trúc này cho phép bạn tổng hợp dữ liệu và chạy một số truy vấn nhất định hiệu quả hơn, nhưng bạn phải đảm bảo rằng dữ liệu phù hợp với các giới hạn của cơ sở dữ liệu đó.

Bạn nên chọn cơ sở dữ liệu nào?

Việc chọn cơ sở dữ liệu thường là một vấn đề khó chịu và với rất nhiều tùy chọn có sẵn, việc này có vẻ như là một nhiệm vụ quá sức. Tin tốt là không cần phải chọn chỉ một. Thay vì tạo một ứng dụng nguyên khối duy nhất triển khai tất cả các khả năng và có quyền truy cập vào tất cả dữ liệu hệ thống, bạn có thể sử dụng một mẫu hiện đại khác gọi là microservice : chia ứng dụng thành một tập hợp các dịch vụ độc lập. Mỗi dịch vụ giải quyết vấn đề hẹp của riêng mình và chỉ sử dụng cơ sở dữ liệu riêng, phù hợp nhất để giải quyết vấn đề này.

Làm thế nào bạn có thể học được tất cả những điều này?

Với rất nhiều cơ sở dữ liệu , việc tìm hiểu tất cả chúng có vẻ như là một nhiệm vụ bất khả thi. Tin tốt: bạn không cần phải làm điều này. Chỉ có một số loại cơ sở dữ liệu NoSQL cơ bản và nếu bạn hiểu cách chúng hoạt động thì những loại khác sẽ dễ hiểu hơn nhiều. Ngoài ra, một số cơ sở dữ liệu NoSQL được sử dụng thường xuyên hơn những cơ sở dữ liệu khác, vì vậy tốt nhất bạn nên tập trung nỗ lực vào các giải pháp phổ biến nhất. Dưới đây là danh sách các cơ sở dữ liệu NoSQL được sử dụng phổ biến nhất mà tôi nghĩ bạn nên xem qua:

1. MongoDB . Có lẽ là cơ sở dữ liệu NoSQL phổ biến nhất trên thị trường. Nếu một công ty không sử dụng cơ sở dữ liệu quan hệ làm kho lưu trữ dữ liệu chính thì có thể công ty đó sử dụng MongoDB. Đây là nơi lưu trữ tài liệu linh hoạt với một bộ công cụ tốt. Thời kỳ đầu trong sự nghiệp của mình, MongoDB bị mang tiếng xấu là mất dữ liệu trong một số trường hợp , nhưng kể từ đó, tính ổn định và độ tin cậy của nó đã được cải thiện rất nhiều. Hãy xem khóa học MongoDB này nếu bạn muốn tìm hiểu thêm.


2. DynamoDB . Nếu sử dụng Amazon Web Services (AWS), tốt hơn bạn nên tìm hiểu thêm về DynamoDB. Đây là cơ sở dữ liệu cực kỳ đáng tin cậy, có thể mở rộng, độ trễ thấp với bộ tính năng phong phú và tích hợp với nhiều dịch vụ AWS khác. Điều tuyệt vời nhất là bạn không phải tự mình triển khai nó. Thiết lập cụm DynamoDB có thể mở rộng có thể xử lý hàng nghìn truy vấn chỉ bằng vài cú nhấp chuột. Nếu điều này làm bạn quan tâm, bạn có thể xem khóa học này .


3. Neo4j . Cơ sở dữ liệu đồ thị phổ biến nhất. Đây là giải pháp có khả năng mở rộng và ổn định phù hợp cho những ai muốn sử dụng mô hình dữ liệu đồ thị. Nếu bạn muốn tìm hiểu thêm, hãy bắt đầu với khóa học này .


4. Redis . Trong khi các cơ sở dữ liệu khác được mô tả ở đây được sử dụng để lưu trữ dữ liệu ứng dụng cốt lõi thì Redis được sử dụng chủ yếu để triển khai bộ nhớ đệm và lưu trữ dữ liệu phụ trợ. Trong nhiều trường hợp, một trong những cơ sở dữ liệu nêu trên được sử dụng song song với Redis. Để tìm hiểu thêm, hãy xem khóa học này.

Năm 2018 với NoSQL

Cơ sở dữ liệu NoSQL là một lĩnh vực rộng lớn và đang phát triển nhanh chóng. Chúng cho phép bạn lưu trữ và xử lý lượng dữ liệu không thể tưởng tượng được trước đây, nhưng nó phải trả phí. Những cơ sở dữ liệu này không có nhiều tính năng mà bạn quen thuộc trong cơ sở dữ liệu quan hệ và có thể khó thiết lập để sử dụng chúng. Nhưng khi đã hiểu rõ về chúng, bạn có thể tạo cơ sở dữ liệu phân tán, có thể mở rộng, có thể xử lý khối lượng yêu cầu đọc và ghi đáng kinh ngạc, điều này có thể cực kỳ quan trọng khi khối lượng dữ liệu ngày càng lớn hơn được tạo ra. Bản gốc: https://simpleprogrammer.com/guide-nosql-software-developers/