LỜI CAM ĐOAN
Tôi Đào Anh Khoa cam kết luận văn thạc sĩ là công trình nghiên cứu của bản thân tôi
dưới sự hướng dẫn của TS. Nguyễn Nhật Quang.
Các kết quả nêu trong luận văn thạc sĩ là trung thực, không phải là sao chép toàn văn
của bất kỳ công trình nào khác.
Hà Nội, ngày 22 tháng 09 năm 2014
Tác giả luận văn

Đào Anh Khoa
Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của luận văn và cho phép
bảo vệ:

Hà Nội, ngày 22 tháng 09 năm 2014
Giáo viên hướng dẫn

TS. Nguyễn Nhật Quang


MỤC LỤC
MỤC LỤC ........................................................................................................................ 1
DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ ................................................... 2
DANH MỤC CÁC BẢNG............................................................................................... 2
DANH SÁCH CÁC HÌNH .............................................................................................. 2
MỞ ĐẦU .......................................................................................................................... 5
1 Đặt vấn đề ................................................................................................................. 7
2 Các công nghệ sử dụng ........................................................................................... 11
2.1 RESTful Web Service ....................................................................................... 11
2.2 Ruby On Rails .................................................................................................. 15
2.3 Memcached ....................................................................................................... 16
2.4 Redis ................................................................................................................. 18

2.5 ElastichSearch .................................................................................................. 20
2.6 Amazon Web Services (AWS) .......................................................................... 21
2.7 Google geocoding ............................................................................................. 23
2.8 Sidekiq .............................................................................................................. 24
3 Phân tích, thiết kế hệ thống..................................................................................... 26
3.1 Tổng quan về các chức năng của hệ thống ....................................................... 26
3.1.1 Chức năng quản trị: .................................................................................... 26
3.1.2 Các chức năng chính của mạng xã hội ...................................................... 27
3.2 Phân tích, thiết kế hệ thống .............................................................................. 31
3.2.1 Khung nhìn theo lược đồ trường hợp sử dụng (Use-case diagram) .......... 31
3.2.2 Khung nhìn theo lược đồ hoạt động (Activity diagram) ........................... 34
3.2.3 Khung nhìn theo lược đồ chuỗi hành động (Sequence diagram) .............. 39
3.2.4 Thiết kế cơ sở dữ liệu ................................................................................ 71
3.2.5 Sơ đồ các package của hệ thống ................................................................ 72
4 Cài đặt thư viện ....................................................................................................... 73
4.1.1 KdaGem ..................................................................................................... 74
4.1.2 Kcache ....................................................................................................... 75
4.1.3 Mredis ........................................................................................................ 76
5 Cài đặt hệ thống mạng xã hội chia sẻ địa điểm ...................................................... 80
5.1 Kiến trúc hệ thống ............................................................................................ 80
5.2 Giao diện chương trình của các chức năng chính trong hệ thống .................... 82
6 Kết luận ................................................................................................................... 96
7 Tài liệu tham khảo .................................................................................................. 97
1


8

PHỤ LỤC ............................................................................................................... 98


DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ
Viết tắt

Thuật ngữ

Ghi chú

CSDL

Cơ sở dữ liệu

AWS

Amazon Web Service

Dịch vụ đám mây của Amazon

S3

Simple Storage Service

Dịch vụ lưu trữ đám mây của
Amazon

MXH

Mạng xã hội

DANH MỤC CÁC BẢNG
Bảng 4.1 Các phương thức trong thư viện KdaGem...................................................... 75


DANH SÁCH CÁC HÌNH
Hình 2.1 Hình minh họa sử dụng các phương thức HTTP trong RESTful.................... 12
Hình 2.2 Thiết kế trạng thái ........................................................................................... 12
Hình 2.3 Thiết kế phi trạng thái ..................................................................................... 13
Hình 2.4: Sử dụng Memcached trong đệm dữ liệu khi truy cập cở sở dữ liệu .............. 17
Hình 2.5: Kiến trúc hệ thống khi sử dụng Amazon Cloudfront ..................................... 23
Hình 3.1 Biều đồ Use-case chức năng quản lý theo hình ảnh ....................................... 31
Hình 3.2 Biểu đồ Use-case chức năng quản lý theo địa điểm ....................................... 32
Hình 3.3 Biều đồ Use-case người sử dụng..................................................................... 33
Hình 3.4 Biểu đồ activity của quá trình đăng kí ............................................................ 34
Hình 3.5 Biểu đồ activity quá trình đăng nhập .............................................................. 35

2


Hình 3.6 Biểu đồ activity đăng ảnh mới ........................................................................ 36
Hình 3.7 Biểu đồ activity kiểm tra ảnh có được vào danh sách phô biến không? ......... 38
Hình 3.8 Biểu đồ sequence của tiến trình bình luận về ảnh ........................................... 39
Hình 3.9 Biểu đồ sequence của tiến trình xóa bình luận về ảnh .................................... 41
Hình 3.10 Biểu đồ sequence tiến trình thích ảnh ........................................................... 42
Hình 3.11 Biểu đồ sequence tiến trình thực hiện sưu tập ảnh ........................................ 44
Hình 3.12 Biểu đồ sequence tiến trình đưa ảnh vào thư mục sưu tập............................ 46
Hình 3.13 Biểu đồ sequence tiến trình xóa ảnh khỏi thư mục sưu tập .......................... 47
Hình 3.14 Biểu đồ sequence tiến trình xóa ảnh ............................................................. 48
Hình 3.15 Biểu đồ sequence tiến trình báo cáo sai phạm về ảnh................................... 49
Hình 3.16 Biểu đồ sequence tiến trình tìm kiếm ảnh theo các tiêu chí khác nhau ........ 50
Hình 3.17 Biểu đồ sequence tiến trình lấy danh sách ảnh của người dùng được theo dõi
bởi người dùng hiện tại .................................................................................................. 51
Hình 3.18 Biểu đồ sequence tiến trình lấy danh sách ảnh được sưu tập........................ 52

