ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

KHOA ĐIỆN – ĐIỆN TỬ

BÀI TẬP LỚN THIẾT KẾ VÀ PHÁT TRIỂN ỨNG DỤNG IoT

EVALUATION OF DATABASE ANTELOPE IN CONTIKI

Giảng viên hướng dẫn: Nguyễn Khánh Lợi

Sinh viên thực hiện:
Phạm Tùng Hải : 2013080
Vũ Quốc Việt : 2015052
Nguyễn Thành An : 2012561
Phạm Đại Phú : 2014144
Hoàng Văn Huy : 2013288

Tp. Hồ Chí Minh, tháng 12 năm 2023

BÁO CÁO KẾT QUẢ LÀM VIỆC NHÓM

Họ và tên MSSV Đóng góp

Phạm Tùng Hải 2013080 100%
Vũ Quốc Việt 2015052 100%
Nguyễn Thành An 2012561 100%
Phạm Đại Phú 2014144 100%
Hoàng Văn Huy 2013288 100%

2
MỤC LỤC

1. LÝ THUYẾT .......................................................................................................... 4

1.1. Giới thiệu ................................................................................................................. 4

1.2. Mục tiêu ................................................................................................................... 4

1.3. Kiến trúc - Antelope ................................................................................................. 4

1.4. Thuật ngữ ................................................................................................................. 5

2. MÔ PHỎNG VÀ ĐÁNH GIÁ ................................................................................ 6

2.1. Đánh giá năng lượng tiêu thụ của Antelope .............................................................. 7

2.2. Đánh giá truy vấn nội bộ ........................................................................................ 11

2.3. Đánh giá truy vấn từ xa .......................................................................................... 14

2.4. Đánh giá các loại Data Indexing ............................................................................. 17

KẾT LUẬN ................................................................................................................... 21

TÀI LIỆU THAM KHẢO ............................................................................................ 22

3
1. LÝ THUYẾT
1.1. Giới thiệu
Antelope là một hệ thống quản lý cơ sở dữ liệu cho nút cảm biến, mang lại những
lợi ích vượt trội so với các hệ thống hiện tại. Sử dụng Antelope, người dùng có thể tạo ra
cơ sở dữ liệu mới và truy vấn dữ liệu phức tạp một cách động. Với chỉ mục MaxHeap,
Antelope cung cấp khả năng chèn và truy vấn các tập dữ liệu lớn với chi phí năng lượng
rất thấp. Ngoài ra, Antelope còn ẩn giấu các chi tiết I/O cấp thấp của bộ nhớ flash để giúp
cho nhà phát triển ứng dụng dễ dàng hơn trong việc xây dựng ứng dụng. LogicVM là một
tính năng đặc biệt của Antelope, cung cấp một kiến trúc máy ảo mới lạ để phân tích và
thực thi logic mệnh đề được biểu diễn dưới định dạng Byte-code (Bytecode, còn được gọi
là portable code hoặc p-code, là cách thức lưu trữ dạng mã các chỉ thị (instructions - các
opcode) trong lập trình máy tính, được thiết kế để phần mềm thông dịch thực hiện hiệu
quả trên nền tảng máy ảo). Với LogicVM, Antelope có thể thực hiện các truy vấn lựa
chọn quan hệ nhanh hơn gấp đôi so với phân tích lặp lại, giúp tối ưu hóa hiệu suất của hệ
thống. Bằng cách biên dịch các truy vấn và thực thi chúng ở trên máy ảo, hiệu suất của
các truy vấn lựa chọn quan hệ tăng theo một bậc độ lớn so với việc phân tích cú pháp lặp
lại.
1.2. Mục tiêu
Qua việc demo, nhóm sẽ tìm hiểu ngắn gọn cách thức triển khai Antelope trong hệ
điều hành Contiki bằng cách thực hiện một số đoạn code cơ bản. Tiếp theo, nhóm sẽ mô
phỏng được cách sử dụng database client và server trong Cooja và biết cách thực hiện một
số truy vấn cơ bản trong cơ sở dữ liệu Antelope. Cuối cùng là đánh giá một số ưu và
nhược điểm của mô hình và kết quả mô phỏng.
1.3. Kiến trúc - Antelope
Antelope bao gồm 8 khối được sắp xếp như hình dưới đây

