Khi nào bạn không nên sử dụng MongoDB?

từ chối trách nhiệm. Tôi không xây dựng công cụ cơ sở dữ liệu. Tôi xây dựng các ứng dụng web. Tôi chạy 4-6 dự án khác nhau mỗi năm, vì vậy tôi xây dựng rất nhiều ứng dụng web. Tôi thấy các ứng dụng có yêu cầu khác nhau và nhu cầu lưu trữ dữ liệu khác nhau. Tôi đã triển khai hầu hết các kho lưu trữ dữ liệu mà bạn đã nghe nói đến và một số ít mà bạn có thể chưa

Tôi đã chọn sai một vài lần. Đây là câu chuyện về một trong những thời điểm đó - tại sao ban đầu chúng tôi chọn nó, cách chúng tôi phát hiện ra nó sai và cách chúng tôi phục hồi. Tất cả xảy ra trên một dự án mã nguồn mở có tên là Diaspora

Dự án

Diaspora là mạng xã hội phân tán có lịch sử lâu đời. Waaaaay trở lại vào đầu năm 2010, bốn sinh viên đại học từ Đại học New York đã làm một video Kickstarter yêu cầu 10.000 đô la để dành cả mùa hè để xây dựng một giải pháp thay thế phân tán cho Facebook. Họ đã gửi nó cho bạn bè và gia đình, và hy vọng điều tốt nhất

Nhưng họ đánh một dây thần kinh. Vừa có một vụ bê bối về quyền riêng tư khác của Facebook, và khi mọi chuyện đã ổn thỏa trên Kickstarter của họ, họ đã huy động được hơn 200.000 đô la từ 6400 người khác nhau cho một dự án phần mềm chưa có một dòng mã nào được viết.

Diaspora là dự án Kickstarter đầu tiên vượt quá mục tiêu của nó. Kết quả là, họ đã được đăng trên tờ New York Times – điều này đã trở thành một vụ xì-căng-đan, bởi vì tấm bảng đen phía sau bức ảnh của cả đội có viết một trò đùa tục tĩu trên đó và không ai để ý cho đến khi nó thực sự được in ra. Trong THỜI GIAN YORK MỚI. Hậu quả từ đó thực sự là lần đầu tiên tôi nghe về dự án

Nhờ thành công trên Kickstarter, các chàng trai rời trường học và đến San Francisco để bắt đầu viết mã. Họ đã kết thúc trong văn phòng của tôi. Vào thời điểm đó, tôi đang làm việc tại Pivotal Labs và một trong những anh trai của họ cũng làm việc ở đó, vì vậy Pivotal đã cung cấp cho họ không gian làm việc miễn phí, internet và tất nhiên là quyền sử dụng tủ lạnh đựng bia. Tôi làm việc với khách hàng chính thức vào ban ngày, sau đó đi chơi với họ sau giờ làm việc và đóng góp mã vào cuối tuần

Cuối cùng họ đã ở lại Pivotal hơn hai năm. Tuy nhiên, vào cuối mùa hè đầu tiên đó, họ đã triển khai một mạng xã hội phân tán được xây dựng bằng Ruby on Rails và được hỗ trợ bởi MongoDB ở mức tối thiểu nhưng đang hoạt động (theo một số định nghĩa).

Đó là rất nhiều từ thông dụng. Hãy phá vỡ nó

“Mạng xã hội phân tán”

Nếu bạn đã xem Mạng xã hội, bạn sẽ biết mọi thứ bạn cần biết về Facebook. Đó là một ứng dụng web, chạy trên một máy chủ logic duy nhất và cho phép bạn giữ liên lạc với mọi người. Khi bạn đăng nhập, giao diện của Diaspora có cấu trúc tương tự như của Facebook

Ảnh chụp màn hình giao diện người dùng Diaspora

Có một nguồn cấp dữ liệu ở giữa hiển thị tất cả các bài đăng của bạn bè bạn và một số nội dung ngẫu nhiên khác ở hai bên mà chưa ai từng xem. Sự khác biệt kỹ thuật chính giữa Diaspora và Facebook là vô hình đối với người dùng cuối. đó là phần "phân phối"

Cơ sở hạ tầng Diaspora không nằm sau một địa chỉ web duy nhất. Có hàng trăm máy chủ Diaspora độc lập. Mã này là mã nguồn mở, vì vậy nếu bạn muốn, bạn có thể đứng lên máy chủ của riêng mình. Mỗi máy chủ, được gọi là nhóm, có cơ sở dữ liệu riêng và nhóm người dùng riêng, đồng thời sẽ tương tác với tất cả các nhóm Diaspora khác mà mỗi nhóm có cơ sở dữ liệu và nhóm người dùng riêng

Các nhóm có kích thước khác nhau giao tiếp với nhau mà không cần trung tâm

Mỗi nhóm giao tiếp với các nhóm khác thông qua API dựa trên HTTP. Khi bạn đã thiết lập tài khoản trên nhóm, nó sẽ khá nhàm chán cho đến khi bạn theo dõi một số người khác. Bạn có thể theo dõi những người dùng khác trên nhóm của mình và bạn cũng có thể theo dõi những người là người dùng trên các nhóm khác. Khi ai đó bạn theo dõi trên một nhóm khác đăng cập nhật, đây là điều sẽ xảy ra

