Hãy để tôi kể một câu chuyện kỹ thuật.
Nhiều năm trước, tôi đã phát triển một ứng dụng có các tính năng cộng tác được tích hợp sẵn trong đó. Đó là một ngăn xếp thử nghiệm thân thiện với người dùng, tận dụng tối đa tiềm năng của React và CouchDB thời kỳ đầu. Nó đồng bộ hóa dữ liệu theo thời gian thực thông qua JSON . Nó được sử dụng trong nội bộ công ty, nhưng khả năng ứng dụng rộng rãi và tiềm năng của nó trong các lĩnh vực khác là rất rõ ràng.
Trong khi cố gắng bán công nghệ này cho các khách hàng tiềm năng, chúng tôi đã gặp phải một trở ngại không ngờ tới. Trong video demo, công nghệ của chúng tôi trông và hoạt động rất tốt, không có vấn đề gì. Video cho thấy chính xác cách thức hoạt động và không bắt chước bất cứ điều gì. Chúng tôi đã nghĩ ra và viết mã một kịch bản thực tế để sử dụng chương trình.
Trên thực tế, điều này đã trở thành vấn đề. Bản demo của chúng tôi hoạt động chính xác theo cách mà mọi người khác đã mô phỏng ứng dụng của họ. Cụ thể, thông tin được chuyển ngay lập tức từ A sang B, ngay cả khi đó là các tệp phương tiện lớn. Sau khi đăng nhập, mỗi người dùng sẽ thấy các mục mới. Khi sử dụng ứng dụng, những người dùng khác nhau có thể làm việc cùng nhau một cách rõ ràng trên cùng một dự án, ngay cả khi kết nối Internet bị gián đoạn ở đâu đó trong làng. Điều này được ngầm ám chỉ trong bất kỳ video cắt sản phẩm nào trong After Effects.
Mặc dù mọi người đều biết nút Làm mới dùng để làm gì, nhưng không ai thực sự hiểu rằng các ứng dụng web mà họ yêu cầu chúng tôi xây dựng thường có những hạn chế riêng. Và rằng nếu chúng không còn cần thiết nữa, trải nghiệm người dùng sẽ hoàn toàn khác. Hầu hết họ nhận thấy rằng họ có thể “trò chuyện” bằng cách để lại ghi chú cho những người họ đang nói chuyện, vì vậy, họ tự hỏi điều này khác với Slack chẳng hạn như thế nào. Phù!
Thiết kế đồng bộ hàng ngày
Nếu bạn có kinh nghiệm trong việc phát triển phần mềm, chắc hẳn bạn sẽ rất lo lắng khi nhớ rằng hầu hết mọi người không thể chỉ nhìn vào hình ảnh của một giao diện và hiểu nó sẽ làm gì khi tương tác với nó. Chưa kể những gì xảy ra bên trong chương trình. Kiến thức đó có thể xảy ra phần lớn là kết quả của việc biết điều gì không thể xảy ra và điều gì không nên xảy ra. Điều này đòi hỏi không chỉ chức năng của phần mềm mà còn cả cách các bộ phận riêng lẻ của nó được phối hợp và giao tiếp với nhau như thế nào.
Một ví dụ kinh điển về điều này là người dùng nhìn chằm chằm vào một spinner.gif, tự hỏi khi nào công việc cuối cùng sẽ được hoàn thành. Nhà phát triển có thể đã nhận ra rằng quá trình này có thể đã bị kẹt và ảnh gif sẽ không bao giờ biến mất khỏi màn hình. Hoạt hình này mô phỏng việc thực hiện một công việc nhưng không liên quan đến trạng thái của nó. Trong những trường hợp như vậy, một số kỹ thuật viên thích trợn mắt ngạc nhiên trước mức độ nhầm lẫn của người dùng. Tuy nhiên, hãy để ý xem có bao nhiêu người trong số họ chỉ vào chiếc đồng hồ đang quay và nói rằng nó thực sự đứng yên?
Đây là bản chất của giá trị thời gian thực. Ngày nay, cơ sở dữ liệu thời gian thực vẫn còn rất ít được sử dụng và nhiều người nghi ngờ chúng. Hầu hết các cơ sở dữ liệu này nghiêng nhiều về phong cách NoSQL, đó là lý do tại sao chúng thường sử dụng các giải pháp dựa trên Mongo, những giải pháp tốt nhất nên bị lãng quên. Tuy nhiên, đối với tôi, điều này có nghĩa là cảm thấy thoải mái khi làm việc với CouchDB, cũng như học cách thiết kế các cấu trúc mà không chỉ một số quan chức có thể lấp đầy dữ liệu. Tôi nghĩ tôi đang sử dụng thời gian của mình tốt hơn.
Nhưng chủ đề thực sự của bài đăng này là những gì tôi đang sử dụng ngày hôm nay. Không phải do lựa chọn mà do chính sách doanh nghiệp áp dụng một cách thờ ơ, mù quáng. Vì vậy, tôi sẽ đưa ra so sánh Hoàn toàn công bằng và không thiên vị về hai sản phẩm cơ sở dữ liệu thời gian thực có liên quan chặt chẽ với nhau của Google.
Cả hai đều có chữ Fire trong tên của họ. Có một điều tôi nhớ một cách trìu mến. Điều thứ hai đối với tôi là một loại lửa khác. Tôi không vội nói tên họ, vì một khi tôi làm vậy, chúng ta sẽ gặp phải vấn đề lớn đầu tiên: tên.
Cái đầu tiên được gọi là Cơ sở dữ liệu thời gian thực của Firebasevà thứ hai - Cửa hàng lửa đám mây Firebase. Cả hai đều là sản phẩm của Bộ căn cứ hỏa lực Google. API của họ được gọi tương ứng firebase.database(…) и firebase.firestore(…).
Điều này xảy ra bởi vì Cơ sở dữ liệu thời gian thực - nó chỉ là bản gốc thôi Tường lửa trước khi được Google mua lại vào năm 2014. Sau đó Google quyết định tạo ra như một sản phẩm song song sao chép Firebase dựa trên công ty dữ liệu lớn và gọi nó là Firestore với đám mây. Tôi hy vọng bạn chưa nhầm lẫn. Nếu bạn vẫn còn bối rối, đừng lo lắng, bản thân tôi đã viết lại phần này của bài viết tới mười lần.
Bởi vì bạn cần phải chỉ ra Tường lửa trong câu hỏi về Firebase và lò sưởi trong một câu hỏi về Firebase, ít nhất là để bạn hiểu cách đây vài năm trên Stack Overflow.
Nếu có giải thưởng cho trải nghiệm đặt tên phần mềm tệ nhất thì đây chắc chắn sẽ là một trong những ứng cử viên. Khoảng cách Hamming giữa những cái tên này nhỏ đến mức khiến ngay cả những kỹ sư giàu kinh nghiệm cũng bối rối khi ngón tay gõ một tên trong khi đầu họ đang nghĩ về một tên khác. Đây là những kế hoạch có thiện chí nhưng lại thất bại thảm hại; họ đã ứng nghiệm lời tiên tri rằng cơ sở dữ liệu sẽ bốc cháy. Và tôi không đùa chút nào. Người nghĩ ra cách đặt tên này đã đổ máu, mồ hôi và nước mắt.
Chiến thắng Pyrrhic
Người ta sẽ nghĩ rằng Firestore là sự thay thế Firebase, hậu duệ thế hệ tiếp theo của nó, nhưng điều đó sẽ gây hiểu nhầm. Firestore không được đảm bảo là sự thay thế phù hợp cho Firebase. Có vẻ như ai đó đã cắt bỏ mọi thứ thú vị khỏi nó và nhầm lẫn hầu hết những thứ còn lại theo nhiều cách khác nhau.
Tuy nhiên, việc xem nhanh hai sản phẩm này có thể khiến bạn bối rối: chúng dường như làm cùng một việc, về cơ bản là giống nhau về các API và thậm chí trong cùng một phiên cơ sở dữ liệu. Sự khác biệt rất nhỏ và chỉ được tiết lộ bằng cách nghiên cứu so sánh cẩn thận các tài liệu sâu rộng. Hoặc khi bạn đang cố gắng chuyển mã hoạt động hoàn hảo trên Firebase để nó hoạt động với Firestore. Thậm chí sau đó bạn còn phát hiện ra rằng giao diện cơ sở dữ liệu sẽ sáng lên ngay khi bạn cố gắng kéo và thả bằng chuột trong thời gian thực. Tôi nhắc lại, tôi không nói đùa.
Ứng dụng khách Firebase lịch sự theo nghĩa là nó đệm các thay đổi và tự động thử lại các bản cập nhật ưu tiên cho thao tác ghi cuối cùng. Tuy nhiên, Firestore có giới hạn 1 thao tác ghi cho mỗi tài liệu cho mỗi người dùng mỗi giây và giới hạn này được thực thi bởi máy chủ. Khi làm việc với nó, bạn phải tìm cách giải quyết nó và triển khai giới hạn tốc độ cập nhật, ngay cả khi bạn chỉ đang cố gắng xây dựng ứng dụng của mình. Nghĩa là, Firestore là một cơ sở dữ liệu thời gian thực không có ứng dụng khách thời gian thực, giả mạo là một cơ sở dữ liệu sử dụng API.
Ở đây chúng ta bắt đầu thấy những dấu hiệu đầu tiên về tồn tại của Firestore. Tôi có thể sai, nhưng tôi nghi ngờ rằng ai đó cấp cao trong ban quản lý của Google đã nhìn vào Firebase sau khi mua hàng và nói đơn giản: “Không, Chúa ơi, không. Điều này là không thể chấp nhận được. Chỉ là không dưới sự lãnh đạo của tôi thôi."
Anh ta xuất hiện từ phòng của mình và tuyên bố:
“Một tài liệu JSON lớn? KHÔNG. Bạn sẽ chia dữ liệu thành các tài liệu riêng biệt, mỗi tài liệu sẽ có kích thước không quá 1 megabyte.”
Có vẻ như hạn chế như vậy sẽ không tồn tại trong lần gặp đầu tiên với bất kỳ cơ sở người dùng nào có đủ động lực. Bạn biết đấy. Ví dụ: tại nơi làm việc, chúng tôi có hơn một nghìn rưỡi bài thuyết trình và điều này là Hoàn toàn bình thường.
Với hạn chế này, bạn sẽ buộc phải chấp nhận thực tế là một "tài liệu" trong cơ sở dữ liệu sẽ không giống bất kỳ đối tượng nào mà người dùng có thể gọi là tài liệu.
"Mảng mảng có thể chứa đệ quy các phần tử khác? KHÔNG. Mảng sẽ chỉ chứa các đối tượng hoặc số có độ dài cố định, như ý định của Chúa."
Vì vậy, nếu bạn đang hy vọng đưa GeoJSON vào Firestore của mình, bạn sẽ thấy rằng điều này là không thể. Không có gì không một chiều có thể được chấp nhận. Tôi hy vọng bạn thích Base64 và/hoặc JSON trong JSON.
“Nhập và xuất JSON qua HTTP, công cụ dòng lệnh hoặc bảng quản trị? KHÔNG. Bạn sẽ chỉ có thể xuất và nhập dữ liệu vào Google Cloud Storage. Đó là những gì nó được gọi bây giờ, tôi nghĩ vậy. Và khi tôi nói “bạn”, tôi chỉ đề cập đến những người có bằng cấp của Chủ dự án. Mọi người khác có thể đi và tạo vé."
Như bạn có thể thấy, mô hình dữ liệu FireBase rất dễ mô tả. Nó chứa một tài liệu JSON khổng lồ liên kết các khóa JSON với đường dẫn URL. Nếu bạn viết với HTTP PUT в / FireBase như sau:
{
"hello": "world"
}
Các GET /hello sẽ trở lại "world". Về cơ bản nó hoạt động chính xác như bạn mong đợi. Bộ sưu tập các đối tượng FireBase /my-collection/:id tương đương với một từ điển JSON {"my-collection": {...}} trong thư mục gốc, nội dung của nó có sẵn trong /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Điều này hoạt động tốt nếu mỗi phần chèn có ID không xung đột mà hệ thống có giải pháp tiêu chuẩn.
Nói cách khác, cơ sở dữ liệu tương thích 100% JSON(*) và hoạt động tốt với HTTP, chẳng hạn như CouchDB. Nhưng về cơ bản, bạn sử dụng nó thông qua API thời gian thực để tóm tắt các ổ cắm web, ủy quyền và đăng ký. Bảng quản trị có cả hai khả năng, cho phép chỉnh sửa theo thời gian thực và nhập/xuất JSON. Nếu bạn làm điều tương tự trong mã của mình, bạn sẽ ngạc nhiên về mức độ lãng phí của mã chuyên dụng khi bạn nhận ra rằng JSON vá lỗi và khác biệt giải quyết được 90% các tác vụ thông thường trong việc xử lý trạng thái liên tục.
Mô hình dữ liệu Firestore tương tự như JSON nhưng khác ở một số điểm quan trọng. Tôi đã đề cập đến việc thiếu mảng trong mảng. Mô hình dành cho các bộ sưu tập phụ dành cho chúng là các khái niệm hạng nhất, tách biệt với tài liệu JSON chứa chúng. Vì không có sự tuần tự hóa sẵn có cho việc này nên cần có một đường dẫn mã chuyên dụng để truy xuất và ghi dữ liệu. Để xử lý các bộ sưu tập của riêng bạn, bạn cần viết các tập lệnh và công cụ của riêng mình. Bảng quản trị chỉ cho phép bạn thực hiện các thay đổi nhỏ từng trường một và không có khả năng nhập/xuất.
Họ lấy cơ sở dữ liệu NoSQL thời gian thực và biến nó thành một cơ sở dữ liệu không phải SQL chậm với tính năng tự động tham gia và một cột không phải JSON riêng biệt. Một cái gì đó giống như GraftQL.
Java nóng
Nếu Firestore được cho là đáng tin cậy và có khả năng mở rộng hơn, thì điều trớ trêu là nhà phát triển trung bình sẽ kết thúc với một giải pháp kém tin cậy hơn là chọn FireBase ngay từ đầu. Loại phần mềm mà Quản trị viên cơ sở dữ liệu Grumpy cần đòi hỏi mức độ nỗ lực và tài năng tầm cỡ, điều này đơn giản là không thực tế đối với lĩnh vực mà sản phẩm được cho là giỏi. Điều này tương tự như cách HTML5 Canvas hoàn toàn không phải là sự thay thế cho Flash nếu không có công cụ phát triển và trình phát. Hơn nữa, Firestore bị sa lầy trong mong muốn về độ tinh khiết của dữ liệu và xác thực vô trùng, đơn giản là không phù hợp với cách người dùng doanh nghiệp bình thường thích làm việc: đối với anh ấy mọi thứ đều là tùy chọn, bởi vì cho đến cuối cùng mọi thứ đều là bản nháp.
Nhược điểm chính của FireBase là ứng dụng khách đã được tạo trước thời đại vài năm, trước khi hầu hết các nhà phát triển web biết đến tính bất biến. Vì điều này, FireBase giả định rằng bạn sẽ thay đổi dữ liệu và do đó không tận dụng được tính bất biến do người dùng cung cấp. Ngoài ra, nó không sử dụng lại dữ liệu trong các ảnh chụp nhanh mà nó chuyển cho người dùng, điều này khiến việc tìm khác biệt trở nên khó khăn hơn nhiều. Đối với các tài liệu lớn, cơ chế giao dịch dựa trên khác biệt có thể thay đổi của nó đơn giản là không đủ. Các bạn, chúng ta đã có rồi WeakMap trong JavaScript. Thật thoải mái.
Nếu bạn cung cấp cho dữ liệu hình dạng mong muốn và không làm cho cây quá đồ sộ thì vấn đề này có thể được khắc phục. Nhưng tôi tò mò liệu FireBase có thú vị hơn nhiều không nếu các nhà phát triển phát hành một API ứng dụng khách thực sự tốt sử dụng tính bất biến kết hợp với một số lời khuyên thực tế nghiêm túc về thiết kế cơ sở dữ liệu. Thay vào đó, họ dường như cố gắng sửa chữa những gì không bị hỏng và điều đó khiến mọi việc trở nên tồi tệ hơn.
Tôi không biết tất cả logic đằng sau việc tạo ra Firestore. Suy đoán về động cơ nảy sinh bên trong hộp đen cũng là một phần thú vị. Sự đặt cạnh nhau của hai cơ sở dữ liệu cực kỳ giống nhau nhưng không thể so sánh được là khá hiếm. Giống như có người đã nghĩ: "Firebase chỉ là một chức năng mà chúng tôi có thể mô phỏng trong Google Cloud", nhưng vẫn chưa khám phá ra khái niệm xác định các yêu cầu trong thế giới thực hoặc tạo ra các giải pháp hữu ích đáp ứng tất cả các yêu cầu đó. “Hãy để các nhà phát triển suy nghĩ về điều đó. Chỉ cần làm cho giao diện người dùng đẹp hơn… Bạn có thể thêm lửa không?”
Tôi hiểu một vài điều về cấu trúc dữ liệu. Tôi chắc chắn coi khái niệm "mọi thứ trong một cây JSON lớn" là một nỗ lực nhằm trừu tượng hóa mọi ý nghĩa về cấu trúc quy mô lớn khỏi cơ sở dữ liệu. Việc mong đợi phần mềm có thể đối phó với bất kỳ phân dạng cấu trúc dữ liệu đáng ngờ nào chỉ đơn giản là điên rồ. Tôi thậm chí không cần phải tưởng tượng mọi việc có thể tệ đến mức nào, tôi đã thực hiện kiểm tra mã nghiêm ngặt và Tôi đã thấy những điều mà các bạn chưa bao giờ mơ tới. Nhưng tôi cũng biết cấu trúc tốt trông như thế nào, и . Tôi có thể tưởng tượng một thế giới nơi Firestore có vẻ hợp lý và những người tạo ra nó sẽ nghĩ rằng họ đã làm rất tốt. Nhưng chúng ta không sống ở thế giới này.
Hỗ trợ truy vấn của FireBase kém theo bất kỳ tiêu chuẩn nào và thực tế là không tồn tại. Nó chắc chắn cần cải thiện hoặc ít nhất là sửa đổi. Nhưng Firestore cũng không tốt hơn nhiều vì nó bị giới hạn ở cùng các chỉ mục một chiều được tìm thấy trong SQL thuần túy. Nếu bạn cần các truy vấn mà mọi người chạy trên dữ liệu hỗn loạn, bạn cần tìm kiếm toàn văn bản, bộ lọc nhiều phạm vi và thứ tự tùy chỉnh do người dùng xác định. Khi kiểm tra kỹ hơn, bản thân các chức năng của SQL đơn giản quá hạn chế. Ngoài ra, truy vấn SQL duy nhất mọi người có thể chạy trong sản xuất là truy vấn nhanh. Bạn sẽ cần một giải pháp lập chỉ mục tùy chỉnh với cấu trúc dữ liệu thông minh. Đối với mọi thứ khác, ít nhất phải có sự giảm bản đồ gia tăng hoặc điều gì đó tương tự.
Nếu bạn tìm kiếm trên Google Docs để biết thông tin về điều này, hy vọng bạn sẽ được hướng tới những thứ như BigTable và BigQuery. Tuy nhiên, tất cả các giải pháp này đều đi kèm với rất nhiều thuật ngữ bán hàng dày đặc của công ty đến mức bạn sẽ nhanh chóng quay lại và bắt đầu tìm kiếm thứ khác.
Điều cuối cùng bạn muốn với cơ sở dữ liệu thời gian thực là thứ được tạo ra bởi và dành cho những người trong thang lương quản lý.
(*) Đây chỉ là trò đùa, không có chuyện đó đâu .
Như một quảng cáo
Tìm kiếm để gỡ lỗi dự án, máy chủ để phát triển và lưu trữ? Bạn chắc chắn là khách hàng của chúng tôi 🙂 Giá hàng ngày cho các máy chủ có cấu hình khác nhau, giấy phép chống DDoS và Windows đã được bao gồm trong giá.
Nguồn: www.habr.com