Hình 1.1: Kiến trúc Antelope

4
 Query processor (khối xử lý truy vấn): phân tích cú pháp truy vấn AQL (ngôn ngữ
truy vấn dùng cho Antelope).
Privacy control: check xem lệnh truy vấn có được phép hay không.
Logic VM: thực thi việc truy vấn.
Database kernel: lưu trữ logic của cơ sở dữ liệu và điều phối việc thực hiện truy vấn.
Index abstraction: lưu trữ các chỉ số logic
Indexer process: xây dựng các chỉ số từ data sẵn có.
Storage abstraction: chứa tất cả các logic lưu trữ.
Result transformer : hiển thị kết quả của việc truy vấn để chương trình dễ sử dụng.

1.4. Thuật ngữ

Antelope sử dụng các thuật ngữ tiêu chuẩn từ hệ thống quản lý cơ sở dữ liệu quan
hệ. Dưới đây là một vài thuật ngữ quan trọng cần nắm :
(i) Tuple : là một tập hợp các giá trị thuộc tính
(ii) Attribute : các thuộc tính khác nhau về tính chất. Ví dụ : SensorID, Time.
Domain/miền: mỗi thuộc tính có một miền xác định kiểu dữ liệu của các giá trị
thuộc tính đó.
(iii) Relation/ tập hợp : là một tập hợp các bộ dữ liệu có cùng một tập hợp các thuộc
tính
(iv) Primary key/khóa chính : là một trong các thuộc tính mà nó xác định duy nhất
bộ dữ liệu trong một quan hệ.
(v) Cardinality/số lượng phần tử khác nhau của tập hợp: số lượng tuple trong tập
hợp dữ liệu.
Hình 1.2: Hệ thống quản lý cơ sở dữ liệu Antelope

5
2. MÔ PHỎNG VÀ ĐÁNH GIÁ
Để mô phỏng và đánh giá hoạt động của Antelope, ta sẽ sử dụng phần mềm mô
phỏng Cooja và file mô phỏng “netdb.csc” nằm ở mục /contiki/examples/antelope/netdb.
Khi khởi chạy mô phỏng, netdb-server sẽ tự động khởi tạo một cơ sở dữ liệu có relation là
samples gồm 2 attributes: time (domain INT) và hum (domain INT). Database bao gồm
1000 tuples (được định nghĩa bởi biến CARDINALITY) và dữ liệu là các mẫu số nguyên
có giá trị ngẫu nhiên. Nếu không có lỗi gì xảy ra, màn hình Mote output sẽ hiển thị
“Ready to process queries”, lúc này cơ sở dữ liệu đã sẵn sàng để chúng ta có thể truy vấn.
Hình 2.1: Mote output

Để có thể truy vấn vào cơ sở dữ liệu, ta sẽ sử dụng cửa sổ giao diện cho antelope
database client (Mote 51). Thông qua cửa sổ Mote Interface Viewer người dùng có thể
nhập các thông tin vào, Shell process của netdb-client sẽ có nhiệm vụ sử lý các thông điệp
được truyền nối tiếp này hay chính là các lệnh truy vấn và gửi các truy vấn đến netdb-
server (chạy trên Mote 4). Khi máy chủ đã nhận được thông tin và gửi lại phản hồi, các
confirmation message sẽ được in ra trên cửa sổ này.

6
 Hình 2.2: Mote Interface Viewer