1. Bản cập nhật đi vào cơ sở dữ liệu của nhóm tác giả

2. Nhóm của bạn được thông báo qua API

3. Bản cập nhật được lưu trong cơ sở dữ liệu nhóm của bạn

4. Bạn nhìn vào nguồn cấp dữ liệu hoạt động của mình và thấy bài đăng đó được trộn lẫn với bài đăng của những người khác mà bạn theo dõi

Nhận xét hoạt động theo cùng một cách. Trên bất kỳ bài đăng nào, một số nhận xét có thể là của những người trong cùng nhóm với tác giả của bài đăng và một số nhận xét có thể là của những người trong nhóm khác. Mọi người có quyền xem bài đăng sẽ thấy tất cả các bình luận, giống như bạn mong đợi nếu mọi người ở trên một máy chủ logic duy nhất

Ai quan tâm?

Kiến trúc này có những lợi thế về mặt kỹ thuật và pháp lý. Ưu điểm kỹ thuật chính là khả năng chịu lỗi

Đây là một hệ thống chịu lỗi rất quan trọng mà mọi văn phòng nên có

Nếu bất kỳ một trong các nhóm bị hỏng, nó sẽ không làm giảm các nhóm khác. Hệ thống tồn tại và thậm chí mong đợi, phân vùng mạng. Có một số ý nghĩa chính trị thú vị đối với điều đó - ví dụ: nếu bạn đang ở một quốc gia tắt internet đi để ngăn truy cập vào Facebook và Twitter, nhóm của bạn chạy cục bộ vẫn kết nối bạn với những người khác trong quốc gia của bạn, mặc dù không có gì bên ngoài

Lợi thế pháp lý chính là sự độc lập của máy chủ. Mỗi nhóm là một thực thể riêng biệt về mặt pháp lý, được điều chỉnh bởi luật của bất kỳ nơi nào nó được thiết lập. Mỗi nhóm cũng đặt điều khoản dịch vụ của riêng họ. Trên hầu hết các trang này, bạn có thể đăng nội dung mà không phải từ bỏ quyền của mình đối với nội dung đó, không giống như trên Facebook. Diaspora là phần mềm miễn phí theo cả nghĩa “miễn phí” và “miễn phí” của thuật ngữ này và hầu hết những người điều hành nhóm đều quan tâm sâu sắc đến loại điều đó

Vì vậy, đó là kiến ​​trúc của hệ thống. Hãy xem kiến ​​trúc trong một nhóm duy nhất

Đó là một ứng dụng Rails

Mỗi nhóm là một ứng dụng web Ruby on Rails được hỗ trợ bởi cơ sở dữ liệu, ban đầu là MongoDB. Theo một số cách, cơ sở mã là một ứng dụng Rails 'điển hình' - nó có cả giao diện người dùng trực quan và có lập trình, một số mã Ruby và cơ sở dữ liệu. Nhưng theo những cách khác, nó không phải là điển hình

Cấu trúc bên trong của một nhóm Diaspora

Tất nhiên, giao diện người dùng trực quan là cách người dùng trang web tương tác với Diaspora. API được sử dụng bởi nhiều ứng dụng di động Diaspora khác nhau - phần đó khá điển hình - nhưng nó cũng được sử dụng cho "liên kết", là tên kỹ thuật cho giao tiếp giữa các nhóm. (Tôi đã từng hỏi điểm truy cập của người Romulans ở đâu và nhận được rất nhiều cái nhìn trống rỗng. Thở dài. ) Vì vậy, bản chất phân tán của hệ thống thêm các lớp vào cơ sở mã không có trong một ứng dụng thông thường

Và tất nhiên, MongoDB là một lựa chọn không điển hình để lưu trữ dữ liệu. Phần lớn các ứng dụng Rails được hỗ trợ bởi PostgreSQL hoặc (ít thường xuyên hơn hiện nay) MySQL

Vì vậy, đó là mã. Hãy xem xét loại dữ liệu chúng tôi đang lưu trữ

Tôi không nghĩ rằng từ đó có nghĩa là những gì bạn nghĩ đó có nghĩa là

“Dữ liệu xã hội” là thông tin về mạng lưới bạn bè của chúng tôi, bạn bè của họ và hoạt động của họ. Về mặt khái niệm, chúng tôi nghĩ về nó như một mạng lưới — một biểu đồ vô hướng trong đó chúng tôi ở trung tâm và bạn bè của chúng tôi tỏa ra xung quanh chúng tôi

Hình ảnh tất cả từ rubyfriends. com. Cảm ơn Matt Rogers, Steve Klabnik, Nell Shamrell, Katrina Owen, Sam Livingston-Grey, Josh Susser, Akshay Khole, Pradyumna Dandwate và Hephzibah Watharkar vì đã đóng góp cho #rubyfriends

Khi chúng tôi lưu trữ dữ liệu xã hội, chúng tôi đang lưu trữ cấu trúc liên kết biểu đồ đó, cũng như hoạt động di chuyển dọc theo các cạnh đó

