Cách giải thích lịch sự của "NoSQL" đã trở thành Not Only SQL . Nếu bạn có dữ liệu thực sự là quan hệ hoặc nếu chức năng của bạn phụ thuộc vào những thứ như liên kết và ACIDity, thì bạn nên lưu trữ dữ liệu đó theo cách quan hệ. Trong bài đăng này, tôi sẽ giải thích cách tôi sử dụng MySQL cùng với hai Các kho dữ liệu NoSQL. Lưu trữ dữ liệu quy mô web, hiện đại là tất cả về việc hiểu cách chọn (các) công cụ tốt nhất cho (các) công việc.
Điều đó nói rằng, NoSQL thực sự là một phản ứng đối với thực tế là phương pháp quan hệ và cách suy nghĩ đã được áp dụng cho các vấn đề mà nó thực sự không phù hợp lắm (điển hình là các bảng lớn với hàng chục triệu hàng trở lên). Khi các bảng trở nên lớn như vậy, thì "phương pháp hay nhất" điển hình của SQL là tạo shard theo cách thủ công dữ liệu - tức là đưa các bản ghi từ 1 đến 10.000.000 vào bảng A, 10.000.001 đến 20.000.001 trong bảng B, v.v. Sau đó, thường trong lớp mô hình ứng dụng, các tra cứu được thực hiện theo sơ đồ này. Đây được gọi là application-aware mở rộng quy mô. Nó tốn nhiều thời gian và dễ xảy ra lỗi, nhưng để mở rộng quy mô trong khi duy trì MySQL cho kho lưu trữ bảng dài, nó trở thành MO tiêu chuẩn ít nhiều. Với tôi, NoSQL đại diện cho application-unaware thay thế.
Khóa-Giá trị
Khi tôi có một nguyên mẫu MySQL bắt đầu quá lớn so với lợi ích của nó, cá nhân tôi đã chuyển càng nhiều dữ liệu càng tốt sang Membase nhanh như chớp , hoạt động tốt hơn Memcached và thêm tính bền bỉ. Membase là một kho lưu trữ khóa-giá trị phân tán có quy mô tuyến tính nhiều hơn hoặc ít hơn (ví dụ:Zynga sử dụng nó để xử lý nửa triệu hoạt động mỗi giây) bằng cách thêm nhiều máy chủ hàng hóa hơn vào một cụm - do đó, điều đó thật tuyệt vời phù hợp với thời đại đám mây của Amazon EC2 , Joyent , v.v.
Ai cũng biết rằng các cửa hàng giá trị khóa được phân phối là cách tốt nhất để có được quy mô tuyến tính, khổng lồ. Điểm yếu của khóa-giá trị là khả năng truy vấn và lập chỉ mục. Nhưng ngay cả trong thế giới quan hệ, phương pháp tốt nhất để có khả năng mở rộng là giảm tải càng nhiều càng tốt lên các máy chủ ứng dụng, thực hiện tham gia vào bộ nhớ trên các máy chủ ứng dụng hàng hóa thay vì yêu cầu cụm RDB trung tâm xử lý tất cả logic đó. Vì simple select cộng với application logic thực sự là cách tốt nhất để đạt được quy mô lớn ngay cả trên MySQL, sự chuyển đổi sang thứ gì đó giống như Membase (hoặc các đối thủ cạnh tranh của nó như Riak
) không thực sự quá tệ.
Cửa hàng tài liệu
Đôi khi - mặc dù tôi sẽ tranh luận ít thường xuyên hơn nhiều người nghĩ - thiết kế của một ứng dụng vốn dĩ yêu cầu các chỉ số phụ, khả năng truy vấn phạm vi, v.v. Cách tiếp cận NoSQL cho điều này là thông qua document store như MongoDB
. Giống như Membase, Mongo rất tốt trong một số lĩnh vực mà cơ sở dữ liệu quan hệ đặc biệt yếu, như application-unaware chia tỷ lệ, auto-sharding và maintaining flat response times even as dataset size balloons . Nó chậm hơn đáng kể so với Membase và phức tạp hơn một chút để thực hiện quy mô ngang thuần túy, nhưng lợi ích là nó có khả năng truy vấn cao. Bạn có thể truy vấn về các tham số và phạm vi trong thời gian thực hoặc bạn có thể sử dụng Map / Reduce để thực hiện các hoạt động hàng loạt phức tạp trên các tập dữ liệu thực sự khổng lồ.
Trong cùng một dự án mà tôi đã đề cập ở trên, sử dụng Membase để cung cấp hàng tấn dữ liệu trình phát trực tiếp, chúng tôi sử dụng MongoDB để lưu trữ dữ liệu phân tích / chỉ số, đây thực sự là nơi MongoDB tỏa sáng.
Tại sao phải giữ mọi thứ trong SQL
Tôi đã đề cập ngắn gọn về thực tế là thông tin 'thực sự quan hệ' nên ở trong cơ sở dữ liệu quan hệ. Như nhà bình luận Dan K. đã chỉ ra, tôi đã bỏ lỡ phần thảo luận về những bất lợi của việc rời bỏ RDBMS, hoặc ít nhất là rời khỏi nó hoàn toàn.
Đầu tiên, có chính SQL. SQL nổi tiếng và đã là một tiêu chuẩn công nghiệp trong một thời gian dài. Một số cơ sở dữ liệu "NoSQL" như App Engine
của Google Kho dữ liệu (được xây dựng trên Big Table) triển khai ngôn ngữ giống SQL của riêng họ (gọi một cách dễ thương là GQL của Google cho Google Query Language ). MongoDB có một cách tiếp cận mới cho vấn đề truy vấn với đối tượng truy vấn JSON
thú vị của nó . Tuy nhiên, bản thân SQL là một công cụ mạnh mẽ để lấy thông tin ra khỏi dữ liệu, đây thường là điểm bắt đầu của toàn bộ cơ sở dữ liệu.
Lý do quan trọng nhất để ở lại với RDBMS là ACID
hoặc Atomicity, Consistency, Isolation, Durability . Tôi sẽ không băm lại trạng thái của Acid-NoSQL, vì nó được giải quyết tốt trong bài đăng này
trên SO. Chỉ cần nói rằng, có một lý do hợp lý RDBMS của Oracle
có một thị trường khổng lồ như vậy sẽ không đi đến đâu: một số dữ liệu cần tuân thủ ACID thuần túy . Nếu dữ liệu của bạn có (và nếu có, bạn có thể biết rõ về sự thật đó), thì cơ sở dữ liệu của bạn cũng vậy. Giữ pH
đó thấp!
Chỉnh sửa: Xem bài đăng của Aaronaught tại đây. Anh ấy đại diện cho quan điểm giữa doanh nghiệp với doanh nghiệp tốt hơn nhiều so với tôi có thể, một phần vì tôi đã dành toàn bộ sự nghiệp của mình trong không gian tiêu dùng.
