3.4. Datastore
3.4.1. Giới thiệu
GAE Datastore là một đối tượng lưu trữ phi lược đồ, cung cấp một kho lưu trữ mạnh mẽ và có khả năng mở rộng cao cho các trình ứng dụng web với các đặc điểm sau:
- Không có thời gian chết. - Giao dịch nguyên tử.
- Tính sẵn sàng cao cho thao tác đọc và viết. - Tính nhất quán cao.
Datastore lưu các đối tượng dữ liệu dưới dạng các thực thể (entities), mỗi một thực thể có thể có một hoặc nhiều thuộc tính (properties), mỗi thuộc tính có thể có một kiểu dữ liệu (data types), các kiểu dữ liệu có thể là một chuỗi (string), các số (số nguyên, số thực …) hoặc một tham chiếu tới các thực thể khác. Mỗi thực thể được xác định bởi một kiểu (kind), để phân loại thực thể theo mục đích của các truy vấn, và một khóa để xác định duy nhất một thực thể trong kiểu của nó.
Datastore có thể thực hiện nhiều thao tác trong một phiên giao dịch (transaction). Một giao tác không thành công trừ khi tất cả các thao tác của nó thành công, nếu một trong các thao tác gặp lỗi, giao tác tự động thực hiện lại. Điều này thực sự hữu ích đối với các ứng dụng web phân tán, khi rất nhiều người dùng có thể truy cập và thao tác trên cùng một dữ liệu trong cùng một khoảng thời gian.
Một trong những thế mạnh của Datastore là hiệu suất làm việc của nó hoàn toàn độc lập với số lượng thực thể mà trình ứng dụng có. Vì vậy, mỗi thực thể của mỗi trình ứng dụng App Engine được lưu trữ trong một bảng singleBigtable. Vì vậy, khi nói đến truy vấn, tất cả các truy vấn được thực hiện với chi phí thực thi là như nhau: Chi phí thực hiện một truy vấn sẽ tỷ lệ thuận với số kết quả trả về của truy vấn đó.
GAE Datastore được thiết kế dựa trên Bigtable, vì vậy cũng như Bigtable, Datastore không phải là một CSDL quan hệ. Một câu hỏi đặt ra là làm thể nào để chúng ta thiết kế một lược đồ CSDL cho ứng dụng sử dụng sử dụng hệ thống CSDL này?
3.4.2. Những ưu điểm so với CSDL truyền thống
Không giống như CSDL quan hệ truyền thống, App Engine Datastore sử dụng kiến trúc phân tán để tự động quản lý việc phân chia các tập dữ liệu lớn. Trong khi giao diện của Datastore có rất nhiều điểm tương đồng với CSDL truyền thống, thì sự khác biệt ở đây chính là sự miêu tả mối quan hệ giữa các đối tượng dữ liệu. Các thực thể của cùng một loại có thể có các thuộc tính khác nhau, còn các thực thể khác nhau có thể có các thuộc tính cùng tên nhưng có kiểu giá trị khác nhau.
Datastore khác với CSDL quan hệ truyền thống ở những đặc điểm sau:
- Do tất cả các truy vấn trên App Engine được phục vụ bởi các chỉ mục được xây dựng trước nên các loại truy vấn được thực hiện có nhiều hạn chế hơn so với CSDL truyền thống. Cụ thế, một số truy vấn sau không được hỗ trợ:
+ Thao tác join.
+ Thao tác lọc khác nhau trên nhiều thuộc tính.
+ Lọc trên những dữ liệu là kết quả của các truy vấn khác.
- Không giống CSDL quan hệ truyền thống, Datastore không yêu cầu các thực thể của cùng kiểu phải nhất quán với tập các thuộc tính.
3.4.3. Thực thể, thuộc tính và khóa:
3.4.3.1. Loại và định danh:
Mỗi thực thể của Datastore thuộc về một loại riêng biệt dùng để phân biệt các thực thể dựa theo mục đích của truy vấn. Trong Java Datastore API, loại của thực thể phải được chỉ định khi nó được tạo ra.
Ngoài việc mỗi thực thể phải thuộc về một loại nào đó, nó còn phải có một định danh, được chỉ định khi thực thể đó được tạo ra. Vì nó là một phần khóa của thực thể, định danh sẽ gắn liền với thực thể vĩnh viễn không thay đổi được. Định danh có thể được chỉ định bằng một trong 2 cách:
- Trình ứng dụng có thể tự chỉ định tên khóa làm định danh.
- Datastore có thể tự động chỉ định định danh cho các thực thể bằng một số ID
3.4.3.2. Giao tác và nhóm các thực thể
Mọi nỗ lực để tạo, cập nhật hoặc xóa các thực thể được diễn ra trong ngữ cảnh của một giao tác. Một giao tác có thể gồm nhiều các thao tác như vậy. Để duy trì tính nhất quán của dữ liệu, một giao tác phải đảm bảo rằng tất cả các thao tác như vậy trong Datastore tạo nên một đơn vị, điều đó có nghĩa là, chỉ cần một thao tác có lỗi, thì không thao tác nào trong giao tác đó được thực hiện.
Một giao tác đơn có thể được thực hiện trên nhiều thực thể, miễn là các thực thể đó được phát triển từ một ancestor. Những thực thể như vậy được gọi là thuộc về một nhóm thực thể. Mỗi khi thiết kế mô hình dữ liệu, cần phải xác định rõ các thực thể nào cùng được thực hiện trong một giao tác. Sau đó, khi tạo các thực thể, đặt chúng vào cùng một nhóm thực thể và báo cho ancestor chung biết. Việc thông báo đó sẽ giúp App Engine biết các thực thể sẽ được cập nhật cùng nhau, do vậy sẽ có cách lưu trữ nhóm các thực thể này một cách thích hợp.
3.4.3.3. Thuộc tính và kiểu dữ liệu
Các giá trị của dữ liệu liên quan đến thực thể sẽ bao gồm một hoặc nhiều thuộc tính. Mỗi thuộc tính sẽ có tên và một hoặc nhiều giá trị. Mỗi thuộc tính có thể có nhiều
hơn một giá trị, và hai thực thể có thể có các kiểu giá trị khác nhau cho cùng một thuộc tính.
Bảng 3.3 sẽ liệt kê các kiểu dữ liệu thường dùng cho các thuộc tính trong java:
Value type Java type(s) Sort order
Integer short int long java.lang.Short java.lang.Integer java.lang.Long Numeric Floating-point number float double java.lang.Float java.lang.Double Numeric Boolean boolean java.lang.Boolean false < true
Text string (short) java.lang.String Unicode
Text string (long) com.google.appengine.api.datastore.Text None Byte string (short) com.google.appengine.api.datastore.ShortBlob Byte order Byte string (long) com.google.appengine.api.datastore.Blob None
Date and time java.util.Date Chronologic
al
Geographical point com.google.appengine.api.datastore.GeoPt By latitude, then
longitude Postal address com.google.appengine.api.datastore.PostalAdd
ress
Unicode
Telephone number com.google.appengine.api.datastore.PhoneNu mber
Unicode
Email address com.google.appengine.api.datastore.Email Unicode Google Accounts com.google.appengine.api.users.User Email
user address in Unicode order Instant messaging handle com.google.appengine.api.datastore.IMHandle Unicode
Link com.google.appengine.api.datastore.Link Unicode Category com.google.appengine.api.datastore.Category Unicode Rating com.google.appengine.api.datastore.Rating Numeric Datastore key com.google.appengine.api.datastore.Key
or the referenced object (as a child)
By path
elements
(kind, identifier, kind, identifier, ...)
Blobstore key com.google.appengine.api.blobstore.BlobKey Byte order Embedded entity com.google.appengine.api.datastore.Embedded
Entity
None
Null null None
Bảng 3. 3. Các kiểu dữ liệu của Datastore được hỗ trợ trong Java
3.4.4. Truy vấn và chỉ mục
Để có thể lấy các thực thể từ Datastore trực tiếp bằng khóa của chúng, trình ứng dụng có thể thực hiện các truy vấn để lấy chúng bằng giá trị của các thuộc tính. Truy vấn sẽ được thực hiện trên các thực thể của một loại nhất định. Nó có thể lọc trên các khóa, các giá trị của thuộc tính và có thể trả kết quả về là không có thực thể nào hoặc nhiều thực thể. Một truy vấn cũng có thể chỉ rõ trình tự sắp xếp nào đó để sắp xếp kết quả theo một trình tự xác định các giá trị của thuộc tính. Các kết quả trả về bao gồm tất cả các thực thể có ít nhất một giá trị cho các thuộc tính thỏa mãn điều kiện lọc hoặc sắp xếp.
Một truy vấn điển hình thường gồm các thành phần sau: - Loại của thực thể mà truy vấn thực hiện.
- Một hoặc nhiều bộ lọc dựa trên khóa, giá trị các thuộc tính của thực thể - Một hoặc nhiều trình tự sắp xếp để sắp xếp các kết quả trả về.
Khi thực hiện, các truy vấn sẽ tìm trên tất cả các thuộc tính của một loại cho trước thỏa mãn tất cả các điều kiện lọc và sắp xếp theo trình tự nhất định
Kết quả của tất cả các truy vấn trên Datastore được tính toán bằng việc sử dụng một hoặc nhiều chỉ mục – là bảng có chứa các thực thể được sắp xếp theo một trình tự nhất định các thuộc tính của các chỉ mục. Các chỉ mục được cập nhật dần để phản ánh mọi thay đổi mà trình ứng dụng thực hiện trên các thực thể của nó. Do vậy các kết quả của các truy vấn có được ngay lập tức mà không cần có thêm bất kỳ thao tác tính toán nào.
3.4.5. Các giao tác
Bất kỳ các cố gắng để tạo mới, cập nhật, hoặc xóa các thực thể được diễn ra trong ngữ cảnh của một giao tác. Một giao tác đơn có thể bao gồm một số lượng bất kỳ các thao tác. Để duy trì tính nhất quán của dữ liệu, một giao tác đảm bảo rằng, tất cả các thao tác của nó thực thi trên Datastore như một đơn vị thực hiện, điều đó có nghĩa là nếu một trong các thao tác gặp lỗi, thì toàn bộ giao tác sẽ bị hủy.
Nhiều hành động có thể được thực hiện trên cùng một giao tác. Ví dụ như, để tăng giá trị của một biến đếm, ta cần thực hiện lần lượt: (1): đọc giá trị của biến đếm; (2): tính toán giá trị mới; (3): lưu giá trị mới tính được. Nếu không sử dụng giao tác, rất có thể sẽ có một tiến trình khác để tăng giá trị của biến đếm trong khoảng thời gian đọc và ghi dữ liệu. Điều đó có thể là nguyên nhân dẫn đến việc trình ứng dụng ghi đè nên dữ liệu đã được cập nhật. Thực hiện việc đọc, tính toán và ghi dữ liệu trên một giao tác đơn sẽ đảm bảo được rằng không có một tiến trình nào khác có thể gây “nhiễu” việc tăng giá trị
3.5. Ứng dụng thử nghiệm dịch vụ LBS trên nền tảng kiến trúc CSDL Datastore
3.5.1. Đặt vấn đề
Như đã trình bày ở chương 1, các dịch vụ LBS được xây dựng nhằm cung cấp các dịch vụ tiện ích hỗ trợ người dùng. Tuy nhiên, việc duy trì một hệ thống dịch vụ LBS hoàn chỉnh và đầy đủ đòi hỏi các nhà cung cấp dịch vụ, các công ty phải đầu tư một khoản chi phí lớn, và điều này đôi khi không đem lại các lợi ích kinh doanh mong muốn cho các nhà cung cấp dịch vụ, các công ty, đặc biệt là các nhà cung cấp, công ty có qui mô vừa và nhỏ.
Với việc ra đời của công nghệ điện toán đám mây, cùng với sự phát triển của mạng lưới hạ tầng viễn thông, các ưu điểm của công nghệ điện toán mây như khả năng đáp ứng cao (99,99% thời gian), khả năng co giãn (thay đổi cấu hình hệ thống), và chi phí thấp hơn việc duy trì một hệ thống dịch vụ tiện ích riêng biệt đã mở ra một hướng phát triển dịch vụ mới cho các nhà cung cấp dịch vụ LBS, các công ty muốn phát triển
các ứng dụng LBS riêng đó là xây dựng dịch vụ dựa trên vị trí trên nền tảng điện toán đám mây.
Dữ liệu và việc lưu trữ dữ liệu như thế nào trong điện toán đám mây là một vấn đề rất quan trọng. Bài toán đặt ra là: “Xây dựng CSDL thử nghiệm trong dịch vụ dựa trên vị trí trên nền tảng điện toán đám mây của Google cho bài toán tìm kiếm các điểm đặt cột ATM xung quanh một vị trí trên bản đồ”
3.5.2. Lựa chọn công cụ triển khai
Như đã trình bày, có rất nhiều các nhà cung cấp dịch vụ điện toán đám mây như IBM, Google, Microsoft, … việc tìm ra một nhà cung cấp để triển khai bài toán là một việc tương đối khó khăn. Tuy nhiên, dựa vào những đặc điểm đã tìm hiều được trong chương II, bài toán sẽ được thử nghiệm bằng ngôn ngữ Java nhờ công cụ Eclipse dựa trên nền tảng Google App Engine.
3.5.3. Thu thập dữ liệu
Việc thu thập dữ liệu nhằm xác định các thông số cần thiết cho thực thể (các cây ATM) theo cấu trúc xác định trước. Đặc biệt dữ liệu quan trọng nhất là vị trí địa lý của mỗi thực thể (lat, lon).
Đầu ra thu được của công việc này là một bảng chứa các thông số cần thiết của tất cả các thực thể.
3.5.4. Số hóa dữ liệu dựa trên Google App Engine
3.5.4.1. Thiết kế cơ sở dữ liệu
tblATM
Key Property Data type
PK ID String Add Bank Lat Lon String String String String