Trong một vài năm nay, người ta nhận thấy rằng dữ liệu xã hội không phải là dữ liệu quan hệ và nếu bạn lưu trữ nó trong cơ sở dữ liệu quan hệ, thì bạn đang làm sai

Nhưng các lựa chọn thay thế là gì? . Những người khác nói rằng cơ sở dữ liệu tài liệu là hoàn hảo cho dữ liệu xã hội và những cơ sở dữ liệu đó đủ chính thống để thực sự được sử dụng. Vì vậy, hãy xem tại sao mọi người nghĩ rằng dữ liệu xã hội phù hợp với MongoDB một cách tự nhiên hơn so với PostgreSQL

Cách MongoDB lưu trữ dữ liệu

MongoDB là cơ sở dữ liệu hướng tài liệu. Thay vì lưu trữ dữ liệu của bạn trong các bảng được tạo từ các hàng riêng lẻ, giống như cơ sở dữ liệu quan hệ, nó lưu trữ dữ liệu của bạn trong các bộ sưu tập được tạo từ các tài liệu riêng lẻ. Trong MongoDB, một tài liệu là một đốm màu JSON lớn không có định dạng hoặc lược đồ cụ thể

Giả sử bạn có một tập hợp các mối quan hệ như thế này mà bạn cần lập mô hình. Điều này khá giống với một dự án thông qua Pivotal đã sử dụng MongoDB và là trường hợp sử dụng tốt nhất mà tôi từng thấy đối với cơ sở dữ liệu tài liệu

Ở gốc, chúng tôi có một bộ chương trình truyền hình. Mỗi chương trình có nhiều mùa, mỗi mùa có nhiều tập và mỗi tập có nhiều đánh giá và nhiều diễn viên. Khi người dùng truy cập trang web này, thông thường họ sẽ truy cập trực tiếp vào trang dành cho một chương trình truyền hình cụ thể. Trên trang đó, họ thấy tất cả các phần và tất cả các tập cũng như tất cả các bài đánh giá và tất cả các diễn viên của chương trình đó, tất cả trên một trang. Vì vậy, từ góc độ ứng dụng, khi người dùng truy cập một trang, chúng tôi muốn truy xuất tất cả thông tin liên quan đến chương trình truyền hình đó

Có một số cách bạn có thể lập mô hình dữ liệu này. Trong một cửa hàng quan hệ điển hình, mỗi hộp này sẽ là một bảng. Bạn sẽ có bảng tv_shows, bảng seasons có khóa ngoại thành tv_shows, bảng episodes có khóa ngoại thành seasons và bảng reviews và cast_members có khóa ngoại thành episodes. Vì vậy, để có được tất cả thông tin cho một chương trình truyền hình, bạn đang xem tham gia năm bảng

Chúng tôi cũng có thể lập mô hình dữ liệu này dưới dạng một tập hợp các giá trị băm lồng nhau. Tập hợp thông tin về một chương trình truyền hình cụ thể là một cấu trúc dữ liệu khóa/giá trị lớn lồng nhau. Trong một chương trình truyền hình, có một loạt các phần, mỗi phần cũng là một hàm băm. Trong mỗi phần, một loạt các tập, mỗi tập là một hàm băm, v.v. Đây là cách MongoDB mô hình hóa dữ liệu. Mỗi chương trình truyền hình là một tài liệu chứa tất cả thông tin chúng tôi cần cho một chương trình

Đây là một tài liệu ví dụ cho một chương trình truyền hình, Babylon 5

Nó có một số siêu dữ liệu tiêu đề và sau đó là một loạt các mùa. Bản thân mỗi phần là một hàm băm với siêu dữ liệu và một loạt các tập. Đổi lại, mỗi tập có một số siêu dữ liệu và mảng cho cả đánh giá và diễn viên

Về cơ bản nó là một cấu trúc dữ liệu fractal khổng lồ

Bộ của bộ của bộ của bộ. fractals ngon

Tất cả dữ liệu chúng tôi cần cho một chương trình truyền hình nằm trong một tài liệu, vì vậy, rất nhanh chóng để truy xuất tất cả thông tin này cùng một lúc, ngay cả khi tài liệu rất lớn. Có một chương trình truyền hình ở Mỹ tên là “Bệnh viện đa khoa” đã phát sóng hơn 12.000 tập trong suốt hơn 50 mùa. Trên máy tính xách tay của tôi, PostgreSQL mất khoảng một phút để lấy dữ liệu không chuẩn hóa cho 12.000 tập, trong khi việc truy xuất tài liệu tương đương bằng ID trong MongoDB chỉ mất một phần giây

Vì vậy, theo nhiều cách, ứng dụng này đã trình bày trường hợp sử dụng lý tưởng cho kho lưu trữ tài liệu

Vâng. Nhưng còn dữ liệu xã hội thì sao?

Đúng. Khi bạn đến một trang mạng xã hội, chỉ có một phần quan trọng của trang. luồng hoạt động của bạn. Truy vấn luồng hoạt động nhận tất cả các bài đăng từ những người bạn theo dõi, được sắp xếp theo thứ tự gần đây nhất. Mỗi bài đăng đó có thông tin lồng nhau bên trong chúng, chẳng hạn như ảnh, lượt thích, lượt chia sẻ lại và nhận xét

