Phát triển Java 2.0: NoSQL
ô hình hóa dữ liệu Schemaless với Bigtable và Gaelyk của Groovy
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. Google và Facebook là hai trong số những tên tuổi lớn đã sử dụng
NoSQL, 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 quan
hệ.
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 đang
dần thay đổi. Trong khi các hệ quản trị cơ sở dữ liệu (RDBMS) cung cấp một nền
tảng vững chắc để lưu trữ dữ liệu trong kiến trúc client-server truyền thống, nhưng
nó không dễ dàng (hay tốn ít chi phí) để mở rộng. Trong thời đại mà các ứng dụng
web có thể co giãn được như Facebook, Twitter thì điều này quả thực là một hạn
chế đá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ệu
hướ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ệc
tiế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ệu
trướ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êu
cầ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ụng
vớ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ủa
Bigtable.
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ác
khó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ảng
cho 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ền
domain 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ấu
trú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 quan
hệ 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ảng
lâ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ệu
schemaless.
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ình
miền domain với các đối tượng đầu tiên (một thứ gì đó mới hơn, các framework
như 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ước
sau đó map miền domain của bạn với kho dữ liệu, điều này rất đễ dàng đối với
Google App Engine.
Trong bài "Phát triển Java 2.0: Gaelyk cho Google App Engine," tôi đã giới thiệu
về Gaelyk, một framework dựa trên Groovy giúp làm việc với kho dữ liệu của
Google. 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ệc
trong Gaelyk.
Liệt kê 1. Gán đối tượng vào thực thể
def ticket = new Entity("ticket")
ticket.officer = params.officer
ticket.license = params.plate
ticket.issuseDate = offensedate
ticket.location = params.location
ticket.notes = params.notes
ticket.offense = params.offense
Thiết kế bởi đối tượng
Các mô hình đối tượng trong thiết kế cơ sở dữ liệu cho thấy trong khuôn khổ ứng
dụ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ìm
kiếm) chúng trong các servlet khác nhau. Một servlet (hay Groovlet) xử lý các
nhiệ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.