Một số câu lệnh có thể sử dụng để tạo các relation, distribute mới, thêm dữ liệu
hay các câu lệnh truy vấn vào cơ sở dữ liệu:
Create relation sensor: - giúp tạo ra một relation mới có tên là sensor. Chúng ta có thể
thay đổi thành bất kì tên nào khác.
Create attribute id domain INT in sensor: - giúp tạo một attribute mới có tên id bên
trong sensor, mang kiểu dữ liệu integer.
Insert (5) into sensor: - thêm dữ liệu vào trong database.
Select count(id) from sensor: - đếm xem tổng số phần tử có trong attribute id.
Select max(id) from sensor: - tìm phần tử có giá trị lớn nhất của attribute id.
Select min(id) from sensor: - tìm phần tử có giá trị nhỏ nhất của attribute id.
2.1. Đánh giá năng lượng tiêu thụ của Antelope
App powertrace là một ứng dụng của Contiki giúp chúng ta có thể đo lường năng
lượng. Để sử dụng được app powertrace, chúng ta cần thêm thư viện “powertrace.h” vào
file netdb-client.c và sửa đổi trong Makefile.

7
 Hình 2.3: Makefile

Chúng ta sẽ thêm dòng lệnh powertrace_start(CLOCK_SECOND*10); vào trong

shell_process. Với mỗi chu kì 10s, các thông số về năng lượng sẽ được in lên cửa sổ Mote
Interface Viewer.
Hình 2.4: Các thông số được in ra sau mỗi 10s

Để biết được từng thông số trên có ý nghĩa gì, ta truy cập vào mục
/contiki/apps/powertrace/powertrace.c và xem hàm powertrace_print(char * str). Ở đây, ta
chỉnh sửa thông số thời gian để có thể hiện từng thời điểm 10s, 20s, 30s, … thay cho số
tick tại thời điểm đó.
Hình 2.5: Hàm void powertrace_print(char *str)

8
 Trong bài mô phỏng này, chúng ta sẽ khảo sát ở chế độ nulldrc_driver. Chúng ta sẽ
đánh giá lần lượt các giá trị all_CPU, all_LPM, all_RX theo chu kì 10s, sau đó sẽ thu
được năng lượng tiêu thụ của CPU, LPM, RX theo công thức:
𝑎𝑙𝑙 _ 𝐶𝑃𝑈(𝑐ℎ𝑢𝑘𝑦𝑠𝑎𝑢)− 𝑎𝑙𝑙 _ 𝐶𝑃𝑈(𝑐ℎ𝑢𝑘𝑦𝑡𝑟𝑢𝑜𝑐) ∗ 0.33 ∗3
CPU: (mW)
10∗𝑅𝑇𝐼𝑀𝐸𝑅_𝑆𝐸𝐶𝑂𝑁𝐷
𝑎𝑙𝑙 _ 𝐿𝑃𝑀(𝑐ℎ𝑢𝑘𝑦𝑠𝑎𝑢)− 𝑎𝑙𝑙 _ 𝐿𝑃𝑀(𝑐ℎ𝑢𝑘𝑦𝑡𝑟𝑢𝑜𝑐) ∗ 0.0011 ∗3
LPM: (mW).
10∗𝑅𝑇𝐼𝑀𝐸𝑅_𝑆𝐸𝐶𝑂𝑁𝐷
𝑎𝑙𝑙 _ 𝑅𝑋(𝑐ℎ𝑢𝑘𝑦𝑠𝑎𝑢)− 𝑎𝑙𝑙 _ 𝑅𝑋(𝑐ℎ𝑢𝑘𝑦𝑡𝑟𝑢𝑜𝑐) ∗ 18.8 ∗3
RX: (mW).
10∗𝑅𝑇𝐼𝑀𝐸𝑅_𝑆𝐸𝐶𝑂𝑁𝐷
Với RTIMER_SECOND = 32768 ticks/second
Đối với năng lượng tiêu thụ trong việc truyền tín hiệu, chúng ta lần lượt gửi từng
gói tin một từ mote 51 (client) cho mote 4 (server) ứng với mỗi chu kì để đo all_TX và
tính trung bình trong toàn khoảng 100s (cho rằng mỗi chu kì TX đều tiêu thụ như nhau).