Cấu trúc lồng nhau của dữ liệu luồng hoạt động trông rất giống với những gì chúng ta đang xem trên các chương trình truyền hình

Người dùng có bạn bè, bạn bè có bài viết, bài viết có bình luận và lượt thích, mỗi bình luận có một người bình luận và mỗi lượt thích có một người thích. Về mối quan hệ, nó không phức tạp hơn nhiều so với các chương trình truyền hình. Và cũng giống như các chương trình truyền hình, chúng tôi muốn lấy tất cả dữ liệu này cùng một lúc, ngay sau khi người dùng đăng nhập. Hơn nữa, trong một cửa hàng quan hệ, với dữ liệu được chuẩn hóa hoàn toàn, sẽ có một phép nối bảy bảng để lấy ra mọi thứ

Tham gia bảy bảng. ừ. Đột nhiên lưu trữ luồng hoạt động của mỗi người dùng dưới dạng một cấu trúc dữ liệu lồng nhau không chuẩn hóa lớn, thay vì thực hiện liên kết đó mọi lúc, có vẻ khá hấp dẫn

Vào năm 2010, khi nhóm Diaspora đưa ra quyết định này, các bài báo của Etsy về việc sử dụng kho lưu trữ tài liệu đã có ảnh hưởng khá lớn, mặc dù họ đã công khai rời khỏi MongoDB để lưu trữ dữ liệu. Tương tự như vậy, vào thời điểm đó, Cassandra của Facebook cũng đang khuấy động rất nhiều cuộc trò chuyện về việc rời khỏi cơ sở dữ liệu quan hệ. Diaspora đã chọn MongoDB cho dữ liệu xã hội của họ trong hệ tư tưởng này. Đó không phải là một lựa chọn vô lý vào thời điểm đó, với thông tin họ có

Cái gì có thể đi sai?

Có một sự khác biệt thực sự quan trọng giữa dữ liệu xã hội của Diaspora và dữ liệu chương trình truyền hình lý tưởng của Mongo mà ban đầu không ai nhận thấy

Với chương trình truyền hình, mỗi hộp trong sơ đồ mối quan hệ là một loại khác nhau. Chương trình truyền hình khác với mùa khác với tập phim khác với đánh giá khác với dàn diễn viên. Không ai trong số họ thậm chí là một loại phụ của loại khác

Nhưng với dữ liệu xã hội, một số hộp trong sơ đồ mối quan hệ là cùng một loại. Trên thực tế, tất cả các hộp màu xanh lá cây này đều cùng loại — tất cả đều là người dùng Diaspora

Người dùng có bạn bè và mỗi người bạn có thể là người dùng. Hoặc, họ có thể không, bởi vì đó là một hệ thống phân tán. (Đó là cả một lớp phức tạp mà hôm nay tôi sẽ bỏ qua. ) Theo cách tương tự, người bình luận và người thích cũng có thể là người dùng

Kiểu trùng lặp này khiến việc chuẩn hóa một luồng hoạt động thành một tài liệu trở nên khó khăn hơn. Đó là bởi vì ở những vị trí khác nhau trong tài liệu của bạn, bạn có thể đề cập đến cùng một khái niệm — trong trường hợp này là cùng một người dùng. Người dùng thích bài đăng đó trong luồng hoạt động của bạn cũng có thể là người dùng đã nhận xét về một bài đăng khác

Sao chép dữ liệu Sao chép dữ liệu

Chúng ta có thể biểu diễn điều này trong MongoDB theo một số cách khác nhau. Sao chép là bất kỳ tùy chọn dễ dàng. Tất cả thông tin về người bạn đó được sao chép và lưu vào phần thích trên bài đăng đầu tiên, sau đó một bản sao riêng được lưu vào phần bình luận trên bài đăng thứ hai. Ưu điểm là tất cả dữ liệu hiện diện ở mọi nơi bạn cần và bạn vẫn có thể kéo toàn bộ luồng hoạt động trở lại dưới dạng một tài liệu

Đây là loại tài liệu luồng không chuẩn hóa hoàn toàn này trông như thế nào

Ở đây chúng tôi có các bản sao dữ liệu người dùng được nội tuyến. Đây là luồng của Joe và luồng này có bản sao dữ liệu người dùng của anh ấy, bao gồm tên và URL của anh ấy, ở cấp cao nhất. Luồng của anh ấy, ngay bên dưới, chứa bài đăng của Jane. Joe đã thích bài đăng của Jane, vì vậy dưới lượt thích cho bài đăng của Jane, chúng tôi có một bản sao dữ liệu riêng của Joe

Bạn có thể thấy lý do tại sao điều này là hấp dẫn. tất cả dữ liệu bạn cần đã được đặt ở nơi bạn cần

Bạn cũng có thể thấy tại sao điều này lại nguy hiểm. Cập nhật dữ liệu của người dùng có nghĩa là xem qua tất cả các luồng hoạt động mà họ xuất hiện để thay đổi dữ liệu ở tất cả những nơi khác nhau đó. Điều này rất dễ xảy ra lỗi và thường dẫn đến dữ liệu không nhất quán và các lỗi bí ẩn, đặc biệt khi xử lý việc xóa