Hình 3.19 Biểu đồ sequence tiến trình lấy danh sách các ảnh popular (ảnh đạt số point
lớn hơn 1 số nhất định trong vòng 3 ngày) .................................................................... 53
Hình 3.20 Biểu đồ sequence tiến trình lấy danh sách các ảnh mới nhất ........................ 54
Hình 3.21 Biểu đồ Sequence tìm kiếm ảnh trong phạm vi và được sắp xếp theo thời
gian hoặc độ phổ biến .................................................................................................... 55
Hình 3.22 Biểu đồ Sequence tìm kiếm địa điểm theo từ khóa tên thành phố, tên bang,
tên nước,... ...................................................................................................................... 56
Hình 3.23 Biểu đồ Sequence lấy danh sách ảnh gắn với một địa điểm ......................... 57
Hình 3.24 Biểu đồ Sequence lấy ra danh sách địa điểm đẹp (landmark) trong phạm vi
nhất định ......................................................................................................................... 58
Hình 3.25 Biểu đồ sequence tiến trình gửi đánh giá về địa điểm đẹp (landmark)......... 59
Hình 3.26 Biểu đồ sequence tiến trình tạo kế hoạch đến địa điểm bằng ảnh ................ 60
Hình 3.27 Biểu đồ sequence tiến trình lấy danh sách kế hoạch đã được tạo bởi người
dùng. ............................................................................................................................... 61
Hình 3.28: Biểu đồ Sequence lấy danh sách các tin tức của user .................................. 62
Hình 3.29 Biểu đồ Sequence tìm kiếm bạn bè (theo tên, username, email) .................. 63
Hình 3.30 Biểu đồ sequence tiến trình đăng kí / hủy đăng kí theo dõi người dùng ...... 64
Hình 3.31 Biểu đồ sequence tiến trình lấy danh sách các người dùng theo dõi người
dùng hiện tại ................................................................................................................... 65
Hình 3.32 Biểu đồ sequence tiến trình lấy danh sách các người dùng được theo dõi bởi
người dùng hiện tại......................................................................................................... 66

3


Hình 3.33 Biểu đồ sequence tiến trình lấy thông tin đăng kí nhận thông báo ............... 67
Hình 3.34 Biểu đồ sequence tiến trình chỉnh sửa đăng kí nhận thông báo .................... 68
Hình 3.35 Biểu đồ sequence tiến trình lấy thông tin cá nhân của người dùng .............. 69
Hình 3.36: Biểu đồ sequence tiến trình chỉnh sửa thông tin cá nhân............................. 70
Hình 3.37 Sơ đồ thiết kế cơ sở dữ liệu hệ thống ............................................................ 71

Hình 3.38 Biểu đồ các package của hệ thống ................................................................ 72
Hình 4.1 Danh sách các thư viện xây dựng được trên RubyGems ................................ 73
Hình 5.1 Kiến trúc hệ thống ........................................................................................... 80
Hình 5.2 Của sổ màn hình đăng kí và đăng nhập .......................................................... 82
Hình 5.3 Thanh công cụ của người dùng sau khi đăng nhập ......................................... 83
Hình 5.4 Cửa sổ hiển thị tin tức thông báo cho người dùng .......................................... 83
Hình 5.5 Giao diện trang hiển thị dành cho người dùng ................................................ 84
Hình 5.6 Sơ đồ quá trình đăng ảnh mới ......................................................................... 85
Hình 5.7 Giao diện trang cài đặt thông tin cá nhân của người dùng.............................. 86
Hình 5.8 Màn hình chi tiết thông tin về ảnh .................................................................. 87
Hình 5.9 Màn hình danh sách ảnh phổ biến ................................................................... 88
Hình 5.10 Màn hình thực hiện sưu tập ảnh .................................................................... 89
Hình 5.11 Màn hình kết quả sau khi thực hiện sưu tập, thích ảnh ................................. 89
Hình 5.12 Màn hình danh sách các bộ sưu tập (dạng lưới) ........................................... 90
Hình 5.13 Màn hình danh sách các bộ sưu tập (dạng bản đồ) ....................................... 91
Hình 5.14 Màn hình chi tiết thông tin về một bộ sưu tập .............................................. 91
Hình 5.15 Màn hình tạo mới kế hoạch ........................................................................... 92
Hình 5.16 Màn hình chi tiết thông tin về địa điểm ........................................................ 93
Hình 5.17 Màn hình tìm kiếm người dùng..................................................................... 94
Hình 5.18 Màn hình hiển thị ảnh, và địa điểm đẹp dưới dạng bản đồ ........................... 94
Hình 5.19 Màn hình tìm kiếm nâng cao ảnh .................................................................. 95
Hình 8.1 Thông tin thư viện KdaGem ........................................................................... 98
Hình 8.2 Thông tin thư viện Kcache .............................................................................. 99
Hình 8.3 Thông tin thư viện Mredis............................................................................. 100

4


MỞ ĐẦU
Trong thời đại hiện nay, mạng xã hội đã trở thành một phần rất phổ biến trong cuộc

sống. Mạng xã hội là nơi mỗi chúng ta có thể chia sẻ cảm xúc, học hỏi, giao lưu, kết
bạn, tìm kiếm thông tin, chia sẽ niềm đam mê, sở thích … Facebook hay Twitter được
biết đến như 2 mạng xã hội nổi tiếng và phổ biến nhất, bên cạnh đó là rất nhiều các
mạng xã hội khác.
Khác với các trang mạng xã hội lớn dùng cho nhiều mục đích (multi-purpose social
network) như Facebook, Twitter là nơi cho tất cả mọi người chia sẻ về rất nhiều lĩnh
vực trong cuộc sống. Mạng xã hội tôi được phát triển trong luận văn nàyhướng tới đối
tượng người dùng cụ thể là những người đi du lịch cần tìm địa điểm đẹp và những
người thích chụp ảnh muốn tìm đến nơi có thể chụp ra những bức ảnh đẹp – một mạng
xã hội chia sẻ địa điểm.
Một vấn đề nữa là các tính năng của một mạng xã hội cần được cập nhật liên tục để
thu hút người dung nên cần chương trình có tính mềm dẻo và khả năng mở rộng cao.
Chính vì vậy tôi chọn Ruby on Rails () – một ngôn ngữ lập trình
ngắn gọn gần với ngôn ngữ tự nhiên cùng cộng đồng phát triển mạnh giúp rút ngắn
thời gian, công sức xây dựng chương trình.
Khi quyết định xây dựng thư viện lập trình và mạng xã hội chia sẻ địa điểm, tôi mong
muốn xây dựng các ứng dụng có thể chạy được trên các nền tảng, hệ điều hành khác
nhau, cũng như có thể kết nối với các ứng dụng hoặc các mạng xã hội khác để tiếp cận
đến với càng nhiều người dùng càng tốt. Chính vì vậy, tôi xây dựng các thư viện lập
trình API theo chuẩn RESTful giúp mọi ứng dụng hay hệ thông đều có thể dễ dàng kết
nối mà không phụ thuộc vào ngôn ngữ lập trình hay hệ điều hành. Ngoài ra, với những
điều thu được, những kĩ thuật hữu ích khi xây dựng mạng xã hội, tôi đóng gói các
thành thư viện (gems) để chia sẻ cho cộng đồng phát triển Ruby On Rails nói riêng và
các nhà lập trình nói chung.
Từ những điểm trên, tôi thực hiện luân văn về “Xây dựng thư viện lập trình API theo