𝑎𝑙𝑙 _ 𝑇𝑋(𝑐ℎ𝑢𝑘𝑦𝑠𝑎𝑢)− 𝑎𝑙𝑙 _ 𝑇𝑋(𝑐ℎ𝑢𝑘𝑦𝑡𝑟𝑢𝑜𝑐) ∗ 17.4 ∗3

TX: (mW).
10∗𝑅𝑇𝐼𝑀𝐸𝑅_𝑆𝐸𝐶𝑂𝑁𝐷
Các gói tin truyền sẽ là các lệnh thêm dữ liệu vào relation samples với các giá trị
tùy ý. Trong samples có 2 domain là hum và time, có thể sử dụng lệnh INSERT (1,1)
INTO samples; để thêm dữ liệu vào relation. Cuối cùng chúng ta sẽ tính được tổng năng
lượng tiêu thụ:
TOTAL=Energy_comsumption(CPU + LPM + RX + TX)
Số liệu thu được từ app Powertrace:
Bảng 2.1: Số liệu thu được từ app Powertrace
Raw Data
Thời điểm all_CPU all_LPM all_RX all_TX
10 13942 313772 327883 101
20 27475 627256 655508 155
30 41034 940713 983133 209
40 54595 1254167 1310758 263
50 68178 1567600 1638383 317
60 81758 1881035 1966008 370
70 95342 2194466 2293634 424
80 108921 2507900 2621259 478
90 122527 2821310 2948884 532

9
 100 136139 3134714 3276509 587
110 149764 3448106 3604134 642

Bảng 2.2: Số liệu sau khi được xử lý

Thời điểm CPU LPM TX RX TOTAL

20 0.04088644 0.00315703 0.00860229 56.3905334 56.4431792
30 0.040965 0.00315676 0.00860229 56.3905334 56.4432575
40 0.04097104 0.00315673 0.00860229 56.3905334 56.4432635
50 0.04103751 0.00315652 0.00860229 56.3905334 56.4433298
60 0.04102844 0.00315654 0.00844299 56.3905334 56.4431614
70 0.04104053 0.0031565 0.00860229 56.3907056 56.4435049
80 0.04102542 0.00315653 0.00860229 56.3905334 56.4433177
90 0.04110699 0.00315629 0.00860229 56.3905334 56.443399
100 0.04112512 0.00315623 0.0087616 56.3905334 56.4435764
110 0.0411644 0.00315611 0.0087616 56.3905334 56.4436156
Trung bình 56.4433605

Hình 2.6: Đồ thị tổng năng lượng tiêu thụ (mW)

10
 Do các mote mô phỏng đang chạy ở chế độ nulldrc_driver, luôn truyền và nhận các
gói tin ở tốc độ dữ liệu tối đa, nên các mote luôn luôn ở trạng thái lắng nghe để nhận các
gói tin, gây tiêu tốn rất nhiều năng lượng. Nếu không xét đến RX thì năng lượng tiêu thụ
CPU, LPM và TX của Antelope rất thấp, chỉ vài cho đến vài chục micro walt (µW ) phù
hợp cho các ứng dụng công thức công suất thấp.
2.2. Đánh giá truy vấn nội bộ
Để đánh giá khả năng tiết kiệm năng lượng từ việc sử dụng cơ sở dữ liệu để truy
vấn cục bộ, chúng ta sẽ thực hiện lần lượt thực hiện 10 mô phỏng đánh giá năng lượng
của antelope trong 60 giây, số lượng gói tin gửi đi sẽ tăng dần từ 1 tới 10 ứng với từng mô
phỏng. Chúng ta sẽ tiếp tục sử dụng app Powertrace trong contiki:

𝑎𝑙𝑙 _ 𝑇𝑋(𝑐ℎ𝑢𝑘𝑦𝑠𝑎𝑢)− 𝑎𝑙𝑙 _ 𝑇𝑋(𝑐ℎ𝑢𝑘𝑦𝑡𝑟𝑢𝑜𝑐) ∗ 17.4 ∗3

 TX: (mW).