Không có hy vọng?

Có một cách tiếp cận khác mà bạn có thể thực hiện cho vấn đề này trong MongoDB, cách tiếp cận này sẽ quen thuộc hơn nếu bạn có nền tảng quan hệ. Thay vì sao chép dữ liệu người dùng, bạn có thể lưu trữ tham chiếu đến người dùng trong tài liệu luồng hoạt động

Với cách tiếp cận này, thay vì đưa dữ liệu người dùng này vào bất cứ nơi nào bạn cần, bạn cung cấp cho mỗi người dùng một ID. Sau khi người dùng có ID, chúng tôi lưu trữ ID của người dùng ở mọi nơi mà trước đây chúng tôi đã đặt dữ liệu nội tuyến. ID mới có màu xanh bên dưới

MongoDB thực sự sử dụng ID BSON, là các chuỗi giống như GUID, nhưng để làm cho các mẫu này dễ đọc hơn, tôi chỉ sử dụng số nguyên

Điều này giúp loại bỏ vấn đề trùng lặp của chúng tôi. Khi dữ liệu người dùng thay đổi, chỉ có một tài liệu được viết lại. Tuy nhiên, chúng tôi đã tạo ra một vấn đề mới cho chính mình. Vì chúng tôi đã di chuyển một số dữ liệu ra khỏi luồng hoạt động nên chúng tôi không còn có thể tạo luồng hoạt động từ một tài liệu nữa. Điều này kém hiệu quả và phức tạp hơn. Việc xây dựng luồng hoạt động hiện yêu cầu chúng tôi 1) truy xuất tài liệu luồng, sau đó 2) truy xuất tất cả tài liệu người dùng để điền tên và hình đại diện

Điều còn thiếu ở MongoDB là thao tác nối kiểu SQL, đó là khả năng viết một truy vấn kết hợp luồng hoạt động và tất cả người dùng mà luồng tham chiếu lại với nhau. Vì MongoDB không có khả năng này, thay vào đó, bạn sẽ thực hiện thủ công việc kết hợp đó trong mã ứng dụng của mình

Dữ liệu không chuẩn hóa đơn giản

Hãy quay lại chương trình truyền hình trong giây lát. Tập hợp các mối quan hệ cho một chương trình truyền hình không có nhiều phức tạp. Bởi vì tất cả các hộp trong sơ đồ mối quan hệ là các thực thể khác nhau, toàn bộ truy vấn có thể được chuyển thành một tài liệu không trùng lặp và không có tham chiếu. Trong cơ sở dữ liệu tài liệu này, không có liên kết giữa các tài liệu. Nó không yêu cầu tham gia

Tuy nhiên, trên một mạng xã hội, không có gì là khép kín. Bất cứ khi nào bạn nhìn thấy thứ gì đó trông giống như tên hoặc hình ảnh, bạn sẽ có thể nhấp vào nó và xem người dùng đó, hồ sơ của họ và bài đăng của họ. Ứng dụng chương trình truyền hình không hoạt động theo cách đó. Nếu bạn đang xem phần 1 tập 1 của Babylon 5, bạn sẽ không thể nhấp qua phần 1 tập 1 của Bệnh viện đa khoa

Đừng. liên kết. Các. Các tài liệu

Khi chúng tôi bắt đầu thực hiện các tham gia MongoDB xấu xí theo cách thủ công trong mã Diaspora, chúng tôi biết đó là dấu hiệu đầu tiên của sự cố. Đó là dấu hiệu cho thấy dữ liệu của chúng tôi thực sự có quan hệ, rằng có giá trị đối với cấu trúc đó và chúng tôi đang đi ngược lại khái niệm cơ bản về kho lưu trữ dữ liệu tài liệu

Cho dù bạn đang sao chép dữ liệu quan trọng (ugh) hay sử dụng tham chiếu và thực hiện liên kết trong mã ứng dụng của mình (gấp đôi ugh), khi bạn có liên kết giữa các tài liệu, bạn đã phát triển vượt trội MongoDB. Khi những người MongoDB nói “tài liệu”, theo nhiều cách, chúng có nghĩa là những thứ bạn có thể in ra một tờ giấy và giữ. Một tài liệu có thể có cấu trúc bên trong — tiêu đề và tiêu đề phụ, đoạn văn và chân trang — nhưng nó không liên kết đến các tài liệu khác. Đó là một phần dữ liệu bán cấu trúc độc lập

Nếu dữ liệu của bạn trông giống như vậy, bạn đã có tài liệu. Xin chúc mừng. Đó là một trường hợp sử dụng tốt cho Mongo. Nhưng nếu có giá trị trong các liên kết giữa các tài liệu, thì bạn thực sự không có tài liệu. MongoDB không phải là giải pháp phù hợp với bạn. Đó chắc chắn không phải là giải pháp phù hợp cho dữ liệu xã hội, nơi liên kết giữa các tài liệu thực sự là dữ liệu quan trọng nhất trong hệ thống

Vì vậy, dữ liệu xã hội không phải là định hướng tài liệu. Điều đó có nghĩa là nó thực sự…quan hệ?

Lời đó một lần nữa