5


chuẩn RESTful cho mạng xã hội chia sẻ địa điểm”. Cụ thể, công việc được thực hiện

trong luận văn bao gồm việc nghiên cứu các công nghệ cần thiết để thiết kế và cài đặt
các thư viện lập trình API theo chuẩn RESTful, cùng với đó thực hiện cài đặt một hệ
thống mạng xã hội chia sẻ địa điểm chạy trên nền tảng Web và đóng gói các thư viện
(gems) cho cộng đồng lập trình có thể tái sử dụng.
Bố cục của luận văn được tổ chức như sau:
1. Đặt vấn đề: khảo sát, đánh giá các thư viện, framework hỗ trợ xây dựng mạng
xã hội hiện có. Qua đó cho thấy tính cần thiết của việc thực hiện các công việc
trong luận văn.
2. Các công nghệ sử dụng: trình bày các đặc điểm chính và các khả năng của các
công nghệ được sử dụng để xây dựng mạng xã hội chia sẻ địa điểm.
3. Phân tích, thiết kế hệ thống: trình bày tổng quan về các chức năng của mạng xã
hội chia sẻ địa điểm, đặc tả các chức năng bằng các khung nhìn theo lược đồ
trường hợp sử dụng (Use-case diagram), lược đồ hoạt động (Activity diagram),
lược đồ chuỗi hành động (Sequence diagram).
4. Cài đặt thư viện: trình bày mục đích xây dựng và các tính năng của các thư viện
thực hiện được.
5. Cài đặt hệ thống mạng xã hội chia sẻ địa điểm: trình bày kiến trúc vật lý, giao
diện của các chức năng của các chức năng chính của mạng xã hội chia sẻ địa
điểm đã được cài đặt.
6. Kết luận: kết quả đạt được đối với các công việc thực hiện trong luận văn,
những điểm còn hạn chế, hướng phát triển của các công việc đã làm được trong
luận văn.

6


1

Đặt vấn đề
Cùng với sự bùng nổ của các mạng xã hội thì các công cụ hỗ trợ giúp xây dựng


mạng xã hội cũng ngày một nhiều lên. Vậy vấn đề là tại sao ta không sử dụng các công
cụ đó để xây dựng mạng xã hội chia sẻ địa điểm? Có ưu. nhược điểm gì ở những công
cụ này? Và tại sao lại tự xây dựng mạng xã hội này bằng Ruby on Rails? Để trả lời các
câu hỏi trên tôi đã thử nghiệm và đánh giá một số framework hỗ trợ xây dựng mạng xã
hội tiêu biểu hiện có, bao gồm:
-

Buddypress (PHP): />
-

Dolphin (PHP): />
-

Community Engine (Ruby): />
Sở dĩ chọn các framework viết bằng PHP và Ruby On Rails để đánh giá vì ta biết rằng
cả 2 ngôn ngữ đều rất phổ biến, có cộng đồng phát triển mạnh, và đều rất thích hợp để
xây dựng, phát triển các mô hình web ứng dụng vừa và nhỏ như mạng xã hội được đề
cập trong luận văn này. Ta sẽ lần lượt đi vào chi tiết các framework này.
 Buddypress: Như chúng ta biết Wordpress có một cộng đồng phát triển rất lớn
mạnh, trong đó nó có rất nhiều các plugin cung cấp rất nhiều các chức năng khác nhau.
Trong đó có Buddypress - một plugin hỗ trợ làm MXH của Wordpress.
Sau khi cài đặt và thử sử dụng Buddypress tôi thấy nó là một plugin hay để xây
dựng một MXH với các chức năng cơ bản như kết bạn, đăng bài, bình luận, thích bài
đăng, …
Tuy nhiên số lượng các chức năng Buddypress bản thân nó cung cấp không nhiều.
Nhưng một lợi thế của nó là cộng đồng phát triển wordpress lớn, số lượng plugin rất
nhiều nên ta có thể dễ dàng tìm được các plugin khác giúp xây dưng các chức năng mở
rộng của MXH mình muốn xây dựng như Address Geocoder giúp tích hợp địa điểm
bản đồ vào bài đăng, hoặc ta muốn kết nối đến các dịch vụ cache dữ liệu giúp nâng cao

hiệu năng cho hệ thống (như memcached, redis) hay dịch vụ giúp đánh chỉ mục cho

7


việc tìm kiếm nâng cao (như elasticsearch) đều có các plugin hỗ trợ tương ứng,… Tuy
không khó khăn trong việc tích hợp các plugin và chúng đều ở dạng mã nguồn mở nên
có thể tùy biến cao nhưng công việc này cũng rất mất công.
Có thể nhận thấy những điểm hạn chế như sau:
-

MXH chia sẻ địa điểm ta cần có sự quản lý phân cấp địa điểm (thành phố, bang,
nước) nhưng các plugin chỉ dừng lại ở mức trả cho ta ở dạng chuỗi kí tự nên ta phải
xử lý chuỗi này nếu muốn thực hiện phân cấp quản lý.

-

Trong trường hợp ta cần nâng cao hiệu năng hệ thống, cần sử dụng memcached như
các thành phần bộ nhớ đệm. Ta có thể tìm được plugin để kết nối memcached
nhưng đó chỉ ở kết nối đơn thuần. Khi chúng ta cần sử dụng chúng như memcached
để làm bộ nhớ đệm cho các truy vấn SQL, dùng làm bộ nhớ đệm cho các thành
phần lặp lại trên view đều không sẵn có.

-

Việc xây dựng Restul API trong Buddypress thì rất khó khăn, gặp trở ngại vì không
được hỗ trợ, ngay cả sử dụng plugin khác thì cũng chưa hoàn chỉnh.

-


Để tìm kiếm hỗ hợp, sắp xếp phức tạp thì ta chọn sử dụng dịch vụ Elasticsearch với
nhiều ưu điểm. Có thể tìm được plugin cho phép kết nối elasticsearch nhưng lại hỗ
trợ chưa tốt nhất là việc đưa dữ liệu vào Elasticsearch từ CSDL. Định nghĩa các bộ
phân tích không có hỗ trợ, đánh chỉ mục cho các phương thức gắn với các đối
tượng mà không phải là thuộc tính sẵn có trong CSDL cũng không có.

 Dolphin: Là một framework bằng PHP giúp xây dựng MXH nhưng mất phí.