60∗𝑅𝑇𝐼𝑀𝐸𝑅_𝑆𝐸𝐶𝑂𝑁𝐷
Số liệu thu được và sau xử lý:
Bảng 2.3: Năng lượng tiêu thụ cho việc truyền tín hiệu (mW)
Packet/min all_TX TX(mW)
1 100
2 154 0.00143372
3 204 0.00132751
4 258 0.00143372
5 308 0.00132751
6 361 0.00140717
7 412 0.00135406
8 464 0.00138062
9 518 0.00143372
10 567 0.00130096
11 620 0.00140717
Trung bình 0.00138062

11
 Hình 2.7: Đồ thị năng lượng tiêu thụ trung bình cho việc truyền tính hiệu

Kết quả thu được đối với ứng dụng thu thập dữ liệu, nếu không tính đến năng
lượng tiêu thụ lớn do hoạt động ở chế độ nulldrc_driver, chúng ta thấy rằng ở từng thời
điểm, khi gói tin tăng thì năng lượng tiêu thụ cũng tăng theo, cụ thể cứ tăng thêm một gói
tin thì năng lượng tiêu thụ trung bình tăng thêm một lượng khoảng 0.00138062 mW. Qua
đó cho thấy mô hình cơ sở dữ liệu của Antelope tiêu thụ năng lượng thấp (chỉ vài chục
µW ), có thể tiết kiệm năng lượng, phù hợp cho các ứng dụng mạng cảm biến công suất
thấp.

Đối với gói tin đầu tiên khi lần đầu gửi lệnh truy vấn từ client (Mote 51) đến server
(Mote 4), năng lượng tiêu thụ để truyền tín hiệu gần như gấp đôi (0.003 mW) so với năng
lượng tiêu thụ trung bình của một gói tin. Đó là do lần đầu truy vấn, giữa các mote vẫn
chưa tìm được đường đi, dẫn đến gói tin không gửi được. Sau khi tìm được đường đi từ
mote 51 đến mote 4 thông qua mote 2, gói tin được gửi lại lần nữa và thành công. Do đã
được định tuyến, mote 51đã ghi nhớ được đường đi nên các gói tin sau được gửi chỉ trong
một lần và thành công, dẫn đến năng lượng tiêu thụ thấp hơn so với gói tin đầu tiên.

12
 Hình 2.9: Lần đầu truy vấn

Hình 2.10: Truy vấn lần sau

Trong mô phỏng này, các mote luôn trong trạng thái lắng nghe nên khả năng thất
thoát các gói tin là rất nhỏ. Nhưng trong các ứng dụng công suất thấp ngoài thực tế, việc
mạng tắt nghẽn hay các mote xảy ra vấn đề phải định tuyến lại dẫn đến việc các gói tin
truyền đi không thành công và phải truyền lại, năng lượng tiêu thụ của Antelope sẽ cao
hơn so với mô phỏng.
13
2.3. Đánh giá truy vấn từ xa
Phần này chúng ta sẽ đánh giá truy vấn từ xa thông qua việc xác định thời gian
phản hồi đối với số lượng tuples nhất định. Để có thể đánh giá, chúng ta thiết lập thử
nghiệm trên relation samples với 2 attribute là time (INT) và hum (INT) đã được tạo sẵn
khi khởi động. Nhóm thu nhận các giá trị cần tìm bằng cách sử dụng các toán tử như:
COUNT, MAX, MIN trong ngôn ngữ truy vấn AQL để đảm bảo rằng việc truy vấn cơ sở
dữ liệu trả về số lượng bộ dữ liệu chính xác. Các cấu trúc truy vấn có dạng như sau: select
count(attribute_name) from samples; với attribute_name là tên của thuộc tính mà chúng ta
cần lấy dữ liệu.
Để có thể xác định được thời gian phản hồi, chúng ta cần thực hiện các câu lệnh truy vấn
trong ngôn ngữ AQL.
Hình 2.11: Kết quả truy vấn