Khi mọi người nói "dữ liệu xã hội không phải là quan hệ", đó không thực sự là ý của họ. Họ có nghĩa là một trong hai điều này

1. “Về mặt khái niệm, dữ liệu xã hội giống một biểu đồ hơn là một tập hợp các bảng. ”

Điều này hoàn toàn đúng. Nhưng thực tế có rất ít khái niệm trên thế giới được mô hình hóa một cách tự nhiên dưới dạng bảng chuẩn hóa. Chúng tôi sử dụng cấu trúc đó vì nó hiệu quả, tránh trùng lặp và vì khi nó bị chậm, chúng tôi biết cách khắc phục

2. “Việc lấy tất cả dữ liệu từ một truy vấn xã hội sẽ nhanh hơn khi dữ liệu đó được phi chuẩn hóa thành một tài liệu duy nhất. ”

Điều này cũng hoàn toàn đúng. Khi dữ liệu xã hội của bạn ở trong một kho lưu trữ quan hệ, bạn cần nối nhiều bảng để trích xuất luồng hoạt động cho một người dùng cụ thể và điều đó sẽ chậm lại khi các bảng của bạn lớn hơn. Tuy nhiên, chúng tôi có một giải pháp được hiểu rõ cho vấn đề này. Nó được gọi là bộ nhớ đệm

Tại All Your Base Conf ở Oxford đầu năm nay, nơi tôi đưa ra phiên bản thảo luận của bài đăng này, Neha Narula đã có một cuộc nói chuyện tuyệt vời về bộ nhớ đệm mà tôi khuyên bạn nên xem sau khi nó được đăng. Trong mọi trường hợp, bộ nhớ đệm trước kho lưu trữ dữ liệu được chuẩn hóa là một vấn đề phức tạp nhưng đã được hiểu rõ. Tôi đã thấy các dự án lưu trữ dữ liệu luồng hoạt động không chuẩn hóa vào bộ nhớ cache vào cơ sở dữ liệu tài liệu như MongoDB, giúp truy xuất dữ liệu đó nhanh hơn nhiều. Vấn đề duy nhất họ gặp phải sau đó là mất hiệu lực bộ nhớ cache

“Chỉ có hai vấn đề khó khăn trong khoa học máy tính. vô hiệu hóa bộ đệm và đặt tên cho mọi thứ. ”

Phil Karlton

Hóa ra việc vô hiệu hóa bộ đệm thực sự khá khó. Phil Karlton đã viết hầu hết SSL phiên bản 3, X11 và OpenGL, vì vậy anh ấy biết một vài điều về khoa học máy tính

Vô hiệu hóa bộ nhớ cache dưới dạng dịch vụ

Nhưng vô hiệu hóa bộ đệm là gì và tại sao nó lại khó đến vậy?

Vô hiệu hóa bộ đệm chỉ biết khi nào một phần dữ liệu được lưu trong bộ nhớ cache của bạn đã lỗi thời và cần được cập nhật hoặc thay thế. Đây là một ví dụ điển hình mà tôi thấy hàng ngày trong các ứng dụng web. Chúng tôi có một cửa hàng sao lưu, điển hình là PostgreSQL hoặc MySQL, và phía trước chúng tôi có một lớp bộ nhớ đệm, thường là Memcached hoặc Redis. Các yêu cầu đọc luồng hoạt động của người dùng sẽ chuyển đến bộ nhớ cache thay vì trực tiếp vào cơ sở dữ liệu, điều này khiến chúng rất nhanh

Thiết lập cửa hàng sao lưu và bộ đệm điển hình

Viết ứng dụng phức tạp hơn. Giả sử một người dùng có hai người theo dõi viết một bài đăng mới. Điều đầu tiên xảy ra (phần 1) là dữ liệu bài đăng được sao chép vào kho lưu trữ. Sau khi hoàn tất, một công việc nền (phần 2)  sẽ nối bài đăng đó vào luồng hoạt động đã lưu trong bộ nhớ cache của cả hai người dùng theo dõi tác giả

Mẫu này khá phổ biến. Twitter giữ các luồng hoạt động của người dùng hoạt động gần đây trong bộ đệm trong bộ nhớ, chúng sẽ thêm vào khi ai đó họ theo dõi đăng nội dung nào đó. Ngay cả các ứng dụng nhỏ hơn sử dụng một số loại luồng hoạt động thường sẽ kết thúc tại đây (xem. tham gia bảy bảng)

Quay lại ví dụ của chúng tôi. Khi tác giả thay đổi một bài đăng hiện có, quy trình cập nhật về cơ bản giống như quá trình tạo, ngoại trừ thay vì thêm vào bộ đệm, nó sẽ cập nhật một mục đã có ở đó

Điều gì xảy ra nếu công việc nền bước 2 không thành công giữa chừng? . Sự không ổn định là hằng số duy nhất trong công việc của chúng tôi. Khi điều đó xảy ra, bạn sẽ nhận được dữ liệu không hợp lệ trong bộ đệm của mình. Một số bản sao của bài viết sẽ có tiêu đề cũ và một số bản sao sẽ có tiêu đề mới. Đó là một vấn đề khó, nhưng với bộ đệm, luôn có tùy chọn hạt nhân