Khác vói Buddypress chỉ cung cấp các tính năng mạng xã hội cơ bản thì Dolphin cung
cấp các chức năng phong phú hơn thông qua số lương khá lớn các module như: quản lý
người dùng, post ảnh, video, quản lý theo tag, lọc và sắp xếp các nhóm đối tượng theo
các tiêu chí, ... Thậm chí nó còn cung cấp giao diện quản trị (admin), forum và tích hợp
di động (mobile). Nhưng cũng có thể thấy các nhược điểm của nó là:
-

Sử dụng mất phí, và vấn đề tùy biến vì liên quan đến bản quyền. Do đó việc phát
triển các chức năng mới sẽ không dễ dàng.

8


-

Cũng như Buddypress không thấy có hỗ trợ Restful.

-

Một điểm chung nữa cho PHP framework, không tích hợp sẵn memcached nên như
nói ở trên việc sử dụng memcached làm bộ nhớ đệm giúp tăng hiệu năng hệ thống
và giảm tải cho CSDL khá khó khăn.


-

Tuy cung cấp khá phong phú các chức năng nhưng một số chức năng mong muốn
mang tính đặc thù như tạo bộ sưu tập ảnh, quản lý phân cấp địa điểm cũng chưa có
sẵn.

 Community Engine: Là tập hợp các gem để xây dựng MXH cho nền tảng Ruby
On Rails. Cung cấp các khái niệm cơ bản cho MXH như người dùng, bài đăng, hoạt
động, …
Không có các chức năng tìm kiếm hỗn hợp, gom nhóm nhưng ta có thể tích hợp
ElasticSearch vào Rails qua thư viện tire. Hỗ trợ rất tốt cho kết nối cũng như cấu hình
các thành phần, định nghĩa bộ phân tích mới hay tạo chỉ mục cho các phương thức
riêng của đối tượng.
Khác với các PHP framework ở trên thì Rails tích hợp sẵn memcached, hỗ trợ
Restful. Đó là các điểm mạnh dễ thấy.
Community Engine cũng chỉ cung cấp các chức năng hết sức đơn giản, còn các
chức năng cần thiết cho MXH ta mong muốn đều cần phải xây dựng từ đầu như tạo bộ
sưu tập, lập kế hoạch, thậm chí là đăng ảnh có gắn với thông tin địa điểm và quản lý
phân cấp địa điểm.
Ngoài ra tuy Rails tích hợp memached như cache mặc định, bản thân memcached
đã được dùng để làm bộ nhớ đệm cho truy vấn SQL và có hỗ trợ cache trên view. Tuy
nhiên điểm yếu ở đây là cơ chế đọc từng dữ liệu đệm ra một không phải dạng đọc
nhiều dữ liệu cùng lúc. Với MXH thì kết nối là tất yếu do đó số lượng đối tượng cần
được truy vấn hiển thị sẽ không hề nhỏ, nếu đọc từng giá trị một ra từ memcached thì
nó sẽ tạo ra rất nhiều kết nối đến máy chủ memcached => gây tắc nghẽn, quá tải. Do
đó rất cần cơ chế gom nhóm các khóa đọc nhiều giá trị chỉ với 1 kết. Đối với redis,

9



Rails cũng có các gems nhưng cũng chỉ hỗ trợ mức cơ bản. Việc thực hiện cache cho
đối tượng phải tự thực hiện. Không có cơ chế xử lý ngoại lệ khi gặp sự cố với redis, …
Chính vì vậy, tôi xây dựng các thư viện với mục đích cải thiện các tồn tại trên để cộng
đồng phát triển Ruby On Rails có thể dễ dàng tái sử dụng.
Như vậy việc sử dụng Community Engine không đem lại lợi ích rút ngắn quá trình
xây dựng hệ thống mà còn gây bất tiện vì không phải thư viện nào trong nó cũng có ích
trong hệ thống, do dư thừa và phải mất công xóa đi.
 Tóm lại, để xây dựng một MXH với các tính năng cơ bản thì có thể sử dụng một
trong số các framework nêu trên. Tuy nhiên, để xây dựng một MXH phục vụ một lĩnh
vực cụ thể như MXH chia sẻ địa điểm mà tôi đang xây dựng, thì việc sử dụng các
framework này không đáp ứng được yêu cầu bởi các nguyên nhân sau:
-

Thiếu nhiều chức năng cần cho hệ thống như không có quản lý đia điểm phân
cấp, tạo và quản lý bộ sưu tập ảnh (đơn thuần chỉ có thích, bình luận về ảnh
hoặc bài viết), tìm kiếm gom nhóm và sắp xếp, lập kế hoạch với ảnh …

-

Thiếu các cơ chế đệm dữ liệu giúp tăng hiệu năng hệ thống (memcached ,
redis, ...), nếu có thì cũng chỉ ở mức đơn giản cần tùy biến nhiều.

-

Mặt khác dùng các framework này, do có tính đóng gói nên đều sẽ tạo ra sự dư
thừa (cả về code và CSDL), để tối ưu ta lại mất công phân tích và loại bỏ.

 Với mục tiêu xây dựng các thư viện lập trình API theo chuẩn RESTful cho MXH
chia sẻ địa điểm, cùng với khả năng mở rộng cao (để tích hợp các chức năng mới,
được phát triển trong tương lai) thì tôi chọn Ruby On Rails. Trong đó, tôi có sử

dụng một số thư viện sẵn có và cũng tùy biến xây dựng một số thư viện mới để đáp
ứng nhu cầu như đã nêu ở trên.

10


2

Các công nghệ sử dụng

2.1 RESTful Web Service
REST là một khái niệm trừu tượng của kiến trúc World Wide Web. REST định
nghĩa các quy tắc kiến trúc về thiết kế Web services, bỏ qua các chi tiết các thành phần
thực hiện và cú pháp giao thức để tập trung vào vai trò của các thành phần, các khó
khăn khi tương tác với các thành phần khác (theo Wikipedia). Nếu tính theo số dịch vụ
mạng sử dụng, REST đã nổi lên trong vài năm qua như là một mô hình thiết kế dịch vụ
chiếm ưu thế. Trong thực tế, REST đã có những ảnh hưởng lớn và gần như thay thế
SOAP và WSDL vì nó đơn giản và dễ sử dụng hơn rất nhiều. Bằng chúng cho thấy
điều đó là các công ty hàng đầu về web 2.0 như Facebook, Google, Yahoo, Twitter,
Amazon ủng hộ sử dụng REST cho các dịch vụ của họ. Ta có thể thấy được các dịch
vụ sử dụng RESTful web service trong thực tế như ElasticSearch, Amazon Simple
Storage Service, Twitter, ... Hay các framework hỗ trợ RESTful như Ruby On Rails,
Restlet (Java), Django (Python),… (Leonard Richardson, Sam Ruby. 2007. RESTful
Web Services). Tập trung vào các yếu tố chinh của RESTful để thấy được các ưu điểm
nó mang lại, ta xem xét đến 4 nguyên tắc thiết kế sau của RESTful:
 Sử dụng các phương thức HTTP một cách rõ ràng
