LỜI CAM ĐOAN Tôi xin cam đoan đề tài khoa học “Xây Dựng Giải Pháp Lưu Trữ Và Truy Xuất Dữ Liệu GPS Với Khối Lượng Lớn Theo Thời Gian Thực Nhằm Phục Vụ Cho Các Giải Pháp Về Giao Thông” nà
Nhiệm vụ nghiên cứu của đề tài
Đưa ra một giải pháp có thể giải quyết bài toán truy xuất và lưu trữ dữ liệu dạng GPS trong thời gian thực Giải pháp có thể là một hệ thống có sẵn trên thị trường hoặc một hệ thống tự xây dựng
- Nếu là hệ thống có sẵn phải mô tả kĩ thuật lưu trữ trên hệ thống đó Mô tả thủ tục cài đặt Có số liệu đo đạc chứng minh hệ thống hệ thống có thể thỏa mãn yêu cầu của luận văn
- Nếu là hệ thống tự xây dựng, phải có thiết kế kiến trúc, mô tả cách hiện thực hệ thống Có các số liệu đo đạc cụ thể chứng minh hệ thống thỏa mãn yêu cầu lưu trữ như trong luận văn
Ý nghĩa khoa học của đề tài
Hiện nay với sự phổ biến của các thiết bị định GPS cũng như các thiết bị cầm tay, lượng dữ liệu có gắn kèm thông tin địa lý sinh ra với tốc độ ngày càng lớn Các giải pháp DBMS truyền thống tỏ ra không phù hợp với loại dữ liệu này
Một số giải pháp chuyên về dữ liệu địa lý tuy nhiên bỏ qua yếu tố thời gian, một số quan tâm đến yếu tố thời gian và địa lý lại tỏ ra quá tải khi dòng dữ liệu đưa vào hệ thống là trong thời gian thực
Bài luận nghiên cứu tìm kiếm một giải pháp giải quyết vấn đề lưu trữ dữ liệu địa lý và thời gian theo thời gian thực, đóng vai trò nền tảng cho các hệ thống khác như phân tích, dự báo, hỗ trợ ra quyết định.
Phương pháp và đối tượng nghiên cứu
- Khảo sát các hệ thống DBMS hiện có, tìm hiểu mô hình dữ liệu Tìm cách đưa dữ liệu mẫu vào hệ thống và đưa ra các đo đạc để xem xét tính phù hợp của hệ thống Nếu hệ thống tỏ ra quá chậm thì đưa ra biện pháp khắc phục, nếu giải pháp khắc phục quá phức tạp hoặc không hiệu quả thì chuyển qua khảo sát hệ thống khác Các hệ thống được khảo sát chủ yếu là các hệ thống theo mô hình NoSQL
- Trong trường hợp không tìm ra hệ thống không phù hợp, tìm hiểu các kĩ thuật index dữ liệu địa lý và thời gian dựa trên các bài báo khoa học Xây dựng hệ thống mới dựa trên các lý thuyết đã tìm hiều được
- Đưa ra các tiêu chí và thực hiện kiểm tra hệ thống đã xây dựng được.
Giới hạn và phạm vi đề tài
- Dữ liệu để khảo sát giải pháp là dữ liệu lộ trình của xe buýt lưu thông tại Việt Nam trong vòng một tuần
- Máy tính để cài đặt là máy tính cá nhân, không phải server chuyên dụng
Kết quả cần đạt được
- Có báo cáo khảo sát các hệ thống, giải pháp tương tự
- Báo cáo về các lý thuyết, giải thuật căn bản của bài toán index dữ liệu theo không gian và bài toán index dữ liệu theo nhiều thuộc tính
- Có kết quả chạy thử với dữ liệu mẫu từ đó đưa ra tính khả thi của giải pháp khi triển khai
2 Mô tả cụ thể bài toán:
Vai trò và vị trí của hệ thống trong hệ thống tổng thể
Từ giờ hệ thống cần xây dựng được gọi là GBStore (GPS Based data Store) Hình dưới mô tả vị trí và vai trò cuả GBStore trong hệ thống tổng thể
- UDP server tiếp nhận các tín hiệu GPS, hình ảnh và các loại dữ liệu khác và truyền vào hệ thống lưu trữ để xử lý sau này
- GBStore là hệ thống cần xây dựng
Hệ thống khách bao gồm các ứng dụng dự đoán giao thông, hiển thị thông tin và các ứng dụng khác khai thác dữ liệu từ hệ thống lưu trữ để phục vụ mục đích riêng của chúng.
Các mũi tên mô tả các luồng dữ liệu:
Hình 1 Vai trò của hệ thống trong hệ thống tổng thể
14 1) Các tín hiệu GPS và các dữ liệu khác từ các phương tiện giao thông, các thiết bị có tích hợp định vị GPS hoặc các loại cảm biến khác truyền thẳng vào hệ thống tiếp nhận
2) Hệ thống tiếp nhận này có thể forward thẳng thông tin nhận được cho các hệ thống khách để xử lý ngay trong thời gian thực
3) Hệ thống tiếp nhận đưa các tín hiệu chứa dữ liệu nhận được vào GBStore để lưu trữ phục vụ cho tổng hợp, phân tích sau này
4) Luồng dữ liệu đáp ứng các truy vấn từ hệ thống khách
5) Luồng dữ liệu từ hệ thống khách đưa vào GBStore Các dữ liệu này có thể là dữ liệu tạm sinh ra trong quá trình xử lý như tốc độ trung bình , mật độ giao thông theo từng khu vực
Dữ liệu
Một đối tượng dữ liệu lưu trữ trong hệ thống phải có các thông tin sau đây: key: khóa do người dùng định nghĩa, time: thời gian của dữ liệu, latitude và longtitude: tọa độ địa lý của dữ liệu, dữ liệu (dạng chuỗi byte thô, hệ thống không quan tâm đến nội dung chuỗi byte này), type: kiểu dữ liệu (để phân loại dữ liệu, tương tự phân loại dữ liệu thành các bảng trong các CSDL quan hệ)
Ngoài kiểu dữ liệu có gắn kèm thời gian, còn có kiểu dữ liệu không phụ thuộc thời gian Với kiểu dữ liệu này, ta xem như một trường hợp đặc biệt của kiểu dữ liệu phụ thuộc thời gian Mọi đơn vị dữ liệu thuộc kiểu độc lập thời gian sẽ được gắn một trị thời gian đặc biệt nào đó để phân biệt với các đơn vị dữ liệu phụ thuộc thời gian
15 Một đối tượng dữ liệu D (Data) được kí hiệu bằng một bộ D(T, Lat,Long, K, B) với T là thời gian, Lat và Long hợp thành tọa độ địa lý, K là khóa của dữ liệu, B là dữ liệu thô được gắn với đối tượng này
Với dữ liệu không phụ thuộc thời gian, T nhận giá trị đặc biệt kí hiệu là t 0
Do thời gian thực hiện luận văn có giới hạn, do đó, để đơn giản bài toán, giả thiết mọi đơn vị dữ liệu đưa vào hệ thống đủ nhỏ và mọi đơn vị dữ liệu đều có kích thước bằng nhau để một thao tác đưa dữ liệu vào hệ thống có thể thực hiện trong một lệnh, không phải chia nhỏ dữ liệu ra nhiều phần.
Lưu trữ
Hệ thống phải có khả năng đáp ứng dòng dữ liệu đầu vào liên tục, do đó yêu cầu lưu trữ là phải đảm bảo đáp ứng tốc độ dòng dữ liệu đầu vào lớn, tức là thời gian lưu trữ một đơn vị dữ liệu phải đủ nhỏ, nếu tốt hơn nên có khả năng lưu trữ đồng thời nhiều đơn vị dữ liệu cùng lúc trong trường hợp hệ thống có nhiều luồng dữ liệu vào
Hệ thống phải có khả năng hoạt động tốt với dòng dữ liệu đầu vào có mật độ phân bố không đều cả về không gian lẫn thời gian (dữ liệu mẫu có phân bố không đều theo cả không gian và thời gian)
Dữ liệu lưu trong hệ thống được đưa vào liên lục do đó hệ thống phải có khả năng sao lưu các dữ liệu cũ để tránh quá tải
Một thao tác đưa dữ liệu D vào hệ thống kí hiệu là Put(D) Tạm thời luận văn không xét đến thao tác xóa dữ liệu khỏi hệ thống.
Truy vấn
Hệ thống phải có thời gian đáp ứng (latency) nhanh với các yêu cầu truy xuất dữ liệu (thời gian từ lúc nhận yêu cầu đến lúc trả về kết quả) Latency này cũng không được tăng khi có nhiều dữ liệu trong hệ thống
16 Các điều kiện trong truy xuất:
- Điều kiện về thời gian: dữ liệu trả về trong trong khoảng thời gian [t1, t2]
- Điều kiện về khóa: dữ liệu trả về có khóa bằng một số xác định
- Điều kiện về địa lý: Có 2 kiểu điều kiện địa lý: o Được bao bởi một hình chữ nhật xác định o Được bao bởi một hình tròn có bán kính và tâm xác định
- Điều kiện về loại dữ liệu: dữ liệu trả về phải có loại giống với loại được xác định trong truy vấn
Một truy vấn đến hệ thống là tổ hợp các điều kiện trên Để đơn giản và tránh trường hợp dữ liệu trả về quá nhiều, ta giới hạn một truy vấn phải luôn luôn tồn tại ít nhất giới hạn về thời gian và giới hạn về loại dữ liệu Như vậy dữ liệu trả về bắt buộc phải có thời gian nằm trong một khoảng và phải cùng một loại
Một truy vấn được kí hiệu Get(TS,TE, Loc, K)
- TS, TE lần lượt là thời điểm bắt đầu và thời điểm kết thúc của dữ liệu cần trả về
- Loc là ràng buộc về tính chất địa lý của dữ liệu, ta có 2 loại ràng buộc: o Tọa độ bị giới hạn bởi một hình chữ nhật, khi đó Loc có dạng R(LatMin, LatMax, LonMin, LonMax) Trong đó, các tham số như tên của chúng, là giới hạn về kinh độ và vĩ độ của dữ liệu được trả về o Nằm trong vùng hình tròn có bán kính và tâm cho trước, Loc có dạng C(Lat, Lon, R), với Lat, Lon là tọa độ tâm hình tròn, R là bán kính hình tròn
- K là khóa ràng buộc, các đối tượng trả về buộc phải có giá trị khóa bằng K
Trong các mô tả kí hiệu trên, các kí hiệu mô tả thời gian và khóa nhận giá trị kiểu long (số nguyên 64 bit); các kí hiệu mô tả kinh độ và vĩ độ kiểu double (số thực dấu chậm động 64 bit); B (dữ liệu thô) là một mảng byte
17 Để các truy vấn thực hiện một cách khả thi, lượng dữ liệu trả về có giới hạn, không thể chỉ giới hạn thời gian hay không gian vì khi đó lượng dữ liệu trả về là cực kì lớn Do đó các truy vấn phải được ràng buộc như sau:
- Mọi truy vấn đều phải có giới hạn về thời giàn: TS và TE có giá trị xác định, không phải là vô cùng hay âm vô cùng
- Loc và K có thể xuất hiện hay không, tuy nhiên một trong Loc và K phải xuất hiện, hoặc có thể cùng xuất hiện
Vậy ta có thể có một số ví dụ về truy vấn:
Giới hạn về thời gian và không gian: Get(TS,TE, R(LatMin, LatMax, LonMin,LonMax)): Lấy dữ liệu trong khoảng thời gian từ TS đến TE, có tọa độ nằm trong hình chữ nhật được định nghĩa bởi R.
- Giớn hạn về thời gian, trong đó các phần tử nằm trong một bán kính đối với một điểm có tọa độ cho trước: Get(TS,TE, C(Lat, Lon, R))
- Giới hạn cả về thời gian, không gian và khóa: Get(TS,TE, R(LatMin, LatMax, LonMin, LonMax), K)
- Giới hạn về thời gian và khóa: Get(TS,TE, K), trả về dữ liệu có key xác định trong khoảng thời gian từ TS đến TE Thông thường key thường được đặt theo id của phương tiện, do đó lệnh này trả về lộ trình của một phương tiện xác định.
Hiệu suất mong muốn
Hệ thống được xây dựng phải có hiệu suất đạt được tối thiểu như sau:
- Về put dữ liệu: số lênh put phải đạt ít nhất 100 lệnh trên giây
- Về get dữ liệu: có khả năng cung cấp các truy vấn như đã mô tả ở phần 1.4
Thời gian từ lúc nhận truy vấn cho đến khi trả về kết quả không quá 100ms
- Về khối lượng dữ liệu: có khả năng scale tốt khi lượng dữ liệu đưa vào hệ thống quá lớn do dữ liệu được liên tục đưa vào hệ thống
Giải pháp dựa trên các hệ thống database hiện có
Cơ sở dữ liệu quan hệ - MySql
Mặc dù MySql[13] cũng như các hệ thống cơ sở dữ liệu quan hệ khác có vẻ không phù hợp với yêu cầu của hệ thống vì những lý do dễ thấy sau:
- Mô hình dữ liệu phức tạp làm giảm hiệu suất chung của hệ thống
- Các truy vấn đến hệ thống cần đảm bảo hệ thống thuộc tính ACID (Atomicity, Consistency, Isolation, Durability), là một tập các thuộc tính bảo đảm các truy xuất cũng như sửa đổi đến DB được thực hiện một cách đáng tin cậy Do phải đảm bảo các thuộc tính này nên các truy vấn và sửa đổi thông tin diễn ra chậm
- MySql không hỗ trợ phân tải tốt dựa trên thuộc tính địa lý mà hệ thống cần xây dựng mong muốn đạt được
Tuy nhiên MySql được xem xét để bảo đảm tính đầy đủ của luận văn cũng như có cơ sở so sánh với các hệ thống khác.
Cơ sở dữ liệu theo mô hình No-SQL
Sự gia tăng dữ liệu mạnh mẽ cùng với sự phổ biến của internet, mạng xã hội và thiết bị di động đã đặt ra thách thức cho hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) truyền thống RDBMS gặp khó khăn trong việc xử lý lượng thông tin khổng lồ được tạo ra, dẫn đến nhu cầu tìm kiếm các giải pháp lưu trữ dữ liệu mới để đáp ứng yêu cầu ngày càng tăng của thời đại số.
19 hệ thống mới với tư tưởng tân tiến hơn nảy sinh Các hệ thống NoSql là các hệ thống được phát triển dựa trên xu hướng đó
Các cơ sở dữ liệu quan hệ cung cấp nhiều tính năng cũng như bảo đảm tính chặt chẽ của dữ liệu Tuy nhiên các đặc điểm này đôi khi không cần thiết trong một số ứng dụng, ví dụ như lưu trữ thông tin giao thông, trong đó tốc độ truy xuất mới là yêu cầu quan trọng chứ không phải độ chính xác của các ràng buộc
Trong những năm gần đây, document store là các hệ thống hướng đến lưu trữ dữ liệu với mô hình văn bản xuất hiện nhiều sản phẩm và phần nào gây được chú ý
Mongodb[14] là hệ thống nổi tiếng thu hút được sự quan tâm của nhiều nhà phát triển
Mongodb hỗ trợ mô hình dữ liệu cực kì mềm dẻo với các document theo định dạng Json Mongodb lưu trữ các document này dưới đĩa cứng theo một định dạng gọi là Bson Các document lưu trữ vào Mongodb không cần phải tuân theo một schema định sẵn Các document được phân nhóm vào các collection, tương tự table như các hệ thống dạng SQL Ví dụ một document:
"_id" : ObjectId("4efb731168ee6a18692d86cd"),
"address" : "29210 Corporate Dr, Suite 100, Anywhere USA"
20 Mongodb hỗ trợ truy vấn document theo bất kì thuộc tính nào trong document
Về chỉ mục, MongoDB sử dụng kỹ thuật index được hiện thực bằng B+tree, cho phép index lên bất kỳ thuộc tính nào Về dữ liệu địa lý, MongoDB index dữ liệu theo kỹ thuật GeoHash MongoDB hỗ trợ 2 chế độ index địa lý là 2dIndex (tọa độ tính theo hệ tọa độ Eclit) và 2dsphere (tọa độ tính bằng kinh độ, vĩ độ).
Ngoài ra Mongodb hỗ trợ phân tán dữ liệu ra nhiều node, người dùng có thể xác định một thuộc tính để Mongodb phân tán dựa vào thuộc tính đó, thuộc tính dùng để phân tán gọi là shard key Tuy nhiên các thuộc tính địa lý không thể dùng làm shard key
Cassandra[15] được phát triển dựa trên mô hình học hỏi từ Amazon Dynamo[16] và
Google Bigtable[17] Được bắt đầu phát triển tại Facebook và trở thành mã nguồn mở vào năm 2008 Lakshman, một trong những thành viên phát triển Cassandra , mô tả Cassandra là "Hệ thống lưu trữ phân tán nhằm quản lý dữ liệu có cấu trúc và được thiết kế để scale thành một cụm với kích thước rất lớn" Ngoài Facebook, một số công ty khác cũng sử dụng Cassandra như Twitter, Digg, Rackspace…
Mô hình dữ liệu Cassandra bao gồm các thành phần:
Row được định nghĩa bởi một khoá là chuỗi có độ dài xác định Các thao tác trên row được đảm bảo là "atomic" và không phụ thuộc vào số lượng cột đang được đọc hoặc ghi.
- Column family: Là một tập hợp bao gồm nhiều row có cùng ý nghĩa lưu trữ
Column family có ý nghĩa tương tự table của các hệ thống database quan hệ
- Column: Một row có thể có đến 2 tỷ column Các column được xác định bằng tên và được sắp xếp theo thứ tự do người dùng xác định Các row trong cùng một column family có thể có số column khác nhau
21 Các tác vụ đối với Cassandra được thực hiện thông giao diện Thrift[?] Từ phiên bản 2.0, người dùng có thể thao tác với Cassandra một cách dễ dàng hơn nhờ một ngôn ngữ truy vấn tương tự SQL gọi là CQL
Một số ví dụ lệnh CQL:
CREATE TABLE playlists ( id uuid, song_order int, song_id uuid, title text, album text, artist text, PRIMARY KEY (id, song_order ) );
INSERT INTO playlists (id, song_order, song_id, title, artist, album)
'Ojo Rojo', 'Fu Manchu', 'No One Rides for Free')
SELECT * FROM playlists WHERE artist = 'Fu Manchu';
Cần lưu ý rằng tuy CQL có cấu trúc giống SQL nhưng về căn bản dữ liệu được lưu trữ bên dưới không phải mô hình quan hệ mà vẫn theo các row và column
Sau một năm được sử dụng tại Facebook, Lakshman kết luận: "Cassandra đã đạt được nhều mục tiêu - tính scale, hiệu suất cao, tính sẵn sàng cao và nhiều khả năng ứng dụng"
22 Cassandra không hỗ trợ sẵn cơ chế index theo địa lý nên không thể áp dụng trực tiếp để xây dựng GBStore
3.1.3 Một số kiểm tra định lƣợng trên các db có sẵn
Giải pháp đề xuất đầu tiên sử dụng Mongodb làm hệ thống lưu trữ vì Mongodb như đã mô tả ở phần trên, có hỗ trợ hệ thống secondary index và location index (được hiện thực với kĩ thuật GeoHash[12]) Ngoài ra, để tiện so sánh, một giải pháp index khác sử dụng MySQL và một giải pháp khác thực hiện chỉ mục ngay trong bộ nhớ chính của máy tính cũng được hiện thực làm cơ sở so sánh Phần sau đây mô tả cách hiện thực các index của hệ thống với Mongodb, MySQL, memory và các kết quả đạt được
Mỗi đối tượng dữ liệu D(T, Lat,Long, K, B) được ánh xạ thành một document Mongodb như sau:
{ lat: tung độ, long: hoành độ, time: thời gian, key: khóa dữ liệu, data: dữ liệu, được lưu với kiểu blob, loc: { type: Point, coordinates: [long, lat]
Ngoài thuộc tính loc có kiểu là Point để Mongodb có thể áp dụng index 2dsphere lên thuộc tính này, các thuộc tính khác có ý nghĩa như tên gọi Để tạo index ta thực hiện các lệnh sau:
- ensureIndex({key : 1}) - ensureIndex({time : 1}) - ensureIndex({loc : 2dsphere})
3.1.3.2 Thiết kế hệ thống cache trong bộ nhớ chính máy tính
Hệ thống memory cache gồm 3 cấu trúc cây index (BTree, RTree) để index cho từng thuộc tính của dữ liệu
Gốc của hệ thống là một Btree để index thời gian, ta gọi Btree này là TimeTree Mỗi lá của BTree lưu toàn bộ dữ liệu trong một đơn vị thời gian (hệ thống đang hiện thực là 1 phút)
RTre e RTre e miền thời gian miền key miền không gian data item
Hình 2 Cấu trúc hệ thống memory index
Đánh giá chung
Nhìn chung, kết quả giống như dự đoán ban đầu, hệ thống MySQL có hiệu suất thấp nhất trong 3 hệ thống thử nghiệm về các thao tác put và get trên các thuộc tính đơn giản, tuy nhiên vượt trội Mongodb khi cần lấy dữ liệu theo thông tin địa điểm
Mặc dù MongoDB tích hợp sẵn hệ thống chỉ mục theo địa điểm và cho phép tạo chỉ mục thứ cấp để lập chỉ mục cho bất kỳ trường dữ liệu nào, tuy nhiên
30 thời gian truy vấn theo địa điểm quá chậm: với lượng dữ liệu chỉ trong 1 ngày, hệ thống mất hơn 8 giây để trả về kết quả, quá chậm so với yêu cầu truy vấn theo thời gian thực của GBStore
Giải pháp lưu và index dữ liệu trong bộ nhớ chính cho hiệu suất insert cũng như truy vấn rất nhanh Tuy nhiên vấn đề đặt ra là bộ nhớ chính của một máy tính thường nhỏ và không có tính lâu bền, dữ liệu bị mất khi tắt máy tính Giải pháp này có thể dùng làm giải pháp lưu tạm (cache) cho hệ thống khác có khả năng lưu trữ dữ liệu lớn và lâu bền Như vậy ta cần tìm một giải pháp có các đặc điểm: a Có khả năng lưu một lượng rất lớn dữ liệu, thường thì một hệ thống phân tán có khả năng đáp ứng điều này Hầu hết các hệ thống NoSql hiện thời điều có khả năng chạy phân tán Điều còn lại cần xem xét khả năng thêm bớt một node vào hệ thống có thể thực hiện ngay lúc hệ thống đang hoạt động hay phải khởi động lại hệ thống Nếu có thể thêm bớt động node mới vào hệ thống đang chạy thì càng tốt b Mô hình dữ liệu: hầu hết các hệ thống DHT và NoSql có mô hình dữ liệu khá đơn giản Hệ thống cần tìm phải có khả năng đáp ứng ít nhất khả năng index ngoài kiểu key-value thông thường của các hệ thống key-value store c Cơ chế phân tải: hệ thống phải có cơ chế phân tải đồng đều cho các node trong hệ thống để tránh một node quá tải trong thời gian hoạt động cao điểm d Thời gian đáp ứng nhanh: thời gian thực hiện các thao tác put và get dữ liệu phải nhanh vì GBStore là một hệ thống thời gian thực
Giải pháp đầu tiên là xây dựng một hệ thống phân tán đáp ứng tốt các tiêu chí trên ngay từ đầu, truy nhiên như vậy phải giải quyết các bài toán sau:
- Bài thiết kế hệ thống phân tán, đảm bảo quản lý các node trong hệ thống trong trường hợp các node có thể rời và tham gia hệ thống Trong trường hợp rời hệ thống có thể do node đó gặp hỏng hóc
- Bài toán giải quyết đụng độ khi các tác vụ diễn ra đồng thời: khi một node rời hệ thống mà có yêu cầu đọc ghi đến node đó thì phải tìm cách giải quyết như thế nào?
- Bài toán index phân tán: ít nhất phải có khả năng tìm kiếm dữ liệu như một DHT
Như vậy việc xây dựng từ đầu một hệ thống đáp ứng tốt các tiêu chí trên, thậm chí là một trong các tiêu chí trên là vượt quá khuôn khổ luận văn này Do đó, luận văn tìm kiếm một hệ thống có sẵn có khả năng đáp ứng tốt càng nhiều càng tốt các tiêu chí trên
Mongodb đáp ứng tốt tiêu chí b và tương đối tốt tiêu chí a, tuy nhiên tiêu chí d lại không tốt Các hệ thống key-value store như redis, memcache đáp ứng rất tốt tiêu chí d và a tuy nhiên lại đáp ứng không tốt các tiêu chí còn lại
Giải pháp khả thi nhất là xây dựng một cơ chế index trên một hệ thống cơ sở dữ liệu hiện có nhằm thỏa mãn các tiêu chí:
- Index theo key người dùng
- Tốc độ put và get nhanh
- Có khả năng co giãn (scale) tốt khi khối lượng dữ liệu đầu vào lớn
Phần sau mô tả các thuật toán, cấu trúc dữ liệu nền tảng của bài toán index dữ liệu theo không gian, bài toán xây dựng hệ thống phân tán, cân bằng tải và một số công trình nghiên cứu tương tự để xây dựng một hệ thống như vậy
Phần sau đó giới thiệu kĩ hơn về Cassandra, một hệ thống đáp ứng tốt các tiêu chí nhanh, co giãn tốt, và cách áp dụng các kĩ thuật đã tham khảo để xây dựng GBStore trên Cassandra
Các kĩ thuật và công trình nghiên cứu liên quan
Các kĩ thuật index địa lý
Cách tiếp cận căn bản của bài toán chỉ mục dữ liệu theo thông tin địa lý là tìm cách chia không gian thành một số không gian con có thể quản lý được, những không gian con này lại tiếp tục được chia nhỏ hơn và quá trình cứ tiếp tục như thế Quá trình cứ tiếp tục như thế cho đến khi những không gian con không được chia nhỏ hơn nữa chứa một số đối tượng dữ liệu có thể gói gọn trong không trang lưu trữ Nhiều chiến lược chia nhỏ khác nhau được phát triển nhằm mục đích tối ưu hóa thời gian tìm kiếm và thu nhỏ không gian lưu trữ Bằng cách chia nhỏ như trên, hình thành một cây phân cấp giữa các không gian con với nhau, cấu trúc phân cấp được lưu trữ bởi một cấu trúc dữ liệu cụ thể để tối ưu thời gian truy xuất
Nhiều kiểu cấu trúc dữ liệu như B-Tree, chỉ mục ISAM , bảng hash và cây nhị phân từng được sử dụng để tối ưu truy xuất, thêm và xóa dữ liệu vào những cơ sở dữ liệu rất lớn Tất cả những kĩ thuật trên dùng để chỉ mục dữ liệu dựa trên khóa chính, tuy nhiên khi các truy vấn theo vùng dựa trên khóa phụ được sử dụng nhiều thì các kĩ thuật trên lại tỏ ra không hữu hiệu Để giải quyết vấn đề trên, các cấu trúc dữ liệu nhiều chiều như: grid-file [18], B-Tree đa chiều, kd-Tree[19], quad-tree[20] được đề xuất Các cấu trúc trên được gọi là cấu trúc chỉ mục theo điểm vì dữ liệu được đánh chỉ mục là các điểm trong không gian (có thể lớn hơn 2 chiều)
Tìm kiếm theo địa lý tương tự như tìm kiếm theo nhiều khóa thông thường ở chỗ các tọa độ có thể được ánh xạ thành các thuộc tính khác nhau của khóa, và giá trị của các thuộc tính của khóa này biểu diễn một điểm trong không gian k chiều Mặc dù các kĩ thuật ánh xạ các vùng chính quy thành các điểm trong không gian k chiều cho phép chỉ mục các vùng không gian thành các điểm trong không gian nhiều chiều hơn, nhưng lại gây khó khăn cho các phép tìm kiếm chuyên biệt về địa lý như giao nhau hoặc bao trùm (đối tượng này nằm trong hẳn đối tượng kia)
33 Các phương pháp để tìm cách áp dụng các kĩ thuật chỉ mục dữ liệu truyền thống sang dữ liệu có thông tin địa lý có thể phân thành các loại sau:
Có nhiều cách tiếp cận để lập chỉ mục dữ liệu không gian Một phương pháp phổ biến là chỉ mục không gian tham số, trong đó dữ liệu được ánh xạ thành các điểm trong không gian đa chiều Phương pháp này tận dụng được các phương pháp lập chỉ mục nhiều thuộc tính hiện có, nhưng cũng có nhược điểm là các đối tượng gần nhau trong không gian ban đầu có thể không gần nhau trong không gian đã lập chỉ mục Một phương pháp khác là ánh xạ dữ liệu vào không gian một thuộc tính bằng cách chia không gian thành các ô và sắp xếp chúng theo đường cong điền không gian Cách này cho phép chia nhỏ các đối tượng không gian thành nhiều đối tượng trong không gian một chiều, từ đó có thể áp dụng các phương pháp lập chỉ mục một chiều như B+-tree.
- Chia nhỏ không gian thành những phần không chồng nhau: o Lặp đối tượng: Không gian k chiều được chia thành nhiều miền không chồng nhau Các không gian con này sau đó được chỉ mục Định danh một đối tượng được lưu tại mọi không gian con mà nó giao với Như vậy id của một đối tượng có thể được lưu ở nhiều nơi o Cắt đối tượng: Không gian được chia nhỏ như cách lặp đối tượng, tuy nhiên, thay vì lặp id của đối tượng, đối tượng được chia nhỏ thành nhiều phần không giao nhau sao cho mỗi phần nằm gọn trong một không gian con Các phần đối tượng con này được đánh chỉ mục như các đối tượng riêng rẽ
34 Ưu điểm của phương pháp chia nhỏ không gian thành các phần không giao nhau như trên có lợi thế là có thể áp dụng trực tiếp các giải thuật chỉ mục thông thường Tuy nhiên khi các đối tượng phân bố không đều và quá dày đặc tại một khu vực nhất định thì phương pháp này gặp bất lợi,
- Chia nhỏ không gian thành các phần có thể giao nhau: ý tưởng căn bản là chia dữ liệu theo cách phân cấp thành một số có thể quản lý được các thành phần con Thay vì hỗ trợ các không gian con không chồng nhau, hướng tiếp cận này cho phép các không gian con có thể chồng lên nhau, do đó đủ lớn để chứa trọn bất kì đối tượng dữ liệu nào Các không gian này được tổ chức theo một mô hình phân cấp Vấn đề cốt yếu của cách tiếp cận này là giảm thiểu phần giao nhau giữa các không gian con, nhờ đó loại bỏ nhiều trường hợp phải thử khi tìm kiếm dữ liệu
3.2.1.1 Kĩ thuật dựa trên cây nhị phân - kd-Tree
Cây tìm kiếm nhị phân là cấu trúc dữ liệu cơ bản dùng để mô tả dữ liệu mà giá trị được chỉ mục theo thứ tự tuyến tính Ý tưởng chia đôi không gian theo đệ quy được sử dụng trong nhiều bài toán khác nhau Kd-Tree là cấu trúc chỉ mục áp dụng ý tưởng này để trả về kết quả phù hợp.
Kd-Tree [19], một cây tìm kiếm k chiều, được đề xuất bởi Bentley để index dữ liệu nhiều thuộc tính Một node trong cây có 2 mục đích: miêu tả một đối tượng dữ liệu và hướng của tìm kiếm Một số discriminator (nhận giá trị từ 0 đến k - 1), cho biết tại node hiện tại thì khóa là thuộc thuộc tính nào (vi dụ : dis = 0 thì khóa hiện tại là chiều x, dis = 1 thì khóa hiện tại là chiều y, với trường hợp k = 2) Một node P có 2 node con, node con bên trái LOSON(P) và node con bên phải HISON(P) Nếu giá trị discriminator tại P là j thì giá trị thuộc tính j của tất cả các node nằm bên LOSON(P) phải nhỏ hơn giá trị thuộc tính j tại P và giá trị thuộc tính j của tất cả các node bên cây con HISON(P) phải lớn hơn hoặc bằng giá trị thuộc tính j của P
35 Kd là chủ đề của nhiều nghiên cứu trong nhiều năm liền Nhiều phiên bản khác nhau của kd-tree được đề xuất nhằm giải quyết các bài toán như: phân nhóm, tìm kiếm, lưu trữ hiệu quả và cân bằng tải Nhược điểm của kd-Tree là quá trình xóa một node khỏi cây rất phức tạp và tốn nhiều bước và độ cân bằng của cây phụ thuộc vào thứ tự insert dữ liệu, trong trường hợp xấu nhất quá trình tìm kiếm trên cây có thể trở thành quá trình tìm kiếm tuần tự
Hình 3 Không gian đƣợc chia ra bởi kd-Tree
3.2.1.2 Kĩ thuật dựa trên B-Tree - R-Tree
B+-Tree đã và đang được sử dụng rộng rãi trong các hệ thống nặng về dữ liệu để khai thác khả năng chỉ mục dữ liệu của nó Đặc tính mạnh mẽ của B+-Tree là tính cân bằng chiều cao, làm cho B+-Tree trở thành phương tiện lý tưởng để truy xuất dữ liệu, trong
36 đó dữ liệu được truy xuất theo đơn vị từng trang nhằm làm giảm các tác truy vụ truy xuất đĩa cứng
R-Tree[1] là một phiên bản B-Tree được tổng quát hóa thành nhiều chiều, giữ lại đặc tính cân bằng chiều cao Giống như B-Tree, việc thêm và xóa các đối tượng có thể dẫn đến việc chia hoặc gộp các node R-Tree đã nhận được nhiều quan tâm và nghiên cứu vì nó là một trong những cấu trúc đầu tiên được phát triển để đánh chỉ mục cho các đối tượng địa lý có kích thước (không chỉ là điểm trong không gian mà còn có thể là các dạng hình học khác), ngoài ra còn vì cấu trúc của nó được định nghĩa đơn giản nhưng cũng rất chặt chẽ Nhiều bài báo về cấu trúc chỉ mục cho thông tin địa lý dùng R-Tree làm mốc để so sánh hiệu suất
Mỗi node lá chứa một con trỏ đến đối tượng dữ liệu và một khối chữ nhật k chiều bao bọc hoàn toàn đối tượng dữ liệu đó về mặt hình học (có thể hình dung khối chữ nhật này là khối nhỏ nhất chứa hoàn toàn đối tượng dữ liệu) Đối với các node không phải là node lá, mỗi entry chứa một con trỏ trỏ đến một node con ở mức thấp hơn kèm theo một khối chữ nhật là khối nhỏ nhất bao toàn bộ dữ liệu của nhánh bắt đầu bằng node con đó
Hình 4 Cấu trúc phân cấp của một R-Tree
Hình 5 Cách phân chia mặt phẳng 2 chiều thành các phần có thể giao nhau của R-Tree
Xem xét truy vấn sau: liệt kê tất cả đối tượng dữ liệu giao với một khối chữ nhật cho trước Giải thuật tìm kiếm bắt đầu từ gốc của cây, ở mỗi node, thuật toán xem xét xem node nào có mbb(minimum bounding box) giao với khối chữ nhật trong truy vấn thì áp dụng giải thuật này một cách đệ qui cho node đó Khi giải thuật chạy đến node lá, mỗi đối tượng trong node lá được lấy ra xem xét xem có thỏa mãn yêu cầu của truy vấn hay không, nếu có thì thêm vào kết quả trả về Để thêm một đối tượng, cây được duyệt qua và tất cả các mbb trong node - không phải node lá - hiện tại đều được xem xét Ràng buộc sau được sử dụng để chọn node con để thêm đối tượng vào: đối tượng sẽ được thêm vào node con sao cho phần diện tích của mbb của node con đó tăng thêm ít nhất (có thể phần tăng thêm bằng 0 nếu đối tượng nằm trọn trong mbb của node con) Quá trình sẽ được thực hiện đệ quy như vậy cho
Một số kĩ thuật cân bằng tải
3.2.2.1 Cách phân tải của Oracle và phương pháp phân cụm dữ liệu để tăng hiệu suất xử lý song song trên khối lượng dữ liệu địa lý lớn:
Các hệ thống quản lý cơ sở dữ liệu của Oracle có thị phần lớn nên việc nghiên cứu và phân tích phương pháp phân phối của hệ thống Oracle là rất hữu ích Oracle phân vùng dữ liệu dựa trên tọa độ X, tọa độ Y hoặc kết hợp cả X và Y, chia vùng địa lý của các đối tượng dữ liệu thành nhiều vùng con Các đối tượng dữ liệu trong một vùng con được lưu trữ trên một đơn vị lưu trữ cụ thể Tuy nhiên, phương pháp của Oracle không cân nhắc đến yếu tố gần nhau về mặt địa lý, dẫn đến việc các đối tượng dữ liệu nằm gần nhau có thể được lưu trữ trên các đơn vị lưu trữ khác nhau, trong khi các đối tượng dữ liệu trên cùng một đơn vị lưu trữ có thể lại không gần nhau.
Trong [9], Yong Jie Wang et.al đề xuất giải pháp phân tán dữ liệu dựa trên phương pháp Hilbert Curve nhằm cải thiện các nhược điểm của thuật toán của Oracle
Phương pháp này như sau:
- Dùng phương pháp Hilbert Curve [10] để chuyển phần thông tin địa lý (2 chiều) thành thông tin một chiều
- Chia dữ liệu thành n phần (n là số máy tính trong hệ thống) dựa trên thông tin 1 chiều có được từ bước trên
- Xây dựng một hệ thống chỉ mục phân tán dựa trên R Tree gọi là PGSIR-tree
- Quá trình tìm kiếm dữ liệu có thể được thực hiện song song tại nhiều máy cùng lúc
Cơ chế song song hóa quá trình tìm kiếm dữ liệu được thực hiện nhờ các node đặc biệt gọi là replica, như mô tả trong hình dưới, hình ảnh được trích từ bài báo:
Hình 7 Chỉ mục dữ liệu nhờ các Replica
Bài báo cũng mô tả thuật toán để cập nhật thông tin index cho các replica khác mỗi khi một replica nào đó được truy vấn, nhờ đảm bảo tính chặt chẽ trong toàn hệ thống chỉ mục Bài báo cũng trình bày một vài kết quả thử nghiệm cho thấy hiệu suất cao hơn giải thuật của Oracle
Tuy nhiên, để áp dụng vào hệ thống GBStore thì ta thấy có một số vấn đề sau:
- Số máy tính trong hệ thống phải biết trước
- Dữ liệu được cung cấp từ đầu trước khi dữ liệu được gom nhóm và xây dựng hệ thống chỉ mục
Như vậy ta thấy hệ thống không phù hợp với bài toán vì không có khả năng xử lý dữ liệu đầu vào liên tục, cũng không đưa ra phương pháp tái cân bằng tải khi dữ liệu đầu vào có phân bố địa lý không đều Ngoài ra quá trình chuyển thông tin từ 2 chiều qua 1 chiều cũng làm mất một số thông tin ban đầu gây khó khăn trong việc hiện thực một số giải thuật tìm kiếm khác dựa trên thuộc tính địa lý
3.2.2.2 Chỉ mục Spatio-temporal dựa trên các cơ sở dữ liệu No-Sql phân tán
Trong [11], Anthony Fox, Chris Eichelberger, James Hughes và Skylar Lyon đưa ra một phương pháp chỉ mục dữ liệu dựa trên thông tin địa lý và thời gian (Spatio- temporal) dựa vào cơ chế phân tán có sẵn của các DBMS thuộc loại No-Sql, cụ thể là Accumulo
Apache Accumulo được xây dựng theo ý tưởng thiết kế BigTable, thêm phần bảo mật ở mức cell và một mô hình lập trình từ phía server (server side) Hình dưới miêu tả cấu trúc của một cặp key-value trong Accumulo:
Hình 8 Cấu trúc một cặp key-value Ý tưởng của phương pháp này bao gồm các phần:
- Sử dụng phương pháp GeoHash [12] để chuyển thông tin địa lý thành một chuỗi nhị phân Chuỗi nhị phân này được dùng để chỉ mục theo địa lý Thời gian được mã hóa theo dạng „yyyyMMddhh‟ Bằng cách sử dụng Geohash 35bit và chuỗi thời gian như trên, hệ thống chia dữ liệu thành các khối lập phương có một mặt biểu diễn địa lý có diện tích 150m 2 và cạnh kia biểu diễn thời gian có giá trị 1 giờ GeoHash chia không gian thành các ô tăng theo thứ tự z (z-order), trong khi đó chuỗi thời gian tăng một cách tuyến tính, kết hợp 2 giá trị này lại tạo thành một chuỗi có thứ tự một chiều nhưng lấp đầy không gian 3 chiều (không- thời gian)
44 - Xét trường hợp insert một mẩu dữ liệu tương ứng với một điểm không gian và một thời điểm Tọa độ của điểm được biểu diễn bởi một chuỗi GeoHash 35bit (được mã hóa thành một chuỗi 7 kí tự bằng phương pháp mã hóa Niemeyer), và thông tin thời gian được biểu diễn bằng chuỗi „yyyyMMddhh‟ Hai chuỗi này - một cho địa lý, một cho thời gian - mỗi chuỗi được chia làm 2 và phân bố vào các thành phần của cấu trúc khóa theo cách dưới đây: o Khóa hàng (row key): được tạo ra bằng cách ghép 3 chuỗi lại với nhau:
Chuỗi đầu tiền gọi là bin number, trợ giúp cho quá trình phân tải
Giả sử không có bin number, như ta đã biết dữ liệu được chia thành đơn vị nhỏ nhất là 150m 2 trong khoảng thời gian 1 tiếng Có thể sẽ có khu vực có nhiều dữ liệu hơn nới khác (như trung tâm thành phố) Bin number này sinh một cách ngẫu nhiên, giúp cho dữ liệu tại những vùng (và cả thời gian) có mật độ dữ liệu dày đặc được phân tán ngẫu nhiên trên nhiều server Quá trình shard dữ liệu này do Accumulo thực hiện
Kí tự đầu tiên của GeoHash
Chuỗi biễu diễn thời gian đến mức tháng
Ví dụ, chuỗi "01u201205" có bin number là 01, không gian được bao bởi hình chữ nhật tương ứng với ký tự u, thời gian là tháng 5 năm 2012 Column Family sẽ chứa 3 ký tự tiếp theo của chuỗi GeoHash, Qualifier Key sẽ chứa id của dữ liệu, phần còn lại của chuỗi GeoHash và phần còn lại của chuỗi thời gian.
Hình 12 mô tả cách phân bổ GeoHash và chuỗi thời gian vào các thành phần của cấu trúc chỉ mục của Accumulo Hình được lấy từ bài báo
Sử dụng Accumulo cho mục đích phân tải dữ liệu cho phép tận dụng tối đa cơ chế phân tải sẵn có của Accumulo, giúp đơn giản hóa quá trình triển khai và tiết kiệm thời gian thực hiện các thuật toán phân tán Hệ thống cũng xử lý hiệu quả phân tải dữ liệu theo cả không gian và thời gian, đảm bảo tính khả dụng và hiệu suất cao.
Tuy nhiên giải pháp này không cho người dùng có thể tìm kiếm một cách hữu hiệu theo id của dữ liệu Id này không nằm trong phần row key, do đó các mẫu dữ liệu có id gần nhau có thể phân tán rải rác trên nhiều server Như vậy giải pháp kém hữu hiệu khi người dùng cần theo dõi thông tin từ một thiết bị cụ thể nào đó
Hình 9 Mã hóa không-thời gian vào các trường của khóa index
Kĩ thuật index dữ liệu đa thuộc tính
3.2.3.1 MAAN (Multi-Attribute Addressable Network) - mạng tìm kiếm dữ liệu đa thuộc tính phục vụ các dịch vụ thông tin phân tán Đối với bài toán đã cho, ta thấy việc cần thiết của việc tìm kiếm dữ liệu không chỉ dựa trên mỗi thuộc tính địa lý mà còn các thuộc tính khác nữa Ví dụ điển hình là theo dõi hành vi của một phương tiện với id nào đó, hoặc có vận tốc nằm trong khoảng nào đó
MAAN[4] đề xuất phương pháp tìm kiếm dữ liệu theo nhiều thuộc tính dựa trên hệ thống Chord[6] Như ta đã biết Chord là một dịch vụ cung cấp khả năng tìm kiếm dữ liệu trên một cụm máy tính nhờ vào một khóa k - được cung cấp khi dữ liệu được đưa vào hệ thống (hoạt động như một bảng hash khổng lồ phân tán trên nhiều máy tính)
Tuy nhiên việc tìm kiếm dữ liệu dựa trên chỉ một khóa k là chưa đủ, giả sử Client muốn đưa dữ liệu vào hệ thống với lệnh sau: register name=pioneer && url=gram://pioneer.isi.edu:8000 && os-type=linux && cpu-speed00MHz && memory-sizeQ2M Sau đó, Client muốn truy vấn dữ liệu theo điều kiện được mô tả như lệnh sau: search os-type=linux && 800MHz