Luôn luôn là một lựa chọn >_<

Bạn luôn có thể xóa toàn bộ bản ghi luồng hoạt động khỏi bộ nhớ đệm và tạo lại bản ghi đó từ kho lưu trữ sao lưu nhất quán của mình. Nó có thể chậm, nhưng ít nhất nó có thể

Nếu không có cửa hàng hỗ trợ thì sao?

Khi MongoDB là tất cả những gì bạn có, đó là bộ đệm không có kho lưu trữ phía sau. Nó sẽ trở nên không nhất quán. Cuối cùng không nhất quán - chỉ đơn giản, hoàn toàn không nhất quán, mọi lúc. Tại thời điểm đó, bạn không có lựa chọn nào. Thậm chí không phải là hạt nhân. Bạn không có cách nào để tạo lại dữ liệu ở trạng thái nhất quán

Khi Diaspora quyết định lưu trữ dữ liệu xã hội trong MongoDB, chúng tôi đã kết hợp cơ sở dữ liệu với bộ đệm. Cơ sở dữ liệu và bộ đệm là những thứ rất khác nhau. Họ có những ý tưởng rất khác nhau về tính lâu dài, tính nhất thời, tính trùng lặp, tài liệu tham khảo, tính toàn vẹn của dữ liệu và tốc độ

chuyển đổi

Khi chúng tôi phát hiện ra rằng chúng tôi đã vô tình chọn bộ đệm cho cơ sở dữ liệu của mình, chúng tôi đã làm gì với nó?

Chà, đó là câu hỏi triệu đô. Nhưng tôi đã trả lời câu hỏi tỷ đô rồi. Trong bài đăng này, tôi đã nói về cách chúng tôi sử dụng MongoDB so với. làm thế nào nó được thiết kế để được sử dụng. Tôi đã nói về nó như thể tất cả thông tin đó đều hiển nhiên và nhóm Diaspora đã không nghiên cứu đầy đủ trước khi chọn

Nhưng những thứ này không rõ ràng chút nào. Các tài liệu MongoDB cho bạn biết nó giỏi ở điểm nào mà không nhấn mạnh nó không giỏi ở điểm nào. Đó là điều tự nhiên. Tất cả các dự án làm điều đó. Nhưng kết quả là chúng tôi đã mất khoảng sáu tháng, rất nhiều khiếu nại của người dùng và rất nhiều cuộc điều tra để tìm ra rằng chúng tôi đã sử dụng MongoDB sai cách

Không có gì để làm ngoài việc lấy dữ liệu ra khỏi MongoDB và chuyển nó đến một kho lưu trữ quan hệ, xử lý tốt nhất có thể với dữ liệu không nhất quán mà chúng tôi đã phát hiện ra trong quá trình thực hiện. Bản thân việc chuyển đổi dữ liệu — xuất từ ​​MongoDB, nhập vào MySQL — rất đơn giản. Đối với các chi tiết cơ học, bạn có thể xem các slide của tôi từ All Your Base Conf 2013

Thiệt hại

Chúng tôi có tám tháng dữ liệu sản xuất, biến thành khoảng 1. 2 triệu hàng trong MySQL. Chúng tôi đã dành bốn tuần để phát triển mã cho chuyển đổi và khi chúng tôi kích hoạt, trang web chính có khoảng hai giờ ngừng hoạt động. Điều đó quá mức chấp nhận được đối với một dự án ở giai đoạn tiền alpha. Chúng tôi có thể giảm thời gian ngừng hoạt động đó nhiều hơn, nhưng chúng tôi đã lập ngân sách cho tám giờ ngừng hoạt động, vì vậy hai giờ thực sự có vẻ tuyệt vời

KHÔNG TỆ

phần kết

Bạn có nhớ ứng dụng chương trình truyền hình đó không? . Mỗi chương trình là một tài liệu, hoàn toàn khép kín. Không có tham chiếu đến bất cứ thứ gì, không trùng lặp và không có cách nào để dữ liệu trở nên không nhất quán

Khoảng ba tháng sau khi phát triển, nó vẫn hoạt động tốt trên MongoDB. Một ngày thứ Hai, tại cuộc họp lập kế hoạch hàng tuần, khách hàng nói với chúng tôi về một tính năng mới mà một trong những nhà đầu tư của họ muốn. khi họ đang xem các diễn viên trong một tập của một chương trình, họ muốn có thể nhấp vào tên của một diễn viên và xem toàn bộ sự nghiệp truyền hình của người đó. Họ muốn có một danh sách theo trình tự thời gian của tất cả các tập của tất cả các chương trình khác nhau mà diễn viên đã từng tham gia.

Chúng tôi đã lưu trữ mỗi chương trình dưới dạng tài liệu trong MongoDB chứa tất cả thông tin lồng nhau của nó, bao gồm cả các thành viên diễn viên. Nếu cùng một diễn viên xuất hiện trong hai tập khác nhau, thậm chí của cùng một chương trình, thông tin của họ sẽ được lưu trữ ở cả hai nơi. Chúng tôi không có cách nào để biết, ngoài việc so sánh tên, liệu họ có phải là cùng một người hay không. Vì vậy, để triển khai tính năng này, chúng tôi cần tìm kiếm trong mọi tài liệu để tìm và loại bỏ các phiên bản trùng lặp của tác nhân mà người dùng đã nhấp vào. ừ. Ở mức tối thiểu, chúng tôi cần loại bỏ trùng lặp chúng một lần, sau đó duy trì một chỉ mục bên ngoài về thông tin diễn viên, chỉ mục này sẽ có các vấn đề về tính không hợp lệ giống như bất kỳ bộ đệm nào khác