Một đặc tính quan trọng của dịch Web service RESTful là sử dụng một cách rõ ràng
các phương thức HTTP theo giao thức được xác định bởi RFC 2616. REST yêu cầu các
nhà phát triển sử dụng phương thức HTTP một cách rõ ràng theo cách tương thích với
giao thức chuẩn. Nguyên lý thiết kế của REST thiết lập ánh xạ 1-1 giữa các hành động

tạo, đọc, cập nhật và xoá (CRUD) của quá trình vận hành và các phương thức HTTP
như sau:
 Phương thức POST: Để tạo một tài nguyên trên máy chủ.
 Phương thức GET: Để truy xuất một tài nguyên.
 Phương thức PUT: Để thay đổi trạng thái một tài nguyên hoặc để cập nhật nó.

11


 Phương thức DELETE: Để huỷ bỏ hoặc xoá một tài nguyên.

Hình 2.1 Hình minh họa sử dụng các phương thức HTTP trong RESTful
 Phi trạng thái
Thiết kế phi trạng thái chuyển hầu hết vai trò duy trì trạng thái từ máy chủ sang ứng
dụng ở máy khách. Trong một dịch vụ mạng RESTful, máy chủ chịu trách nhiệm đưa
ra các phản hồi và cung cấp một giao diện cho phép máy khách duy trì trạng thái ứng
dụng của chính nó.
Ví dụ: trong yêu cầu lấy kết quả theo trang dữ liệu, máy khách gửi yêu cầu gồm số
trang thực tế khi truy xuất thay vì đơn giản chỉ là gửi yêu cầu tiếp theo như dịch vụ
trạng thái. Tham khảo hình sau để thấy rõ hơn:

Hình 2.2 Thiết kế trạng thái

12


Hình 2.3 Thiết kế phi trạng thái
Thiết kế phi trạng thái trong RESTful thể hiện như sau:
 Máy chủ: tạo ra các phản hồi mà xác định chúng có thể lưu trữ hoặc không phải để
nâng cao hiệu quả bằng cách giảm số lượng yêu cầu đối với các tài nguyên trùng

nhau. Máy chủ làm được như vậy bằng cách sử dụng HTTP Last - Modified (lần
sửa gần nhất) (giá trị ngày) và Cache-Control (bộ điều khiển lưu trữ) trong phần
header trả về.
 Ứng dụng máy khách: sử dụng phần đầu phản hồi Cache-Control để xác định lưu
trữ tài nguyên nội bộ hay không. Máy khách cũng đọc phần đầu phản hồi LastModified và gửi lại giá trị ngày vào If-Modified-Since (nếu-sửa) để truy vấn máy
chủ xem tài nguyên có thay đổi không. Nếu mã phản hồi là HTTP 304, điều đó có
nghĩa máy khách có thể sử dụng tài nguyên từ vùng sao lưu nội bộ mà không cần
gửi yêu cầu GET cho đến khi tài nguyên thay đổi.
 Sự hợp tác này giữa ứng dụng máy khách và máy chủ giúp nâng cao hiệu quả bằng
cách tiết kiệm băng thông và tối thiểu hoá trạng thái ứng dụng phía máy chủ.
 Cấu trúc URls dạng cấu trúc cây thư mục
Các địa chỉ REST đều được xây dựng với mục đích sao cho rõ ràng, có thể đoán
được và dễ hiểu đối với người dùng, do vậy cần xây dựng URIs có cấu trúc. Loại URI
này có thứ bậc, có điểm nguồn tại một đường dẫn đơn, và có nhánh đi ra từ nó là các
đường nhỏ tỏa ra từ phần chính của dịch vụ. Nó như là một cây với các nhánh chính và
nhánh phụ nối với nhau tại các nút. Các URIs này được xây dựng với mục tiêu tự nó

13


đem đến ý nghĩa mà cần ít lý giải thêm, đối với nhà phát triển thì nó giúp chỉ định đến
tài nguyên liên quan.
Ví dụ 1: đường dẫn để truy cập đến trang của một thành phố trong hệ thống:
/>Gốc là /locations (chỉ kiểu địa điểm), có một nút tiếp theo là /cities (chỉ đây là kiểu
thành phố) bên dưới nó. Phía cuối {name} đơn giản là chuỗi chỉ tên của thành phố
muốn xem.
Ví dụ 2: phân cấp tài nguyên theo cấu trúc bởi ngày, tháng, năm
/> Chuyển đổi JSON và XML hoặc cả hai
Cuối cùng cần nhắc đến là việc trả về dữ liệu cho yêu cầu từ máy khách. Các máy
khách có thể yêu cầu các nguồn tài nguyên đa dạng như một bản ghi trong một cơ sở

dữ liệu bao gồm một tổng thể giữa tên các cột và các thẻ XML (nơi các giá trị thành
phần trong XML bao gồm các giá trị các dòng) hoặc một bản tóm tắt các thuộc tính của
những thứ trong mô hình dữ liệu hệ thống dưới dạng JSON. RESTful thiết lập quy
trình phải làm thế nào với định dạng dữ liệu mà ứng dụng và dịch vụ trao đổi trong quá
trình yêu cầu/phản hồi hoặc trong phần thân của HTTP. Để máy khách có khả năng yêu
cầu loại nội dung cụ thể cho các ứng dụng phù hợp nhất, hãy tận dụng được phần
HTTP Accept header sẵn có (giá trị ở đây muốn nhắc đến là MIME-type). Điều đó cho
phép máy khách chọn định dạng dữ liệu nào là đúng với chúng và tối thiểu hoá sự kết
nối lại giữa dịch vụ và các ứng dụng mà sử dụng nó. Các loại định dạng thông thường
sử dụng bởi RESTful:
MIME-Type

Content-Type

JSON

application/json

XML

application/xml

XHTML

application/xhtml+xml

14


2.2 Ruby On Rails

Ruby on Rails được biết đến là một Web framework với ngôn ngữ lập trình là Ruby
và hỗ trợ đầy đủ RESTful web service. Như mọi Web framework, nó có chứa nhiều
công cụ, thư viện và các tiện ích mở rộng của ngôn ngữ Ruby cho phép lập trình viên
tạo phần mềm trên nền web dễ dàng. Một điểm nữa là các thư viện và cộng đồng phát
triển Ruby on Rails khá mạnh và đa phần là mã nguồn mở, cho phép các lập trình viên
dễ dàng sử dụng và tùy biến theo mục đích. Theo các đánh giá của các hà phát triển,
Ruby on Rails có thể làm giảm chi phí tạo ra và duy trì phần mềm trên nền web.
Dưới đây là một số trong những lý do chính để sử dụng Ruby on Rails cho dự án ứng
dụng web:
 Thời gian phát triển nhanh hơn