Sau khi gói tin được truyền đi thành công và nhận được phản hồi từ server, chúng
ta sẽ có được thời điểm gói tin truyền đi và thời điểm máy chủ phản hồi. Ở đây, mỗi thời
điểm đang được biểu diễn dưới dạng tổng số tick tại thời điểm đó được xác định bởi hàm
clock_time() trong file netdb-client.c.
Hình 2.12: Shell Process

14
 Vì vậy, công thức để thu được thời gian phản hồi:
𝑅𝐸𝑃𝐿𝑌 𝑇𝐼𝑀𝐸 − 𝑇𝑅𝐴𝑁𝑆𝑀𝐼𝑇 𝑇𝐼𝑀𝐸
(𝑠)
128
Hình 2.13: Thời điểm gửi gói tin

Hình 2.14: Thời điểm phản hồi và kết quả trả về từ máy chủ

Ngoài ra, chúng ta có thể thay đổi số lượng tuples tạo ra trong cơ sở dữ liệu thông
qua thông số CARDINALITY trong file netdb-server.c:
Hình 2.15: Tạo ra 1000 tuples

Thời gian phản hồi thu được ứng với từng số lượng tuples:
Bảng 2.4: Thời gian phản hồi với lần đầu truy vấn

Lần đầu truy vấn

Tuples Transmit Reply Thời gian phản hồi

(s)
1 297 715 3.265625
5 525 839 2.453125
10 2791 3153 2.828125
50 357 750 3.0703125
100 2903 3246 2.6796875
500 199 602 3.1484375
1000 745 1191 3.484375
15
2500 3893 4537 5.03125
5000 6365 6887 4.078125
10000 13731 14747 7.9375

Bảng 2.5: Thời gian phản hồi với các lần truy vấn sau
Lần sau truy vấn
Tuples Transmit Reply Thời gian phản hồi
(s)
1 7239 7261 0.171875
5 2567 2590 0.1796875
10 1183 1206 0.1796875
50 7145 7172 0.2109375
100 973 1005 0.25
500 3783 3854 0.5546875
1000 2737 2857 0.9375
2500 3069 3337 2.09375
5000 5763 6276 4.0078125
10000 10115 11118 7.8359375

Hình 2.16: Biểu đồ thời gian phản hồi ứng với từng số lượng tuples

16
 Giống như trong mô phỏng 2, ở lần đầu truy vấn, các mote phải thực hiện quá trình
tìm đường đi dẫn đến thời gian phản hồi ứng với từng số lượng tuples khá lâu và có sự
thay đổi không ổn định. Sau khi mạng đã trở nên ổn định, thời gian phản hồi giảm đi đáng
kể và tăng gần như tuyến tính khi số lượng tuples tăng. Ở một số mốc tuples, khi thực
hiện truy vấn còn trả về kết quả Failed to send packet: time out, phải thực hiện truy vấn
nhiều lần mới thu được phản hồi.
Hình 2.17: Gói tin không gửi đi được

Trong thực tế, thời gian phản hồi còn bị ảnh hưởng bởi nhiều yếu tố như quá trình di
chuyển gói tin giữa các mote, tắc nghẽn mạng, quá trình định tuyến mới khi các mote xảy
ra hư hỏng, gói tin không thể gửi được phải gửi lại.
2.4. Đánh giá các loại Data Indexing
Một chỉ mục (Index) là một cấu trúc dữ liệu phụ trợ với mục đích tối ưu hóa thực
thi các truy vấn cơ sở dữ liệu bằng cách giới hạn tập hợp các tuple cần được xử lý. Quản
trị cơ sở dữ liệu chọn các thuộc tính (atrribute) nào cần tạo chỉ mục dựa trên các ứng dụng
dự kiến của cơ sở dữ liệu. Một chỉ mục lưu trữ một cặp key – value, trong đó key chỉ định
một giá trị thuộc tính và value chỉ định vị trí của một hoặc nhiều tuple có giá trị thuộc tính
đó. Khi thực hiện một truy vấn liên quan đến một điều kiện trên thuộc tính đã được chỉ
mục, hệ thống cơ sở dữ liệu có thể sử dụng để nhanh chóng định vị các tuple liên quan
thay vì quét toàn bộ bảng. Điều này cải thiện hiệu suất truy vấn, đặc biệt là trên các bảng
lớn.
Ở đây, chúng ta sẽ mô phỏng 2 kiểu cấu trúc dữ liệu phụ trợ là INLINE Index và
MAXHEAP Index. Maxheap index sử dụng cấu trúc heap nhị phân tối đa, cho phép ánh