Bạn thấy nơi này sẽ đi

Khách hàng mong đợi tính năng này là tầm thường. Nếu dữ liệu đã ở trong một cửa hàng quan hệ, nó sẽ là. Đúng như vậy, trước tiên chúng tôi cố gắng thuyết phục Thủ tướng rằng họ không cần nó. Sau khi thất bại, chúng tôi đã cung cấp một số lựa chọn thay thế rẻ hơn, chẳng hạn như liên kết với tìm kiếm IMDB cho tên diễn viên. Tuy nhiên, công ty kiếm tiền từ quảng cáo, vì vậy họ muốn người dùng ở lại trang web của họ thay vì truy cập IMDB

Yêu cầu tính năng này cuối cùng đã thúc đẩy chuyển đổi dự án sang PostgreSQL. Sau nhiều cuộc trò chuyện với khách hàng, chúng tôi nhận ra rằng doanh nghiệp đã nhận thấy rất nhiều giá trị trong việc liên kết các chương trình truyền hình với nhau. Họ hình dung sẽ xem các chương trình khác mà một đạo diễn cụ thể đã tham gia và các tập của các chương trình khác được phát hành cùng tuần với chương trình này, trong số những thứ khác

Đây cuối cùng là một vấn đề giao tiếp chứ không phải là một vấn đề kỹ thuật. Nếu những cuộc trò chuyện này diễn ra sớm hơn, nếu chúng tôi dành thời gian để thực sự hiểu cách khách hàng xem dữ liệu và họ muốn làm gì với dữ liệu đó, thì có lẽ chúng tôi đã thực hiện chuyển đổi sớm hơn, khi có ít dữ liệu hơn và dễ dàng hơn.

Luôn luôn học hỏi

Tôi đã học được điều gì đó từ kinh nghiệm đó. Trường hợp sử dụng lý tưởng của MongoDB thậm chí còn hẹp hơn dữ liệu truyền hình của chúng tôi. Điều duy nhất nó giỏi là lưu trữ các đoạn JSON tùy ý. "Tùy tiện", trong ngữ cảnh này, có nghĩa là bạn không quan tâm đến những gì bên trong JSON đó. Bạn thậm chí không nhìn. Không có lược đồ, thậm chí không có lược đồ ẩn, như trong dữ liệu chương trình truyền hình của chúng tôi. Mỗi tài liệu chỉ là một đốm màu bên trong mà bạn hoàn toàn không có giả định nào về

Tại RubyConf cuối tuần này, tôi tình cờ gặp Conrad Irwin, người đã đề xuất trường hợp sử dụng này. Anh ấy đã sử dụng MongoDB để lưu trữ các bit JSON tùy ý đến từ khách hàng thông qua API. Sự hợp lý của nó. Định lý CAP không thành vấn đề khi dữ liệu của bạn vô nghĩa. Nhưng trong các ứng dụng thú vị, dữ liệu của bạn không phải là vô nghĩa

Tôi đã nghe nhiều người nói về việc đưa MongoDB vào ứng dụng web của họ để thay thế cho MySQL hoặc PostgreSQL. Không có hoàn cảnh theo đó đó là một ý tưởng tốt. Tính linh hoạt của lược đồ nghe có vẻ là một ý tưởng tuyệt vời, nhưng lần duy nhất nó thực sự hữu ích là khi cấu trúc dữ liệu của bạn không có giá trị. Nếu bạn có một lược đồ ẩn — nghĩa là, nếu có những thứ bạn đang mong đợi trong JSON đó — thì MongoDB là một lựa chọn sai lầm. Tôi khuyên bạn nên xem hstore của PostgreSQL (dù sao bây giờ rõ ràng là nhanh hơn MongoDB) và tìm hiểu cách thực hiện các thay đổi lược đồ. Chúng thực sự không khó, ngay cả trong những chiếc bàn lớn

Tìm giá trị

Khi bạn chọn một kho lưu trữ dữ liệu, điều quan trọng nhất cần hiểu là dữ liệu của bạn ở đâu — và ở đâu trong các kết nối của nó — giá trị kinh doanh nằm ở đâu. Nếu bạn chưa biết, điều đó hoàn toàn hợp lý, thì hãy chọn thứ gì đó sẽ không dồn bạn vào chân tường. Đẩy JSON tùy ý vào cơ sở dữ liệu của bạn nghe có vẻ linh hoạt, nhưng tính linh hoạt thực sự là dễ dàng thêm các tính năng mà doanh nghiệp của bạn cần

Nhược điểm của MongoDB là gì?

Khi nào bạn nên sử dụng MongoDB?

Tại sao bạn chọn MongoDB mà không phải những người khác?

Khi nào bạn nên sử dụng MongoDB thay vì SQL?