Ruby on Rails đã được tạo ra với một khái niệm trong tâm trí gọi là "quy ước về
cấu hình". Trong một số công nghệ khác, các nhà phát triển cần phải giành thời gian
đáng kể để đưa ra quyết định về cách một ứng dụng sẽ được thiết lập (ví dụ, cấu trúc
cho các dự án, làm thế nào mã kết nối CSDL, hoặc các thiết lập trong các tập tin cấu
hình). Rails đi kèm với những quyết định "mặc định hợp lý", quy ước mà nó làm việc
tốt trong phần lớn các ứng dụng. Điều đó có nghĩa các nhà phát triển có thể dành phần
lớn thời gian vào các vấn đề mà họ đang cố gắng giải quyết trong ứng dụng của họ,
không phải là khía cạnh cài đặt thiết lập chung. Rails cũng bao gồm một khái niệm
được gọi là "không lặp lại chính mình" hay DRY. Ý tưởng đằng sau DRY là ta không
nên lặp lại mã của chính mình. Thay vào đó, ta nên sắp xếp nó trong một cách mà mã
cần thiết ở những nơi nhiều có thể được viết một lần, sau đó chia sẻ bất cứ nơi nào cần
thiết của nó. Điều này giúp tránh được "sao chép / dán mã" và làm cho việc bảo trì,
thay đổi dễ dàng hơn.

15


 Thư viện và cộng đồng phát triển mạnh
Thư viện của Ruby được gọi là "gems" nó tương tự như plugin trong WordPress,
hay thư viện (lib) trong java nhưng nó dễ dàng hơn cho việc ghép vào chương trình.

Chỉ cần khai báo và chỉ định phiên bản là có thể sử dụng. Đặc biệt tiện lợi trong việc
nhiều người phát triển một dự án hay trên nhiều máy khác nhau, khi đó thao tác sẽ đơn
giản và rút gọn hơn. Ngoài ra cộng đồng phát triển mạnh cùng với việc các gems đều ở
dạng mở nên người phát triển không chỉ dễ dàng trong việc tìm kiếm và sử dụng mà
còn dễ dàng tùy biến theo mục đích.
 Tự động kiểm tra
Vấn đề về thử nghiệm rất quan trọng. Khi ta xây dựng từng phần, ta muốn được
rằng nó hoạt động đúng. Và ta cũng muốn chắc chắn rằng khi ta tiếp tục xây dựng trên
tính năng mới, ta không gây ảnh hưởng đến những gì đã làm. Đó là những điểm cơ bản
mà kiểm tra tự động cho phép ta làm, bằng cách viết code để kiểm tra chức năng hoặc
các phần chức năng. Đó là mã thử nghiệm có thể được chạy với một lệnh duy nhất và
có thể nhanh chóng kiểm tra tất cả các trường hợp cho các chức năng của hệ thống để
chắc chắn tất cả mọi thứ vẫn hoạt động chính xác. Điều này chính xác và đầy đủ hơn
nhiều với việc kiểm tra trên giao diện chương trình trên các trình duyệt web.
2.3 Memcached
Memcached là phần mềm miễn phí và mã nguồn mở, nó hỗ trợ việc phân tán rất tốt,
cho nên ta có thể dễ dàng triển khai với nhiều server memcached phân tán. Memcached
lưu trữ dựa trên các cặp khóa và giá trị trên bộ nhớ RAM. Memcached thường được
dùng như một hệ thống lưu trữ bản sao các đối tượng và dữ liệu được truy cập nhiều
lần để tăng tốc độc truy xuất. Vì Memcached tạo các bộ nhớ đệm dữ liệu và các đối
tượng trong bộ nhớ RAM nên nó đảm bảo việc truy cập dữ liệu rất nhanh, mà không
phải truy cập vào CSDL hay tài nguyên trên đĩa cứng.

16