17
xạ tự nhiên đến các tệp mở rộng động trong hệ thống tệp cơ sở dữ liệu. Đối với thuộc tính
đã được chỉ mục, việc triển khai chỉ mục lưu trữ hai tệp: một bảng mô tả heap và một bộ
chứ tập hợp các bucket. Mô tả heap chứa các nút mô tả phạm vi các giá trị trong bucket,
bộ chứa tập hợp bucket chứa các bucket bao gồm các cặp key – value thực tế của chỉ mục.
Maxheap Index yêu cầu O(n + 4k) bytes bộ nhớ, với n là tổng số node trong heap và k là
tổng số keys trong mỗi node. Maxheap Index thường được sử dụng trong các ứng dụng
mà giá trị cần truy vấn là giá trị lớn nhất hoặc nhỏ nhất trong cơ sở dữ liệu.
Inline Index là một chỉ mục nhẹ, đơn giản là một bao bọc cho các thuật toán tìm kiếm,
hoạt động mà không sử dụng bất kì bộ nhớ ngoài nào và có một footprint không đổi bất
kể số lượng các mục dữ liệu được chỉ mục. Inline Index được thực hiện dưới dạng biến
thể của tìm kiếm nhị phân, truy cập trực tiếp lớp trừu tượng hóa lưu trữ, từ đó nó truy xuất
các bộ nối cụ thể được chỉ mục theo số hàng trong lưu trữ vật lý.
Trong mô phỏng này, chúng ta sẽ tiếp tục thiết lập thử nghiệm trên relation
samples với 2 attribute là time (INT) và hum (INT) đã được tạo sẵn khi khởi động và
đánh giá thời gian phản hồi. Chúng ta sẽ tạo kiểu Inline Index đối với thuộc tính time và
kiểu Maxheap Index đối với thuộc tính hum. Chúng ta sẽ thực hiện 2 truy vấn, đó là đếm
số lượng tuples và tìm giá trị lớn nhất đối với mỗi thuộc tính, từ đó chúng ta sẽ thu được
phản hồi của mỗi kiểu data index ứng với số lượng tuples nhất định. Chúng ta sẽ bỏ qua
quá trình định tuyến, khảo sát thời gian phản hồi khi mạng đã ổn định.
Hình 2.18: Khởi tạo cơ sở dữ liệu

Thời gian phản hồi khi thực hiện đếm số lượng tuples trong thuộc tính với câu lệnh
truy vấn: select count(attribute_name) from samples;
Bảng 2.6: Thời gian phản hồi khi thực hiện đếm số lượng tuples
Thời gian phản hồi (s)
Tuples INLINE Index MAXHEAP Index
5 1.9375 1.9375
10 1.53125 1.53125
18
100 1.5234375 1.5234375
500 1.765625 1.765625
1000 2.0625 2.0625
5000 5.875 5.875
10000 8.8984375 8.8984375

Hình 2.19. Đồ thị biểu diễn độ chênh lệch thời gian phản hồi giữa hai kiểu Index

Thời gian phản hồi khi thực hiện tìm giá trị lớn nhất trong thuộc tính với câu lệnh
truy vấn: select max(attribute_name) from samples;
Bảng 2.7: Thời gian phản hồi khi thực hiện tìm giá trị lớn nhất
Thời gian phản hồi (s)
Tuples INLINE Index MAXHEAP Index
5 1.59546 1.59546
10 1.6203753 1.6203753
100 2.0015843 2.0015843
500 2.3015128 2.3015128
1000 0.5966 0.5625
5000 1.2453788 0.9453125
10000 4.415112 4.015625

