Phát triển Java 2.0: NoSQL

Kho dữ liệu NoSQL cũng giống như Bigtable và CouchDB là đều chuyển lên trọng tâm trong thời đại Web 2.0 bởi vì chúng có thể giải quyết các vấn đề mở rộng trên một quy mô lớn.
Nội dung trích xuất từ tài liệu:
Phát triển Java 2.0: NoSQLPhát triển Java 2.0: NoSQLô hình hóa dữ liệu Schemaless với Bigtable và Gaelyk của GroovyKho dữ liệu NoSQL cũng giống như Bigtable và CouchDB là đều chuyển lên trọngtâm trong thời đại Web 2.0 bởi vì chúng có thể giải quyết các vấn đề mở rộng trênmột quy mô lớn. Google và Facebook là hai trong số những tên tuổi lớn đã sử dụngNoSQL, và kể cả chúng tôi nữa. Kho dữ liệu Schemaless về cơ bản khác với cơ sởdữ liệu quan hệ truyền thống, nhưng việc tận dụng chúng dễ dàng hơn bạn nghĩ,đặc biệt là nếu bạn bắt đầu với mô hình miền domain chứ không phải là một quanhệ.Cơ sở dữ liệu quan hệ đã thống trị lưu trữ dữ liệu hơn 30 năm, nhưng việc cơ sở dữliệu schemaless (hay NoSQL) ngày càng phổ biến đã cho thấy rằng điều này đangdần thay đổi. Trong khi các hệ quản trị cơ sở dữ liệu (RDBMS) cung cấp một nềntảng vững chắc để lưu trữ dữ liệu trong kiến trúc client-server truyền thống, nhưngnó không dễ dàng (hay tốn ít chi phí) để mở rộng. Trong thời đại mà các ứng dụngweb có thể co giãn được như Facebook, Twitter thì điều này quả thực là một hạnchế đáng tiếc.Trong khi lựa chọn cơ sở dữ liệu quan hệ trước đó (bạn còn nhớ về cơ sở dữ liệuhướng đối tượng chứ?) đã thất bại trong việc giải quyết các vấn đề cấp bách, thìcác cơ sở dữ liệu NoSQL như Bigtable của Google hay SimpleDB của Amazon đãxuất hiện như một câu trả lời cho nhu cầu co giãn cao của các ứng dụng Web. Vềbản chất, NoSQL có thể là giải pháp cho các vấn đề khó khăn — một trong các quátrình tiến hóa của ứng dụng Web không hơn không kém, nó cũng giống như việctiến hóa tất yếu lên Web 2.0 vậy.NoSQL: Một lối tư duy mới?Khi các nhà phát triển bàn về cơ sở dữ liệu không-quan-hệ hay NoSQL, thì điềuđầu tiên mà họ thường nhắc đến là việc phải thay đổi lối tư duy. Theo tôi, thực rađiều đó còn tùy vào cách tiếp cận ban đầu của bạn về mô hình hóa dữ liệu. Nếu bạnđã quen với việc thiết kế ứng dụng theo cách mô hình hóa cấu trúc cơ sở dữ liệutrước (có nghĩa là bạn phải tìm ra các bảng và các mối quan hệ của chúng trước),sau đó việc mô hình hóa dữ liệu với kho lưu trữ schemaless như Bigtable sẽ yêucầu bạn phải xem xét lại cách làm. Tuy nhiên, nếu bạn bắt đầu thiết kế ứng dụngvới mô hình miền domain thì sẽ cảm thấy phù hợp hơn với cấu trúc schemaless củaBigtable.Kho dữ liệu không-quan-hệ không có các bảng hay khóa chính, hay thậm chí là cáckhóa ngoại (mặc dù cả hai loại khóa này đều hiện diện trong một dạng nới lỏng).Vì thế bạn sẽ thất vọng nếu cố gắng áp dụng mô hình hóa quan hệ như là nền tảngcho mô hình hóa dữ liệu trong cơ sở dữ liệu NoSQL. Bắt đầu từ một mô hình miềndomain giúp đơn giản hóa nhiều thứ; trong thực tế, tôi đã thấy sự linh hoạt của cấutrúc schemaless dưới mô hình miền domain chính là khả năng làm mới.Sự phức tạp của việc chuyển từ một mô hình dữ liệu quan hệ đến một mô hình dữliệu schemaless phụ thuộc vào cách tiếp cận của bạn: đó là bạn bắt đầu từ một quanhệ hay một thiết kế dựa trên miền domain. Khi bạn di chuyển sang kho dữ liệu nhưCouchDB hoặc Bigtable, bạn sẽ thật sự loại bỏ được những hạn chế của nền tảnglâu đời như Hibernate (ít nhất là từ bây giờ). Mặt khác, hiệu ứng green-pasture sẽgiúp bạn tự xây dựng nó. Và trong bài này, bạn sẽ tìm hiểu sâu về kho dữ liệuschemaless.Các thực thể và mối quan hệMột kho dữ liệu schemaless cung cấp cho bạn sự linh hoạt để thiết kế mô hìnhmiền domain với các đối tượng đầu tiên (một thứ gì đó mới hơn, các frameworknhư Grails tạo thuận lợi một cách tự động). Công việc của bạn là tiến về phía trướcsau đó map miền domain của bạn với kho dữ liệu, điều này rất đễ dàng đối vớiGoogle App Engine.Trong bài Phát triển Java 2.0: Gaelyk cho Google App Engine, tôi đã giới thiệuvề Gaelyk, một framework dựa trên Groovy giúp làm việc với kho dữ liệu củaGoogle. Phần lớn bài viết tập trung vào việc thúc đẩy các đối tượng Google Entity.Ví dụ sau đây (trích từ bài viết đó) cho thấy cách các thực thể đối tượng làm việctrong Gaelyk.Liệt kê 1. Gán đối tượng vào thực thểdef ticket = new Entity(ticket)ticket.officer = params.officerticket.license = params.plateticket.issuseDate = offensedateticket.location = params.locationticket.notes = params.notesticket.offense = params.offenseThiết kế bởi đối tượngCác mô hình đối tượng trong thiết kế cơ sở dữ liệu cho thấy trong khuôn khổ ứngdụng Web hiện đại như Grails và Ruby on Rails, nhấn mạnh việc thiết kế mô hìnhđối tượng và xử lý việc tạo giản đồ cơ sở dữ liệu cho bạn.Phương pháp này phản đối các tiến trình dai dẳng, nhưng ta sẽ dễ dàng thấy nó trởnên tẻ nhạt nếu bạn sử dụng nhiếu thực thể vé — ví dụ, nếu bạn đã tạo ra (hay tìmkiếm) chúng trong các servlet khác nhau. Một servlet (hay Groovlet) xử lý cácnhiệm vụ của bạn có thể loại bỏ đi một số gánh nặng. Một lựa chọn tự nhiên hơn— như tôi sẽ chứng minh — sẽ là một mô hình đối tượng Ticket.Trở lại với Race (đường đua)Thay vì tạo lại các ticket ví dụ từ phần giới thiệu Gaelyk, tôi sẽ giữ mọi thứ mớimẻ và sử dụng một chủ đề xuyên suốt bài này để xây dựng một ứng dụng chứngminh các kỹ thuật mà tôi đã thảo luận..Sơ đồ nhiều-nhiều ở Hình 1 cho thấy, một Race có nhiều Runners và một Runnercó thể thuộc về nhiều Races.Figure 1. Race and runnersNếu tôi được sử dụng một cấu trúc bảng quan hệ để thiết kế mối quan hệ này thì tôicần ít nhất ba bảng: bảng thứ ba chính là bảng nối liên kết một mối quan hệ nhiều-nhiều. Tôi rất vui vì không bị ràng buộc với mô hình dữ liệu quan hệ. Thay vào đó,tôi sẽ sử dụng Gaelyk (và mã Groovy) để lập bản đồ quan hệ nhiều-nhiều này đểtrừu tượng Bigtable của Google cho Google App Engine. Thực tế là Gaelyk chophép một Entity được đối xử như một Map để giúp quá mình trở nên đơn giản.Mở rộng quy mô với ShardsSharding là một dạng của phân vùng sao chép cấu trúc bảng qua các nút nhưngphân chia hợp lý dữ liệu của chúng. Ví dụ, một nút có thể có tất cả các dữ liệu liênquan đến ...