(Nguồn: />
Hình 2.4: Sử dụng Memcached trong đệm dữ liệu khi truy cập cở sở dữ liệu
Mặt khác Ruby on Rails tích hợp sẵn memcached như một cache mặc định. Việc tải
dữ liệu từ CSDL được mặc định hỗ trợ cache bởi memcached trong Rails. Do đó ta

không mất thời gian cho việc thực hiện hay cài đặt cho nó.
Một tác dụng khác của memached trong hệ thống tôi xây dựng, đó là memcached để
thực hiện cache từng phần (cache fragment) cho đối tượng JSON hay phần HTML
được dùng chung để giảm thời gian xử lý, tăng tốc độ hệ thống. Điều này giúp giảm
thời gian tạo dữ liệu, giảm tài nguyên máy chủ cho công việc này bằng cách dùng dữ
liệu có sẵn trong bộ nhớ đêm. Khác với việc cache toàn bộ trang web hay toàn bộ dữ
liệu JSON trả về, ở đây ta chỉ cache fragment một phần. Sở dĩ vậy vì cache toàn bộ
trang web chỉ thực hiện được với các trang web dùng chung và không bất biến với các
người dùng khác nhau, điều này rất ít có trong một mạng xã hội có sự tương tác giữa
các đối tượng. Ngoài ra theo các tiêu chí tìm kiếm và sắp xếp khác nhau thì dữ liệu trả
về cũng không cố định. Do đó ta chỉ có thể thực hiện cache một phần dữ liệu dùng
chung bất biến, còn các trạng thái sẽ không bị cache do đó sẽ đảm bảo tính đúng đắn về

17


trạng thái tương tác với các người dùng khác nhau.
Ví dụ: việc thực hiện cache cho API lấy danh sách các ảnh: cache các phần thông tin
(url, title, vị trí, tọa độ, …) của từng ảnh - đây là không thay đổi với các người dùng
khác nhau. Phần thông tin trạng thái như like_status, pin_status, … sẽ không được
cache. Khi thực hiện tìm kiếm sắp xếp để lọc ra danh sách các ảnh, các đối tượng ảnh
được lọc sẽ được lấy thông tin từng đối tượng từ bộ nhớ đệm dựa vào ID của ảnh sau
đó hợp nhất dữ liệu JSON trả về.
Ngoài ra, memcached còn được sử dụng cache các phần thông tin dùng chung ít thay
đổi hoặc chỉ thay đổi trong một khoảng thời gian nhất đinh. Như danh sách ảnh phổ
biến chỉ được tính toán và cập nhật mới sau mỗi 30 phút do đó ta có thể đưa danh sách
ảnh phổ biến vào memcached và lưu trữ trong vòng 30 phút., sau thời gian này sẽ tự
động cập nhật lại cho memcached. Điều này, giúp giảm tải cho việc truy cập CSDL,
đẩy nhanh tốc độ cho trang web có tính quảng bá của hệ thống.
2.4 Redis

Redis được biết đến như một NoSQL CSDL Cũng như các NoSQL DB khác (như
memcached, AWS SimpleDB,...) , Redis lưu trữ dữ liệu dưới dạng cặp khóa và giá trị
(key - value). Mặc dù làm việc với data dạng key-value và lưu trữ trên RAM, Redis
vẫn cung cấp thêm cơ chế lưu trữ dữ liệu trên ổ cứng (Tiago Macedo, Fred Oliveira,
2011). Có 2 lý do cho việc này, một là để đảm bảo toàn vẹn dữ liệu khi có sự cố xảy ra
(server bị tắt nguồn) cũng như tái tạo lại dữ liệu khi khởi động lại server, hai là để gửi
dữ liệu đến các slave server, phục vụ cho tính năng replication. Redis cung cấp 2
phương thức chính cho việc sao lưu dữ liệu ra ổ cứng, đó là RDB và AOF.
-

RDB thực hiện tạo và sao lưu snapshot của DB vào ổ cứng sau mỗi khoảng thời
gian nhất định.

-

AOF lưu lại tất cả các thao tác write mà server nhận được, các thao tác này sẽ được

18


chạy lại khi restart server hoặc tái thiết lập lại dữ liệu(dataset) ban đầu.
Một ưu điểm khác của Redis so với Memcached là tuy cùng lưu dữ liệu dưới dạng
key-value nhưng kiểu dữ liệu của memcached bị hạn chế không đa dạng như Redis
(gồm nhiều kiểu khác nhau như STRING, SET, HASH, LIST, ZSET, ...). Do đó ta sử
dụng Redis để lưu trữ các dữ liệu cần truy cập thay đổi nhiều như số đếm, trạng
thái, .... để giảm tái cho CSDL chính (Postgres).
Ví dụ: trong mạng xã hội chia sẻ địa điểm, khi một người dùng thực hiện thích (like) 1
ảnh, ngoài việc ghi nhận sự kiện đó thì trạng thái thích của người dùng đó với ảnh, số
lượt thích của ảnh đó cũng cần được cập nhật, không kể đến các dữ liệu liên quan như
điểm ảnh để tính độ phô biến, số thích của người dùng, .... Nếu tất cả số đếm, trạng thái

trên đều được lưu trữ trên CSDL (CSDL) thì một thao tác thích ảnh kéo theo rất nhiều
lần truy cập đến CSDL. Vậy làm thế nào để giảm tải cho CSDL? Đó là Redis, ta dùng
Redis để lưu trữ số đếm và trạng thái, do cập nhật trên RAM nên việc này thực hiện rất
nhanh (việc ghi dữ liệu ra ổ cúng sẽ được Redis ghi nhận thực hiện sau). Không chỉ
thao tác ghi dữ liệu, mà khi lấy dữ liệu ra việc truy suất dữ liệu từ Redis trên bộ nhớ
RAM cũng nhanh hơn rất nhiều so với việc truy cập CDSL.
Một ví dụ khác, ảnh trong hệ thống luôn cần gắn với địa điểm, nhưng địa điểm được
phân cấp từ thành phố - bang - nước => khi lấy thông tin địa điểm của ảnh ta phải truy
vấn thêm đến 3 bảng trong CSDL. Redis sẽ giúp giải quyết vấn đề này. Ta sẽ tạo
phương thức địa điểm cho mỗi ảnh, nó sẽ được lưu trên Redis. Thông tin địa điểm sẽ
được cập nhật nếu người dùng thay đổi vị trí ảnh. Như vậy thay vì phải truy vấn đến 3
bảng trong CSDL thì ta chỉ cần lấy dữ liệu ra từ Redis đơn giản .
Cuối cùng, nhờ vào kiểu dữ liệu đa dạng của Redis ta còn xây dựng được cơ chế gợi
ý từ khóa để tìm kiếm sắp xếp theo độ phổ biến. Mà trong luận văn tôi đã đóng gói
thành một thư viện để tái sử dụng trong cộng đồng phát triển Ruby on Rails.

19


2.5 ElastichSearch
Elasticsearch là một máy chủ tìm kiếm dựa trên Lucene. Elasticsearch được phát triển
bằng Java và được phát hành dưới dạng mã nguồn mở theo các điều khoản của Giấy
phép Apache. Nó cung cấp rất nhiều tính năng mạnh mẽ, một số điểm nổi bật như:
-

Distributed: phân tán dữ liệu, cho phép phát triển từ quy mô nhỏ đến mức doanh
nghiệp lớn. Khi mở rộng quy mô, elasticsearch cùng với khả năng phân tán, chỉ
việc thêm các nút và để cho các cluster tận dụng khả năng mở rộng phần cứng.

-


Full-text search: Elasticsearch sử dụng Lucene để cung cấp các khả năng tìm kiếm
toàn văn bản mạnh mẽ. Ngoài ra, tìm kiếm đi kèm với hỗ trợ đa ngôn ngữ, ngôn
ngữ truy vấn mạnh mẽ, hỗ trợ định vị địa lý.

-

Multi-Tenancy: Một cluster có thể lưu trữ nhiều chỉ số có thể được truy vấn độc lập
hoặc theo nhóm. Việ sử dụng bí danh (alias) cho phép minh bạch hóa dễ hiểu hơn
trong tìm kiếm và xem kết quả tìm kiếm.

-

RESTful API: việc kết nối truy vấn đến Elasticsearch từ bất kì ngôn ngữ lập trình
nào đều dễ dàng và thuận tiện qua HTTP.
Trong hệ thống của tôi, elasticsearch với những tính năng của nó giúp giải quyết

nhiều bài toán tìm kiếm quan trọng gồm:
-

Tìm kiếm ảnh trong phạm vi nhất định: Elasticsearch cung cấp bộ phân tích
geo_point cho phép lưu trữ thông tin về tọa độ của đối tượng. Cùng với cơ chế tìm
kiếm Geo Distance Filter, Elasticsearch cho phép tìm ra các đối tượng nằm trong
một phạm vi (tính theo km, dặm) từ một tọa độ nhất định.

-

Cung cấp khả năng tìm kiếm và sắp xếp nâng cao: cho phép tìm kiếm ảnh thông
qua nhiều trường thông tin khác nhau như tag, chủ đề, tên địa điểm, tên người sở
hữu, thời gian đăng ảnh, số lượt thích, ..


-

Gom nhóm và sàng lọc dữ liệu (Facet search): sau khi tìm kiếm ảnh bằng từ khóa,
20


một nhu cầu khác là người dùng có thể xem kết quả gom nhóm dữ liệu (bao nhiêu
ảnh trong thành phố A, bao nhiêu ảnh trong nước B, bao nhiêu ảnh có tag C ...).
Qua việc gom nhóm dữ liệu, người dùng có thể sàng lọc dữ liệu qua các nhóm và
đưa ra được danh sách kết quả theo mong muốn. Elasticsearch mặc định cung cấp
tính năng này.
Một điều nữa là việc cập nhật dữ liệu từ các đối tượng vào Elasticsearch cũng rất dễ
dàng thông qua các RESTful API được xây dựng sẵn. Đặc biệt với Rails, thư viện tire
cho phép kết nối giữa Elasticsearch với từng lớp đối tượng trong hệ thống qua một giao
diện lập trình đơn giản.
Cuối cùng là khả năng tùy biến và định nghĩa mới các bộ phân tích khiến
elasticsearch càng trở nên mạnh mẽ và hữu ích khi ta phải đưa ra các tiêu chí tìm kiếm
mang tính riêng biệt (như chỉ tìm kiếm người dùng qua tên đăng nhập bởi từ khóa chứa
từ 3-8 kí tự)
=> Có thể nói elasticsearch đã giúp ta giải quyết bài toán tìm kiếm và lọc dữ liệu trong
hệ thống một cách chính xác và đầy đủ.
2.6 Amazon Web Services (AWS)
Với mạng xã hội có tính chất kết nối toàn cầu thì việc đặt máy chủ và cung cấp khả
năng kết nối đến hệ thống một cách tối ưu từ mọi vị trí là một điều quan trong hàng
đầu. Lưu trữ ảnh và truy cập ảnh trong mạng xã hội ảnh cũng rất quan trọng. Người
dùng sẽ không dùng một hệ thống mà nó chạy quá chậm hay phải đợi quá lâu để chỉ
gửi yêu cầu lên máy chủ. Một điểm nữa là ta không có hoặc khó có thể có kinh phí để
xây dựng một hệ thống lớn để đáp ứng nhu cầu đó. Rất may hiện nay các dịch vụ đám
mây hình thành và phát triển mạnh cung cấp cho ta những dịch vụ tốt với chi phí rất

vừa phải. Một trong những dịch vụ đám mây tốt nhất và ra đời sớm nhất đó là dịch vụ
đám mây của Amazon - Amazon Web Service (AWS).

21


Ngoài việc cung cấp và cho thuê máy chủ (Elastic computing with Amazon - EC2)
thì AWS còn cung cấp dịch vụ lưu trữ (Amazon Simple Storage Service - S3) và truy
cập thông qua Amazon Cloudfront.
Amazon Simple Storage Service (S3) cung cấp các giao diện dịch vụ Web cho việc
lưu trữ và khôi phục dữ liệu. Dữ liệu được cho ở bất kỳ loại nào và có thể được lưu trữ
và truy cập đến từ bất kỳ vị trí nào thông qua Internet. Ta có thể lưu trữ không giới hạn
một lượng lớn các đối tượng trong S3 với kích thước của mỗi đối tượng trong khoảng
từ 1 byte tới 5 GB. Ta có thể chọn vị trí lưu trữ cho các đối tượng khi tạo ra buckets tương tự như khái niệm của thư mục. Ta cũng xác lập được phân quyền truy cập hay
tác động đến vùng lưu trữ. Việc truy cập dữ liệu rất đơn giản qua HTTP. Ưu điểm của
S3 là độ an toàn cao, ổn định, dễ sử dụng và nhất là chi phí rất hợp lý. Thêm nữa, việc
kết nối và sử dụng S3 API qua HTTP và HTTPS (được bảo mật bằng việc sử dụng mã
khóa) cũng rất dễ dàng và không quan trọng ngôn ngữ lập trình nào. Do đó tôi quyết
định dùng S3 để lưu trữ ảnh cho hệ thống.
S3 đem lại rất nhiều tiện lợi và ưu điểm nhưng vẫn có một vấn đề đó là việc truy cập
trải rộng trên toàn thế giới. Do vị trí đặt lưu trữ là cố định nên không thể đảm bảo việc
truy cập dữ liệu (ở đây là ảnh) đến từ khắp nơi có tốc độ tốt. Hơn nữa việc truy cập đến
cùng một điểm liệu có khiến tắc nghẽn. Điều này được giải quyết khi ta sửdụng thêm
dịch vụ Amazon Cloudfront. Dịch vụ này cho phép ta truy cập đến các dữ liệu S3
thông qua hệ thống mạng lưới các máy chủ đặt khắp toàn cầu. Tại mỗi máy chủ khi dữ
liệu S3 được truy cập, nó sẽ kiểm tra dữ liệu đã có sẵn chưa, nếu chưa có sẽ truy cập
đến S3 để lấy dữ liệu, ghi lại (để lần yêu cầu tới sẽ không cần truy cập đến S3 nữa) rồi
trả về. Hệ thống này như hệ thống đệm cho phép ra tăng tốc độ truy cập dữ liệu nhanh
và hiệu quả. Thông thường với các ảnh khác nhau sẽ tạo ra một định danh khác nhau
khi lưu trữ do đó việc đệm bộ nhớ này không ảnh hưởng gì đến hệ thống.


22


(Nguồn: />
Hình 2.5: Kiến trúc hệ thống khi sử dụng Amazon Cloudfront
Như vậy, Amazon Web Services không chỉ giúp ta giải quyết vấn đề thuê máy chủ mà
còn giúp ta quản lý, lưu trữ cũng như truy cập ảnh một cách hiệu quả với chi phí hợp
lý.
2.7 Google geocoding
Một vấn đề lớn đối với mạng xã hội địa điểm đó là việc chuyển dữ liệu từ tọa độ
(kinh độ, vĩ độ) ra tên địa điểm (vị trí, thành phố, bang, nước ...). Khi đó ta tìm đến và
sử dụng Geocoding API. Như chúng ta đã biết Google là hãng cung cấp dịch vụ bản đồ
tốt nhất thế giới, thông tin về địa điểm được cập nhật liên tục nên luôn đem lại độ
chính xác cao. Vì thế dịch vụ Google Gecoding cũng được tin tưởng cho ta thông tin
địa điểm chính xác nhất hiện nay (trên phạm vi toàn thế giới chứ không gói gọn trong
23