Bảng 2.20: Đồ thị biểu diễn độ chênh lệch thời gian phản hồi giữa hai kiểu Index

19
 Với kết quả thu được, với các truy vấn bình thường, cả hai loại Data Indexing đều
cho thời gian phản hồi như nhau. Tương tự vậy với truy vấn để tìm giá trị lớn nhất, trong
khoảng bé hơn 1000 tuples, cả hai đều có thời gian phản hồi như nhau. Nhưng với số
lượng tuples lớn hơn 1000, thời gian phản hồi của kiểu Maxheap nhanh hơn so với kiểu
Inline và tốc độ càng tăng khi số lượng tuples càng lớn. Vậy Maxheap Index phù hợp vơi
các ứng dụng cần truy vấn giá trị lớn nhất với cơ sở dữ liệu lớn nhưng yêu cầu bộ nhớ lớn
hơn so với Inline Index, chúng ta cần xác định rõ mục đích và ứng dụng đang xây dựng
để lựa chọn kiểu cấu trúc dữ liệu phụ trợ hợp lý.

20
 KẾT LUẬN
Dựa trên những nghiên cứu và thử nghiệm đã thực hiện trong đề tài
"EVALUATION OF DATABASE ANTELOPE IN CONTIKI", chúng ta có thể rút ra
một số kết luận quan trọng về các khía cạnh quan trọng của cơ sở dữ liệu Antelope trong
môi trường Contiki.
Đầu tiên, trong việc đánh giá năng lượng tiêu thụ, chúng ta đã thấy rằng Antelope
cung cấp một hiệu suất tốt đáng kể so với các cơ sở dữ liệu khác khi hoạt động trong môi
trường hạn chế về nguồn năng lượng như Contiki. Khả năng tiết kiệm năng lượng của
Antelope đã được xác minh thông qua việc giảm đáng kể lượng nguồn tiêu thụ so với các
hệ thống cơ sở dữ liệu khác.
Thứ hai, trong việc đánh giá truy vấn từ xa, Antelope đã cho thấy khả năng xử lý
các truy vấn từ xa một cách hiệu quả, đáp ứng yêu cầu về thời gian phản hồi và đồng thời
duy trì hiệu suất cao.
Cuối cùng, trong việc đánh giá truy vấn nội bộ, Antelope đã chứng minh khả năng
xử lý dữ liệu nội bộ một cách hiệu quả, cung cấp thời gian truy cập nhanh và đáng tin cậy,
đặc biệt khi hoạt động trong môi trường hạn chế về tài nguyên như Contiki.
Tổng cộng, các kết quả nghiên cứu đã chứng minh rằng Antelope là một lựa chọn
xuất sắc cho việc triển khai cơ sở dữ liệu trong môi trường hạn chế về tài nguyên như
Contiki. Sự kết hợp giữa khả năng tiết kiệm năng lượng, hiệu suất truy vấn từ xa và nội
bộ đã cung cấp cơ sở cho việc sử dụng Antelope trong các ứng dụng IoT và môi trường
có các hạn chế về nguồn lực. Điều này mở ra tiềm năng rất lớn cho việc áp dụng Antelope
trong các ngữ cảnh thực tế và thúc đẩy sự phát triển của các hệ thống IoT thông minh và
hiệu quả năng lượng hơn.
Tuy nhiên, cũng cần lưu ý rằng có thể có những vấn đề cần được tiếp tục nghiên
cứu và cải thiện để tối ưu hóa hiệu suất và tính linh hoạt của Antelope trong các môi
trường IoT cụ thể.

21
TÀI LIỆU THAM KHẢO
1. https://www.researchgate.net/publication/282866479_AntelopeDatabase_Manage
ment
2. _System_-_Contiki
3. https://github.com/contiki-os/contiki/wiki - Contiki Operating System Wiki page
4. Nicolas Tsifftes & Adam Dunkels, A Database in Every Sensor
5. Contiki-NG, Antelope, Antelope — Contiki-NG documentation

22