Phân tán trong Elaticsearch

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
_______________________________________________________________________________

TIỂU LUẬN MÔN HỌC
Đề tài: 7

PHÂN TÁN TRONG ELASTICSEARCH

- Giảng viên hướng dẫn

:

TS. Vũ Tuyết Trinh

- Học viên thực hiện

:

-

Phạm Việt Hưng (CA150110)

-

Đoàn Vũ Giang (CA150108)

-

Võ Thị Hường (CA150111)

- Môn học

:

Cơ sở dữ liệu tiên tiến

- Mã học phần

:

IT6060

- Chuyên ngành

:

Công nghệ thông tin

- Hà Nội: 8/2016 -

MỤC LỤC


- Cơ sở dữ liệu tiên tiến -

2


- Cơ sở dữ liệu tiên tiến DANH MỤC HÌNH VẼ

3


- Cơ sở dữ liệu tiên tiến BẢNG PHÂN CÔNG CÔNG VIỆC

STT

Công việc

Thực hiện

1

Tìm hiểu chung yêu cầu, định hướng tiểu luận

Cả nhóm

2

Phân công nhiệm vụ

Phạm Việt Hưng

3

Tìm hiểu tổng quan về Elasticsearch

Võ Thị Hường
Đoàn Vũ Giang

4

Tìm hiểu về khả năng mở rộng, lưu trữ dữ liệu Võ Thị Hường
phân tán trong Elasticsearch

5

Tìm hiểu về tìm kiếm phân tán, shard và cách Đoàn Vũ Giang
làm việc của shard

6

Cài đặt và so sánh elasticsearch với solr

Phạm Việt Hưng

7

Tổng hợp báo cáo (.doc)

Cả nhóm

8

Nộp tiểu luận

Đoàn Vũ Giang

4

- Cơ sở dữ liệu tiên tiến I.

TỔNG QUAN VỀ ELASTICSEARCH
I.1.

Giới thiệu

Đầu tiên ElasticSearch là một công cụ tìm kiếm (search engine). Mục tiêu của nó là
tạo ra một công cụ, nền tảng hay kỹ thuật tìm kiếm và phân tích trong thời gian thực
(nhanh chóng và chính xác), cũng như cách để nó có thể áp dụng hay triển khai một cách
dễ dàng vào nguồn dữ liệu (data sources) khác nhau.
Nguồn dữ liệu nói ở trên trên bao gồm các cơ sở dữ liệu nổi tiếng như MS SQL,
PostgreSQL, MySQL,... mà nó có thể văn bản (text), thư điện tử (email), pdf,...
ElasticSearch được phát triển bởi Shay Banon và dựa trên Apache Lucene,
ElasticSearch là một bản phân phối mã nguồn mở cho việc tìm kiếm dữ liệu trên máy chủ.
Đây là một giải pháp mở rộng, hỗ trợ tìm kiếm thời gian thực mà không cần có một cấu
hình đặc biệt. Nó đã được áp dụng bởi một số công ty, bao gồm cả StumbleUpon và
Mozilla. ElasticSearch được phát hành theo Giấy phép Apache 2.0.
Một số thông tin về Elasticsearch:
•
•

Elasticsearch là một search engine.
Elasticsearch được xây dựng để hoạt động như một server cloud theo cơ chế của

•
•
•
•

•

RESTful.
Kế thừa và phát triển từ Lucene Apache.
Phát triển bằng ngôn ngữ Java.
Là phần mềm open-source được phát hành theo giất phép của Apache License.
Tương tự như Solr (Apache).
ELASTIC-SEARCH có thể tích hợp được với tất cả các ứng dụng sử dụng các loại

•

•

ngôn ngữ sau.
− Java
− JavaScript
− Groovy
− .NET
− PHP
− Perl
− Python
− Ruby
Những ai đã dùng Elasticsearch :
− Mozilla
− Quora
− SoundCloud
− GitHub
− Stack Exchange
− Center for Open Science
− Reverb

− Netflix

Hệ sinh thái của Elasticsearch rất phong phú, bao gồm:
− Plugins: hỗ trợ hiển thị (VD plugin_head)
− Clients: hỗ trợ nhiều ngôn ngữ lập trình

5


- Cơ sở dữ liệu tiên tiến −
−
−
−

Logstash: hỗ trợ import dữ liệu từ file log
Kibana: hỗ trợ báo cáo thống kê
Hadoop integration: hỗ trợ tích hợp với hadoop
Marvel: hỗ trợ giám sát trạng thái các node

I.2.
•

Các khái niệm trong Elasticsearch

Near Realtime

Elasticsearch là 1 nền tảng Search gần như là thời gian thực, nghĩa là chỉ có 1 độ trễ
nhỏ từ lúc index 1 document cho đến lúc nó có thể được search ra, thường là
khoảng 1 giây.
•

Cluster

Một cluster là 1 tập hợp của 1 hoặc nhiều Nodes mà cùng nhau nắm giữ toàn bộ dữ
liệu và cung cấp các chỉ mục và khả năng search qua tất cả các nodes. Một cluster
được định danh bởi 1 tên duy nhất, mặc định là “elasticsearch”. Tên cluster có thể
cấu hình thay đổi được trong file elasticsearch.yml
Có thể có nhiều clusters độc lập với những cluster name khác nhau
•

Node

Một node là một server riêng, là 1 phần trong Cluster, lưu trữ dữ liệu và tham gia
vào việc lập chỉ mục và search. Một node cũng được định danh bởi 1 tên riêng biệt
khi node khởi động (mặc định bằng tên của 1 nhân vật trong Marvel). Tên node có
thể cấu hình thay đổi được trong file elasticsearch.yml
Mỗi node được thiết lập để join vào 1 cluster nào đó bằng cách khai báo cluster
name. Mặc định nó được join vào “elasticsearch” cluster. Điều đó có nghĩa khi khởi
động 1 vài nodes trong cùng 1 mạng, thì chúng sẽ nhìn thấy nhau và là các nhánh
riêng của 1 cụm chung tên là “elasticsearch”.
Trong 1 cluster có thể có bao nhiêu node cũng được.
•

Index

Một index là 1 tập hợp các documents có đặc điểm chung. Một index được được
định danh bởi tên viết thường (Chú ý: không được viết hoa). Tên này dùng để liên
hệ đến index khi thực hiện tạo index, search, update, delete document trong nó.
Trong 1 cluster có thể chứa nhiều indexes
•

Type
6


- Cơ sở dữ liệu tiên tiến Trong 1 index có thể định nghĩa 1 hoặc nhiều types. Một type là 1 mục/phân vùng
có nghĩa trong index. Một Type được định nghĩa cho document bao gồm 1 số fields.
Ví dụ khi làm blog, có thể định nghĩa 1 type cho dữ liệu user, type khác cho dữ liệu
blog hay type khác cho dữ liệu comment.
•

Document

1 Document là 1 đơn vị thông tin cơ bản để được đánh index. Ví dụ 1 document cho
1 customer, document khác cho 1 sản phẩm hay cho 1 đơn đặt hàng khác.
Document này được format dưới dạng JSON, dạng dữ liệu phổ biến mà tất cả các
ngôn ngữ khác có thể hiểu được.
Trong mỗi index/type, có thể lưu trữ nhiều documents. Chú ý 1 document cần được
gán vào 1 type bên trong index để có thể được đánh index
•

Shard & Replicas

Mỗi index có thể được chia thành nhiều Shards. Mỗi index cũng có thể được sao
lưu nhiều lần. Mỗi khi được nhân bản, mỗi index sẽ có những shards chính và
những shards nhân bản (copy từ shards chính). Số lượng shards và replicas có thể
được khai báo khi tạo index. Sau khi index được tạo, có thể thay đổi số lượng bản
sao bất cứ lúc nào nhưng không thể thay đổi số shards.
Mặc định, mỗi index trong Elasticsearch được phân thành 5 shards chính và 1
replicas nghĩa là nếu trong cluster có 2 nodes thì mỗi index sẽ có 5 shards chính và

5 shards nhân bản, tổng cộng tất cả là 10 shards

I.3.
•

Đặc điểm của ElasticSearch

Real time data & Real time analytics

Elasticsearch là 1 nền tảng Search “gần” thời gian thực, nghĩa là có 1 độ trễ nhỏ từ
lúc index 1 document cho đến lúc nó có thể được search ra, thường là khoảng 1
giây. Tuy gặp một số vấn đề về lưu trữ so với các engine search khác nhưng so sánh
về tốc độ đối với dữ liệu lớn, search ngay sau khi cập nhật dữ liệu Elasticseach hiện
được đánh giá rất cao
•

Auto sharding & replication

Elasticsearch có thể dễ dàng mở rộng chỉ đơn giản bằng cách thêm vào các nodes và nó sẽ

tự động phân mảnh và tạo các bản dự phòng trên các node tham gia vào cùng một
cluster
7


- Cơ sở dữ liệu tiên tiến -

•

RESTful API, Developer-Friendly

RESTful là một cách truyền dữ liệu cực kỳ đơn giản, gọn nhẹ. ElasticSearch hỗ trợ
thêm, xoá, sửa indices thông qua các phương thức HTTP như GET, POST,
DELETE và PUT, hỗ trợ params dưới dạng JSON thay vì chỉ là GET params.

•

Plug and Play

Cài đặt một ElasticSearch server cực kỳ đơn giản. So với các search and index
engine khác thì đây là điều mà khá nhiều người dùng mong đợi. Không cần cấu
hình phức tạp, ElasticSearch sẽ tự động phát hiện các kiểu dữ liệu cơ bản mà ta đưa
vào. Do đó ta chỉ cần tiến hành index tài liệu ngay sau khi cài đặt xong. Tuy nhiên
với các kiểu dữ liệu khác ngoài các kiểu dữ liệu cơ bản, như geo_point, geo_shape
thì chúng ta phải tiến hành mapping.
•

Language Clients

Elastic hỗ trợ cho nhiều ngôn ngữ client như đã giới thiệu phần đầu.

8


- Cơ sở dữ liệu tiên tiến II.

PHÂN TÁN TRONG ELASTICSEARCH
II.1.
II.1.1.

Khả năng mở rộng và vượt qua lỗi

Cluster trống

Hình 1 mô tả 1 cluster với 1 node rỗng, không có dữ liệu và không có các Index,

Hình . Cluster với 1 node rỗng
Node là một server Elasticsearch, trung tâm hoạt động của Elasticsearch. Lưu trữ
toàn bộ dữ liệu để có thể thực hiện công việc lưu trữ và tìm kiếm. Một node là một trường
hợp chạy của Elasticsearch, trong khi một nhóm bao gồm một hoặc nhiều hơn các node với
cluster chỉ ra đang làm việc với nhau để chia sẻ dữ liệu và khối lượng công việc của họ.
Khi node này được thêm vào hoặc gỡ bỏ từ các cluster, các cluster tổ chức lại để truyền bá
các dữ liệu đều.
Một node trong cluster được chọn làm node chính, phụ trách điều khiển thay đổi
cluster toàn giống như việc tạo hoặc xóa một chỉ mục, hoặc thêm hoặc loại bỏ một node từ
cluster. Các node chính không cần phải tham gia vào sự thay đổi bằng văn bản hoặc tìm
kiếm, có nghĩa là có chỉ một node chủ sẽ không trở thành một node cổ chai như phát
triểngiao thông. Bất kỳ node có thể trở thành bậc thầy. Ví dụ môt cluster của chúng tôi chỉ
có một node, do đó nó thực hiện các vai trò chủ.
Khi người sử dụng, chúng ta có thể nói tới bất kỳ node nào trong cluster, cả các node
chính. Mỗi node đều rõ tài liệu ở đâu và có thể chuyển tiếp yêu cầu của người dùng trực
tiếp đến các hạch mà giữ dữ liệu người dùng đang quan tâm. Việc quản lý tiến trình thu
thập các phản hồi từ các node hoặc các node giữ dữ liệu và trả lại kết quả cuối cùng cho
khách hàng. Tất cả được quản lý minh bạch bởi Elasticsearch.

II.1.2.

Cluster health

Trong Elasticsearch có khái niệm cluster health (tạm gọi là "sức khỏe" của cluster). Nhiều

thống kê có thể được theo dõi trong một cluster Elasticsearch, nhưng một điều quan trọng
nhất là sức khỏe cluster, mà các báo cáo trạng thái hoặc là màu xanh lá cây, vàng, hoặc đỏ.
Có thể kiểm tra cluster health bằng câu lệnh:
GET _cluster/health?pretty

Trên một Cluster trống rỗng không có các Index, sẽ trả về kết quả như sau:
{
"cluster_name":"elasticsearch",

9


- Cơ sở dữ liệu tiên tiến "status":"green",(1)
"timed_out":false,
"number_of_nodes":1,
"number_of_data_nodes":1,
"active_primary_shards":0,
"active_shards":0,
"relocating_shards":0,
"initializing_shards":0,
"unassigned_shards":0
}

(1)Trường trạng thái là một trong những trường chúng ta quan tâm nhất.
Kết qủa trả về là một chuỗi json có trường status, đây chính là cluster health. Trường này
nhận 1 trong 3 gía trị:

II.1.3.

•

Red: Vẫn còn primary shard chưa hoạt động.

•

Yellow: Tất cả primary shard đã hoạt động, nhưng vẫn còn replica shard
chưa hoạt động.

•

Green: Tất cả primary shard và replica shard đều hoạt động.
Bổ sung Index

Để bổ sung dữ liệu vào Elasticsearch, chúng ta cần một Index-một nơi để lưu trữ dữ
liệu có liên quan. Trong thực tế, một Index chỉ là một không gian logic chỉ đến một hoặc
nhiều shard vật lý.
Mỗi node sẽ gồm nhiều shard. Shard hoạt động ở mức thấp nhất, đóng vai trò lưu
trữ dữ liệu. Shard có hai loại là primary shard và replica shard..
Shard là làm sao Elasticsearch phân bổ dữ liệu xung quanh các cluster. Hãy suy
nghĩ về những shard như container cho dữ liệu. Các tài liệu được lưu trữ trong những
shard, và những shard được phân bổ cho các node trong cluster. Khi mở rộng hoặc co lại
node lại, Elasticsearch sẽ tự động di chuyển những shard giữa các node để các Cluster vẫn
cân bằng.
Một shard có thể là một primary shard hoặc replica shard.
•

Primary Shard: Dữ liệu được lưu tại 1 primary shard, được đánh index ở
đây trước khi chuyển đến replica shard. Mặc định của Elasticsearch là 5 primary
shard cho một index

•

Replica Shard: Một primary shard có thể không có, hoặc có replica shard.
Vai trò của replica shard đảm bảo khi primary shard có sự cố thì dữ liệu vẫn toàn vẹn
và thay thế được primary shard. Mặc định Elasticsearch là 1 replica shard trên một
primary shard.

Mỗi tài liệu có trong chỉ mục của bạn thuộc về một primary shard duy nhất, nên số lượng
primary shard mà bạn phải xác định số tiền tối đa của dữ liệu mà Index của bạn có thể giữ.

10


- Cơ sở dữ liệu tiên tiến Trong khi không có giới hạn lý thuyết với lượng dữ liệu mà một primary shard có thể nắm
giữ, có một giới hạn thực tế. Cái gì tạo nên kích thước shard tối đa phụ thuộc hoàn toàn
vào trường hợp sử dụng: phần cứng , kích thước và độ phức tạp của tài liệu, làm thế nào
bạn chỉ mục và truy vấn tài liệu, và thời gian đáp ứng mong đợi.
Một replica shards chỉ là một bản sao của một primary shard. Bản sao được sử dụng để
cung cấp các bản sao dự phòng dữ liệu để bảo vệ chống lại các lỗi phần cứng, và để phục
vụ yêu cầu đọc như tìm kiếm hoặc lấy tài liệu.
Số lượng các primary shard trong một Index được cố định tại thời điểm mà một Index
được tạo ra, nhưng số lượng các replica shards có thể được thay đổi bất cứ lúc nào.
Theo mặc định, 5 primary shard cho 1 Index, nhưng với mục đích của cuộc biểu tình này,
chúng tôi sẽ giao chỉ 3 primary shard và một bản sao (một bản sao của tất cả các primary
shard):
PUT/blogs
{
"settings":{
"number_of_shards":3,
"number_of_replicas":1

}

Cluster bây giờ trông giống như hình 2. Tất cả 3 primary shard đã được phân bổ cho
Node 1.

Hình . Một Cluster single-node với một index

Để kiểm tra các cluster-healthy hiện tại, chúng ta sẽ:
{
"cluster_name":"elasticsearch",
"status":"yellow",(1)
"timed_out":false,
"number_of_nodes":1,
"number_of_data_nodes":1,
"active_primary_shards":3,
"active_shards":3,
"relocating_shards":0,
"initializing_shards":0,
"unassigned_shards":3(2)
}

-

Ba replica shards không được giao cho một node.
Tình trạng cluster là yellow màu vàng.

11


- Cơ sở dữ liệu tiên tiến Một clusterhealth màu vàng có nghĩa là tất cả các primary shards đang lên và chạy

(cluster là khả năng phục vụ mọi yêu cầu thành công) nhưng không phải tất cả các replica
shards đang hoạt động. Trong thực tế, cả 3 replica shards hiện đang unassigned, không được
phân bổ cho một node. Nó không có ý nghĩa để lưu trữ các bản sao của cùng một dữ liệu
trên cùng một node. Nếu để mất node đó, thì sẽ mất tất cả các bản sao của dữ liệu.
Chú ý, không bắt buộc primary shard đều nằm ở node master, vì việc phân tán các
primary shard giúp phân tán công đoạn ghi dữ liệu, giúp giảm tải cho một node. Việc lựa
chọn node cho các thao tác đọc được thực hiện bởi thuật toán Round-robin.

II.1.4.

Bổ sung lỗi

Bắt đầu node thứ hai
Để kiểm tra những gì sẽ xảy ra khi thêm một node thứ hai, có thể bắt đầu một node mới
giống như bắt đầu từ cùng một thư mục. Nhiều node có thể chia sẻ cùng một thư mục.
Miễn là node thứ hai có cluster đặt tên cluster.name giống như node đầu tiên (xem tệp
./config/elasticsearch.yml), nó sẽ tự động phát hiện và tham gia các Cluster chạy bằng node đầu
tiên. Nếu không, kiểm tra các bản ghi để tìm ra những gì đã đi sai. Nó có thể là phân bổ đa
phương đó là vô hiệu hóa trên mạng, hoặc là một bức tường lửa ngăn cản các node từ giao
tiếp.
Chạy một node duy nhất có nghĩa là có một điểm duy nhất của thất bại, không có dự
phòng. May mắn thay, để bảo vệ mình khỏi bị mất dữ liệu là để bắt đầu một node khác.
Nếu bắt đầu một node thứ hai, Cluster trông giống như hình 3.

Hình . Hai node cluster- primary và replica shards được phân bổ
Các node thứ hai đã tham gia các Cluster, và ba replica shards đã được phân bổ cho
nó một cho mỗi shard. Điều đó có nghĩa là chúng ta có thể mất đi một trong hai node, và
tất cả các dữ liệu được nguyên vẹn.
Bất kỳ tài liệu mới được lập chỉ mục đầu tiên sẽ được lưu trữ trên một primary
shard, và sau đó sao chép song song với replica shard(s). Điều này đảm bảo rằng dữ liệu có

thể được lấy từ một primary shard hoặc từ bất kỳ bản sao của nó
Các cluster-health hiện nay cho thấy một trạng thái của màu xanh lá cây, có nghĩa
là tất cả 6 shard (cả 3 primary shards và cả 3 replica shards) đang hoạt động với tình trạng:
{
"cluster_name":"elasticsearch",
"status":"green",(1)
"timed_out":false,
"number_of_nodes":2,

12


- Cơ sở dữ liệu tiên tiến "number_of_data_nodes":2,
"active_primary_shards":3,
"active_shards":6,
"relocating_shards":0,
"initializing_shards":0,
"unassigned_shards":0
}

(1) Cluster xanh.

II.1.5.

Mở rộng theo chiều ngang

Nếu chúng ta bắt đầu một node thứ ba, hoặc Cluster tổ chức lại bản thân để trông
giống như Hình 4.

Hình . Ba node cluster-shards đã được phân bổ để lan truyền tải

Một shard từ Node 1 và Node 2 đã chuyển đến Node 3 mới, và có hai shard mỗi node, thay
vì 3. Điều này có nghĩa rằng các tài nguyên phần cứng (CPU, RAM, I / O) của mỗi node
được chia sẻ giữa các shard ít hơn, cho phép mỗi shard để thực hiện tốt hơn.
Một shard là một công cụ tìm kiếm đầy đủ, và có khả năng sử dụng tất cả các nguồn lực
của một node duy nhất. Với tổng số 6 shard (3 primary shard và 3 replicas), Index có khả
năng nhân rộng ra đến tối đa là 6 node, với một shard trên mỗi node và mỗi shard được
tiếp cận với 100% nguồn tài nguyên node của hãng.
Nhưng nếu muốn quy mô tìm kiếm lớn hơn 6 node?
Số lượng các primary shard là cố định tại thời điểm một Index được tạo ra. Có hiệu quả,
con số đó xác định số lượng tối đa của dữ liệu có thể được lưu trữ trong Index. (Số lượng
thực tế phụ thuộc vào dữ liệu, phần cứng và trường hợp sử dụng). Tuy nhiên, đọc yêu cầu
tìm kiếm hoặc tài liệu phản hồi có thể được xử lý bởi một primary shard hoặc bản sao, vì
vậy các bản sao của dữ liệu có thông tìm kiếm nhiều hơn xử lý.
Số lượng các replica shards có thể được tự động thay đổi trên một cluster, cho phép để tăng
hoặc giảm tùy theo nhu cầu đòi hỏi. Hãy tăng số lượng các bản sao từ mặc định của 1-2:
PUT/blogs/_settings
{
"number_of_replicas":2
}

Như có thể thấy trong hình 5, Index blog hiện có 9 đoạn: 3 primary shard và 6 bản sao.
Điều này có nghĩa rằng có thể mở rộng ra tổng số 9 node, một lần nữa với một shard mỗi
node. Điều này sẽ cho phép thực hiện tìm kiếm gấp ba lần so với Cluster ba node ban đầu.
13


- Cơ sở dữ liệu tiên tiến -

Hình . Tăng number_of_replicas 2
Tất nhiên, chỉ có nhiều replica shards trên cùng một số node không làm tăng hiệu suất

của tại tất cả bởi vì mỗi shard có quyền truy cập vào một phần nhỏ tài nguyên node
của hãng. Cần phải thêm phần cứng để tăng thông lượng
Nhưng các bản sao thêm không có nghĩa là có dư thừa: với cấu hình node ở trên,
chúng ta không thể đủ khả năng để mất hai node mà không bị mất bất kỳ dữ liệu

II.1.6.

Khả năng chịu lỗi

Elasticsearch có thể đối phó khi các node lỗi. Nếu tắt node đầu tiên, Cluster giống như
hình 6

Hình . Cluster sau khi bị xóa 1 node
Node bị lỗi là master node. Một cluster phải có một master node để hoạt động một cách
chính xác, do đó, điều đầu tiên mà đã xảy ra là các node được lựa chọn để trở thành node
điều hành: Node 2.
Primary shard 1 và 2 đã bị mất khi Node 1 lỗi và Index không thể đúng chức năng nếu nó
là mất primary shard. Nếu kiểm tra sức khỏe Cluster vào thời điểm này, ta sẽ thấy tình
trạng đỏ: không phải tất cả những primary shard đang hoạt động!
May mắn thay, một bản sao hoàn chỉnh của hai primary shards bị mất tồn tại trên các node
khác, vì vậy điều đầu tiên mà các master node mới đã làm là để thúc đẩy các bản sao của
các shard trên Node 2 và Node 3 là primaries, đưa chúng trở lại vào cluster health màu
vàng.
Vậy tại sao cluster health màu vàng và màu xanh lá cây? Chúng ta có tất cả primary
shards, nhưng muốn hai bản sao của mỗi primary, và hiện chỉ có một bản sao được giao.
Điều này ngăn cản đạt màu xanh, nhưng không quá lo lắng ở đây: xóa Node 2 là tốt, ứng
dụng vẫn có thể tiếp tục chạy mà không mất dữ liệu, vì Node 3 chứa một bản sao của tất cả
các shard.
Nếu chúng ta khởi động lại Node 1, cluster sẽ có thể phân bổ các replica shards mất tích,
dẫn đến tình trạng giống như được mô tả trong hình 5. Nếu Node 1 vẫn có bản sao của

14


- Cơ sở dữ liệu tiên tiến những shard cũ, nó sẽ cố gắng để tái sử dụng chúng, sao chép lại từ các primary shard chỉ
các tập tin đã thay đổi trong khi chờ đợi.

II.2.
II.2.1.

Lưu trữ dữ liệu phân tán

Định tuyến một tài liệu với Shard

Gỉa sử chúng ta đã có một sơ đồ cluster như hình trên, với vị trí primary shard, replica
shard đã cố định. Vậy với một bản ghi (document) mới, chúng ta sẽ lưu nó ở shard nào ?
shard = hash(routing) % number_of_primary_shards
Các giá trị router là một chuỗi tùy ý , mặc định là documents_id mà còn có thể được thiết
lập để một giá trị tùy chỉnh. Chuỗi định tuyến này được truyền thông qua một hash, hash là
một hàm tính toán cố định của Elasticsearch, routing là 1 đoạn text
duy nhất theo document, thường là _id của document đó. number_of_primary_shards là số
lượng primary shard của cluster. Gía trị shard này là đi kèm với document, nó được dùng
để xác định shard nào sẽ lưu document và cũng dùng để cho routing, vì bạn sẽ tìm
document theo id của nó. Đó là lý do chúng ta không thể thay đổi số lượng primary shard,
nếu không công thức trên sẽ không cho kết qủa giống như lúc ban đầu.
Điều này giải thích tại sao số primary shards có thể được thiết lập chỉ khi một Index
được tạo ra và không bao giờ thay đổi: nếu số lượng các primary shard thay đổi trong
tương lai, tất cả các giá trị định tuyến trên sẽ là không hợp lệ và các văn bản sẽ không bao
giờ được tìm thấy.
Người dùng đôi khi nghĩ rằng có một số cố định của các primary shard làm cho nó
khó khăn để mở rộng quy mô ra một Index sau đó. Trong thực tế, có những kỹ thuật mà

làm cho nó dễ dàng để mở rộng ra và khi bạn cần.
Tất cả các tài liệu API (get, index, delete, bulk, update, và mget)chấp nhận một
tham số định tuyến có thể được sử dụng để tùy chỉnh các bản đồ shard tài liệu. Một giá trị
định tuyến tùy chỉnh có thể được sử dụng để đảm bảo rằng tất cả các tài liệu liên quan , ví
dụ , tất cả các văn bản thuộc cùng một người dùng được lưu trữ trên shard tương tự.

II.2.2.

Làm thế nào tương tác Primary và Replica Shard

Chúng ta có một cluster gồm 3 node. Nó chứa một Index gọi là blogs
có hai primary shard. Mỗi primary shard có hai bản sao. Bản sao của các
shard cùng không bao giờ được giao cho cùng một node, do đó cluster trông
giống như Hình 7.

15


- Cơ sở dữ liệu tiên tiến Hình . Một cluster cùng 2 node và 1 Index

Chúng ta có thể gửi các yêu cầu của cho bất kỳ node trong cluster. Mỗi
node là hoàn toàn có khả năng phục vụ mọi yêu cầu. Mỗi node đều biết vị trí
của mỗi tài liệu trong cluster và do đó có thể chuyển tiếp yêu cầu trực tiếp đến
node yêu cầu. Trong ví dụ sau đây sẽ gửi tất cả các yêu cầu để Node 1 , mà
chúng tôi sẽ đề cập đến như là node yêu cầu .
Khi gửi yêu cầu, đó là thực hành tốt để round-robin qua tất cả
các node trong cluster, để lan truyền tải .
II.2.3.

Tạo, idexing và xóa một tài liệu

Tạo, chỉ mục, và xóa các yêu cầu là hoạt động ghi phải được hoàn tất thành
công trên primary shard trước khi chúng có thể được sao chép vào bất kỳ replicas
shard liên quan, như thể hiện trong hình 8.

Hình .Tạo, chỉ mục và xóa một tài liệu

Dưới đây là trình tự các bước cần thiết để hoàn thành việc tạo, chỉ mục, hoặc xóa
một tài liệu trên cả hai primary shard và bất kỳ một replica shards nào.
1. Khách hàng gửi một yêu cầu tạo, chỉ mục, hoặc xóa đến Node 1_master
2. Sau khi xác định được primary shard là 0, request sẽ được gửi đến node
3, nơi chứa P0.
3. Node 3 thực hiện request và xử lý dữ liệu. Sau khi thành công, nó gửi
tiếp request đến các replica shard ở Node 1 và Node 2 để đảm bảo dữ
liệu thống nhất giữa các node.
Vào thời điểm khách hàng nhận được một phản ứng thành công, sự thay
đổi tài liệu đã được thực thi trên primary shard và trên tất cả các replicas shard.
Thay đổi của bạn được an toàn.
Có một số thông số yêu cầu tùy chọn cho phép bạn để ảnh hưởng đến quá
trình này, có thể tăng cường hiệu năng với chi phí của bảo mật dữ liệu. Các tùy
chọn này ít khi được sử dụng vì Elasticsearch là thực sự nhanh, nhưng họ được giải
thích ở đây vì lợi ích của sự hoàn chỉnh :
 Replication
16


- Cơ sở dữ liệu tiên tiến Giá trị mặc định cho replication là sync. Điều này gây ra những primary shard để
chờ đợi để được trả lời thành công từ những replica shards trước khi trở về .
Nếu bạn đặt nhân rộng để async, nó sẽ trở lại thành công cho khách hàng ngay sau
khi các yêu cầu đã được thực hiện trên các primary shard. Nó vẫn sẽ gửi yêu cầu tới

các bản sao, nhưng bạn sẽ không biết liệu các bản sao đã thành công.
Tùy chọn này được đề cập cụ thể đến khuyên bạn không dùng nó. Các sync
replication mặc định cho phép Elasticsearch để gây áp lực trở lại trên bất kỳ hệ
thống được cung cấp với dữ liệu. Với async replication, nó có thể quá tải
Elasticsearch bằng cách gửi yêu cầu quá nhiều mà không chờ hoàn thành..
 Tính nhất quán
Theo mặc định, các primary shard không cần một quorum, hoặc đa số, các bản sao
shard (trong đó một bản sao shard có thể là primary hoặc một replica shards) có sẵn
trước khi thậm chí cố gắng một hoạt động viết. Điều này là để ngăn chặn dữ liệu
văn bản cho "mặt trái" của một phân vùng mạng. Một số đại biểu cần được xác định
như sau:
int( (primary + number_of_replicas) / 2 ) + 1
Các giá trị được phép nhất quán là một (chỉ là primary shard), tất cả (primary và tất
cả bản sao), hoặc quorum mặc định, hoặc đa số, các bản sao shards.
Lưu ý rằng các number_of_replicas là số bản sao quy định trong các thiết lập
chỉ mục, không phải số lượng bản sao có đang hoạt động. Nếu bạn đã xác định rằng
một Index cần phải có ba bản sao, một đại biểu sẽ được như sau:
int( (primary + 3 replicas) / 2 ) + 1 = 3
Nhưng nếu bạn bắt đầu chỉ có hai node, sẽ có đủ số lượng bản sao shard hoạt động
để đáp ứng các quorum, và bạn sẽ không thể index hoặc xóa bất kỳ tài liệu.
 Timeout
Điều gì xảy ra nếu không đủ bản sao shard có sẵn? Elasticsearch chờ đợi, với hy
vọng rằng nhiều shard khác sẽ xuất hiện. Theo mặc định, nó sẽ đợi đến 1 phút. nếu
bạn cần, bạn có thể sử dụng các thông số thời gian chờ để làm cho nó bỏ sớm hơn
100 là 100 mili giây, và 30 là 30 giây .
Một Index mới có 1 bản sao theo mặc định, có nghĩa là hai bản sao shard hoạt động
nên được yêu cầu để đáp ứng nhu cầu cho một số đại biểu. Tuy nhiên, các thiết lập
mặc định sẽ ngăn cản chúng ta làm bất cứ điều gì hữu ích với một cluster singlenode. Để tránh vấn đề này, các yêu cầu đối với một số đại biểu cần được thi hành
chỉ khi num ber_of_replicaslớn hơn 1 .

II.2.4.

Lấy ra một tài liệu

Một tài liệu có thể được lấy ra từ một primary shard hoặc từ bất kỳ bản sao của nó
thể hiện trong hình 9

17


- Cơ sở dữ liệu tiên tiến Hình . Lấy ra một tài liệu

Dưới đây là trình tự các bước để lấy một tài liệu hoặc từ một primary shard hoặc
bản sao:
1. Request được gửi đến node master (Node 1). Tại đây xác định primary shard
cho document sẽ là 0.
2. Do tất cả node đều lưu dữ liệu, nên master node sẽ chọn ra 1 node và lấy dữ
liệu ở shard số 0. Việc chọn này giúp giảm tập trung vào một node. Thuật
toán Round-robin được sử dụng để các shard được chọn khác nhau ở mỗi
request. Trong trường hợp này Node 2 được chọn.
3. Replica 0 ở Node 2 trả về kết qủa cho master node

II.2.5.

Cập nhật từng phần tài liệu

Bản cập nhật API , như thể hiện trong hình 10 , kết hợp đọc và viết mẫu giải thích
trước đây.

Hình . Cập nhật từng phần đến một tài liệu

Dưới đây là trình tự các bước sử dụng để thực hiện một bản cập nhật từng phần trên
một tài liệu :
1. Khách hàng gửi một yêu cầu cập nhật đến Node 1.
2. Nó chuyển tiếp yêu cầu đến Node 3, nơi các primary shard được phân bổ.
3. Node 3 lấy tài liệu từ các primary shard, thay đổi JSON trong lĩnh vực
_sourcevà cố gắng để reindex các tài liệu trên primary shard. Nếu các tài liệu đã
được thay đổi bởi quá trình khác , nó thử lại bước 3 tới retry_on_conflict, trước khi
đưa lên .
4. Nếu Node 3 đã quản lý để cập nhật các tài liệu thành công , nó sẽ chuyển tiếp các
phiên bản mới của các tài liệu song song với các replica shards trên Node 1 và
Node 2 được lập chỉ mục. Một khi tất cả các replica shards báo cáo thành công,
Node 3 báo cáo thành công đến node yêu cầu, mà các báo cáo thành công cho
khách hàng.
Bản sao nền tảng tài liệu
Khi một primary shard/cơ bản chuyển tiếp thay đổi các replica shards của nó, nó
không chuyển tiếp các yêu cầu cập nhật . Thay vào đó nó sẽ chuyển tiếp các phiên
bản mới của tài liệu đầy đủ . Hãy nhớ rằng những thay đổi này sẽ được chuyển đến
các replica shards không đồng bộ , và không đảm bảo rằng chúng sẽ đến theo thứ tự
18


- Cơ sở dữ liệu tiên tiến mà chúng được gửi. Nếu Elasticsearch chuyển tiếp chỉ sự thay đổi , nó có thể là
thay đổi sẽ được áp dụng theo thứ tự sai , kết quả là một tài liệu bị sửa đổi.

II.2.6.

Multidocument Patterns

Các mô hình cho mget và and bulk APIs tương tự như cho các tài liệu cá

nhân. Sự khác biệt là các node yêu cầu biết trong đó shard mỗi tài liệu sống . Nó
phá vỡ các yêu cầu đa tài liệu thành một yêu cầu đa tài liệu cho mỗi phần và chuyển
những song song với mỗi node tham gia .
Sau khi nhận được câu trả lời từ mỗi node, nó đối chiếu phản ứng của họ vào một
phản ứng duy nhất, mà nó trả về cho khách hàng, như thể hiện trong hình 4-5.

Dưới đây là trình tự các bước cần thiết để lấy nhiều tài liệu với một yêu cầu mget
duy nhất:
1. Khách hàng gửi một yêu cầu mget đến Node 1 .
2. Node 1 xây dựng một multi-get cho mỗi phần và chuyển những yêu cầu tương tự
đến các node lưu trữ mỗi yêu cầu chính hoặc replica shards. Một khi tất cả trả lời
đã được nhận, Node 1 xây dựng các phản ứng và trả lại nó cho khách hàng.
Một thông số định tuyến có thể được thiết lập cho mỗi tài liệu trong mảng tài liệu.
Các API số lượng lớn, như mô tả trong hình 4-6 , cho phép thực hiện nhiều create,
index, delete, and update requests trong một yêu cầu số lượng lớn duy nhất.

Hình . Thay đổi tài liệu với số lượng lớn

Trình tự các bước tiếp theo là các API số lượng lớn như sau:
1. Khách hàng gửi một yêu cầu số lượng lớn đến Node 1.
19


- Cơ sở dữ liệu tiên tiến 2. Node 1 xây dựng một số lượng lớn yêu cầu cho mỗi phần và chuyển những yêu
cầu song song với các node lưu trữ mỗi shard có liên quan.
3. Các primary shard thực hiện mỗi hành động nối tiếp, lần lượt từng cái một. Khi
mỗi hành động thành công, primary shard chuyển các tài liệu mới (hoặc xóa) để
replica shards song song, và sau đó chuyển sang các hành động tiếp theo. Một khi
tất cả các replica shards báo cáo thành công cho tất cả các hành động, các báo cáo
node thành công đến node yêu cầu, trong đó đối chiếu các câu trả lời và trả chúng

cho khách hàng.
Các API số lượng lớn cũng chấp nhận các thông số nhân rộng và tính thống nhất ở
cấp cao nhất cho toàn bộ yêu cầu số lượng lớn và các thông số định tuyến trong các
siêu dữ liệu cho mỗi yêu cầu.

II.3.
II.3.1.

Tìm kiếm phân tán

Pha truy vấn

Trong suốt quá trình diễn ra pha truy vấn ban đầu này, truy vấn sẽ được loan
truyền đến bản sao của mọi Shard (primary shard or replica shard) trong bảng dữ
liệu (index). Mỗi shard thi hành việc tìm kiếm trong nội bộ của mình và tạo ra một
danh mục ưu tiên các tài liệu khớp.
Hàng đợi ưu tiên tức là một danh sách liệt kê từ trên xuống dưới một số n những tài
liệu khớp. Kích cỡ của danh mục ưu tiên tùy vào các thông số định dạng trang là
from và size. Ví dụ, yêu cầu tìm kiếm sau đây sẽ đỏi hỏi một danh mục ưu tiên đủ
lớn để chứa được 100 tài liệu:

Hình . Pha truy vấn của tìm kiếm phân tán

Pha truy vấn bao gồm ba bước sau:
− Bước 1. Người dùng gửi một yêu cầu tìm kiếm đến Node 3 để tạo ra một

danh mục ưu tiên (priority queue) với kích thước from + size.
− Bước 2. Node 3 chuyển tiếp yêu cầu tìm kiếm đến primary hoặc replica của

tất cả các shard trong bảng dữ liệu. Mỗi shard thi hành truy vấn ấy trong nội

20


- Cơ sở dữ liệu tiên tiến bộ của chúng và cộng các kết quả vào danh mục ưu tiên nội bộ với kích
thước from + size
− Bước 3. Mỗi shard trả về ID tài liệu và các giá trị phân loại của mọi tài liệu

nằm trong danh mục ưu tiên của mình để coordinating node (node 3), là nơi
sẽ tổng hợp lại những giá trị ấy thành một danh mục ưu tiên của riêng mình
để tạo ra danh sách liệt kê kết quả tổng thể.
Khi có một yêu cầu tìm kiếm được gửi tới node, thì node ấy trở thành
Coordinating node (Node trung gian) trong ví dụ trên thì node 3 trở thành node
trung gian. Công việc của node này là loan truyền yêu cầu tìm kiếm đến mọi shard
liên quan. Các yêu cầu tìm kiếm có thể được thực hiện bởi một primary shard hoặc
bởi bất kỳ repica shard của nó, chính vi thế cho nên càng nhiều replica shard thì
năng suất tìm kiếm càng tăng, và tập hợp phản hồi từ những shard ấy thành một bộ
kết quả liệt kê tổng thể trả về cho người dùng.
Mỗi shard sẽ thi hành truy vấn trong nội bộ của mình và tạo ra một danh
mục ưu tiên liệt kê với độ dài from + size, hay nói cách khác, đủ kết quả để tự nó
thỏa mãn yêu cầu tìm kiếm tổng thể. Nó sẽ trả về Coordinating node một danh sách
kết quả hơi dài một chút chỉ chứa IDs doc và bất cứ giá trị cần thiết nào để liệt kê,
chẳng hạn như _score.

II.3.2.

Pha truy xuất

Pha truy vấn xác địch tài liệu nào thỏa mãn yêu cầu tìm kiếm. Công việc của pha
truy xuất gồm các bước sau:

Hình . Fetch phase of distributed search

Bước1. Coordinating node (Node trung gian) xác định những tài liệu cần được truy
xuất và đưa ra một yêu cầu multi GET tới các Shard liên quan.
Bước 2. Mỗi shard tải những tài liệu rồi trả những tài liệu ấy về Node trung gian.
Bước 3. Khi tất cả những tài liệu đã được truy xuất, Node trung gian sẽ trả về kết
quả cho người dùng.
Ví dụ, nếu truy vấn của chúng ta xác định (“from”: 90, “size”: 10), thì node trung
gian sẽ quyết định xem tài liệu nào thực sự cần thiết được truy xuất, như vậy ta có
90 kết quả đầu tiên sẽ bị loại và chỉ 10 kết quả tiếp theo mới cần phải truy xuất.
Những tài liệu này có đến từ một, một vài, hoặc tất cả các shard liên quan đến yêu
cầu tìm kiếm ban đầu và kết hợp phương pháp tô nổi mẩu thông tin tìm kiếm
21


- Cơ sở dữ liệu tiên tiến (search snippet highlighting). Khi Node trung gian nhận được tất cả kết quả trả về,
nó sẽ ghép chúng thành một phản hồi duy nhất trả về cho người dùng.

II.3.3.

Tùy chọn tìm kiếm

Một vài thông số chuỗi truy vấn tùy chọn có thể ảnh hưởng đến tiến trình tìm kiếm:
2.3.3.1. Preference
Thông số tham chiếu cho phép bạn kiểm soát các Shard hoặc các Node được dùng
để thực hiện yêu cầu tìm kiếm. Nó chấp nhận các giá trị chẳng hạn như _primary,
_primary_first, _local, _only_node:xyz, _prefer_node:xyz, and_shards:2,3,
_primary
_primary_first

Chỉ hoạt động và thực hiện duy nhất trên primary shard
Chỉ thực hiện trên primary shard khi bị lỗi có thể thực
hiện trên shard khác
….

2.3.3.2. Timeout
Sự phản hồi cho một yêu cầu tìm kiếm cho biết tìm kiếm đó có bị hết giờ hay không
và có bao nhiêu Shard phản hồi thành công:

2.3.3.3. Định tuyến
Routing được sử dụng để điều kiển với tất cả shard nhận các yêu cầu để tìm
kiếm tài liệu. Khi routing được bật người dùng có thể chỉ định một giá trị ở hai chỉ
số index time hoặc query time để xác định các shard được sử dụng cho
indexing/quering. Giá trị định tuyến là chuỗi tùy ý, mặc định là các document’s_id,
nhưng có thể thiết lập giá trị tùy ý. chuỗi định tuyến này được thông qua thông qua
một hàm băm để tạo ra một số, được chia theo số lượng phân đoạn cơ bản trong chỉ
mục để trả lại phần còn lại. Trong thời gian tìm kiếm, thay vì tìm kiếm trên tất cả
các Shard của một bảng dữ liệu, bạn có thể chỉ ra một hoặc một số các giá trị định
tuyến để giới hạn việc tìm kiếm vào đúng những Shard ấy: GET /_search?
routing=user_1,user2
Kỹ thuật này trở nên tiện lợi khi thiết kết các hệ thống tìm kiếm cực lớn.
2.3.3.4. Search_type
22


- Cơ sở dữ liệu tiên tiến Tuy phương thức Query_then_Fecth (Query then Fetch) là dạng tìm kiếm mặc định,
nhưng chúng ta cũng có thể chỉ định những dạng tìm kiếm khác khi có mục đích cụ
thể, chẳng hạn như: GET /_search?search_type=count
- Count: Dạng tìm kiếm đếm chỉ có duy nhất pha truy vấn. Có thể dùng nó khi
không cần những kết quả tìm kiếm mà chỉ cần đếm hoặc tập hợp số tài liệu khớp

với truy vấn.
- Query_and_Fetch (Truy vấn và Truy xuất): Dạng tìm kiếm Query_and_Fetch kết
hợp pha truy vấn và truy xuất thành một bước duy nhất. Đây là phương thức tối ưu
hóa nội bộ được dùng khi một yêu cầu tìm kiếm nhắm vào duy nhất một Shard
riêng lẻ, chẳng hạn như khi có một giá trị định tuyến được chỉ định.
- dfs_query_then_fetch and dfs_query_and_fetch: Các dạng truy vấn dfs có pha
truy vấn tìm kiếm những tần số thuật từ, tất cả những Shard liên quan nhằm tính
toán tần suất tổng quát của thuật từ.
- Scan: Dạng tìm kiếm quét được dùng để liên kết với cuộn API nhằm tìm kiếm
hiệu quả một số lớn các kết quả. Nó thực hiện việc này bằng cách vô hiệu hóa tính
năng phân loại.
2.3.4.5. Scan and scroll (Quét và cuộn)
Dạng tìm kiếm quét (scan) và cuộn API được dùng chung với nhau để tìm kiếm
hiệu quả một số lượng lớn tài liệu từ Elasticsearch mà không cần phải chịu kiểu
đánh số trang sâu.
- Scroll: Tìm kiếm dạng cuộn cho phép chúng ta thực hiện một tìm kiếm ban đầu và
duy trì việc lấy kết quả từ Elasticsearch cho đến khi không kết quả nào sót lại. Nó
hơi giống con trỏ (cursor) trong cơ sở dữ liệu truyền thống.
- Scan: Dạng quét bỏ qua việc phân loại và trả về trọn vẹn khối kết quả tiếp theo từ
mọi shard có kết quả trả về. Để sử dụng scan_and_scroll, chúng ta thi hành một yêu
cầu tìm kiếm là search_type , và nhập vào thông số scroll để cho Elasticsearch biết
nó phải mở cuộn trong bao lâu:

II.4.
II.4.1.

Shard và cách làm việc của Shard

Làm cho văn bản mang tính có thể tìm kiếm

Các cơ sở dữ liệu truyền thống lưu trữ một giá trị đơn lẻ trên một trường,
nhưng điều này không đủ để thực hiện full-text search. Mỗi từ trong một trường văn
bản nhất thiết phải mang tính searchable, tức là cơ sở dữ liệu ấy cần có khả năng lập

23


- Cơ sở dữ liệu tiên tiến bảng dữ liệu cho đa giá trị - trong trường hợp này là những từ ngữ ( index multiple
values-words), trong một trường đơn lẻ (single field)
Cấu trúc dữ liệu hỗ trợ tốt nhất cho đòi hỏi multiple-values-per -field đó là bảng dữ
liệu nghịch đảo (inverted index).Bảng dữ liệu nghịch đảo chứa một danh sách phân
loại tất cả những giá trị duy nhất, hay là những thuật từ (term), xuất hiện trong bất
kì tài liệu nào và, đối với mỗi thuật từ (term), một danh sách tất cả những tài liệu
chứa thuật từ (term) ấy.

Bảng dữ liệu nghịch đảo (inverted index) có thể chứa nhiều thông tin hơn danh sách
tài liệu chứa một thuật từ cụ thể nào đó. Bảng này có thể lưu trữ một số lượng tài
liệu chứa mỗi thuật từ, số lần một thuật từ xuất hiện trong một tài liệu cụ thể, và hơn
thế nữa. Những số liệu này cho phép công cụ Elasticsearch quyết định xem những
thuật từ nào quan trọng hơn những thuật khác, và những tài liệu nào quan trọng hơn
những tài liệu khác. Điều quan trọng cần phải biết đó là bảng dữ liệu nghịch đảo
(inverted index) cần biết tất cả tài liệu trong bộ sưu tập để nó có thể thực hiện chức
năng của mình.
Tính không biến đổi

Bảng dữ liệu nghịch đảo (inverted index) được ghi lên ổ đĩa (disk) mang tính không
biến đổi: nó mãi mãi không thay đổi.Tính không biến đổi này có những lợi ích quan
trọng:
•

Nếu không bao giờ phải cập nhật bảng dữ liệu ấy, thì không có gì phải lo
lắng về những quy trình phức tạp để thực hiện những thay đổi đồng thời.
• Khi bảng dữ liệu đã được vùng nhớ đệm (cache) của hệ thống tập tin rồi thì
nó sẽ ở nguyên đấy, vì nó không bao giờ thay đổi. Chừng nào còn có đủ
không gian trống trong vùng nhớ đệm hệ thống tập tin thì hầu hết các hoạt
động đọc (reads) sẽ đến từ bộ nhớ thay vì phải đưa ổ đĩa vào. Điều này tạo ra
một sự tăng cường hiệu suất vượt trội.
• Bất kì vùng nhớ đệm (cache) nào như vùng nhớ đệm filter chẳng hạn đều giữ
nguyên tính hiệu lực cho vòng đời của bảng dữ liệu. Chúng không cần phải
tái xây dựng mỗi lần dữ liệu thay đổi, vì dữ liệu sẽ không thay đổi.
• Việc ghi một bảng dữ liệu nghịch đảo đơn lẻ với kích cỡ lớn cho phép dữ
liệu được nén lại, hạn chế đáng kế đầu vào đầu ra của ổ đĩa và lượng RAM
cần để ghi nhớ bảng dữ liệu ấy.

24


- Cơ sở dữ liệu tiên tiến II.4.2.

Những chỉ số có thể cập nhật một cách linh động

Vấn đề tiếp theo cần giải quyết đó là làm sao để tạo ra một bảng dữ liệu
nghịch đảo có thể cập nhật mà không làm mất đi những lợi ích của tính không
biến đổi kể trên đó là sử dụng nhiều bảng dữ liệu. Thay vì phải viết lại toàn bộ
bảng dữ liệu nghịch đảo, thì ta sẽ thêm vào những chỉ số bổ sung mới để phản
ánh những thay đổi gần đây. Mỗi bảng dữ liệu nghịch đảo về phần chúng đều sẽ
được truy vấn – bắt đầu từ cái cũ nhất – và mọi kết quả sẽ được kết hợp lại.
Lucene, thư viện Java nền tảng của Elasticsearch, có giới thiệu ý tưởng về
tìm kiếm trên mỗi phân mảnh (per-segment-search). Một phân mảnh (segment)
tự nó là một bảng dữ liệu nghịch đảo, nhưng giờ đây từ ngữ index (bảng dữ liệu)

trong Lucene mang nghĩa là tập hợp những phân mảnh cộng với một điểm
chuyển giao (commit point) – một tập tin liệt kê tất cả những phân mảnh đã biết,
như mô tả trong hình 14. Các tài liệu mới trước tiên sẽ được thêm vào một bộ
đệm tạo dữ liệu ghi nhớ (in-memory indexing buffer), như trong hình 15, trước
khi được ghi vào một phân vùng ổ đĩa, như hình 16

Hình . Một bảng dữ liệu lucene với một điểm chuyển đổi và ba phân vùng.

Tìm kiếm trên một phân mảnh hoạt động như sau:
1. Các tài liệu mới được tập hợp trong vùng đệm tạo dữ liệu ghi nhớ (in-memory
indexing buffer). Xem hình 14
2. Tùy tình huống mà vùng đệm được chuyển đổi:
•

Một phân vùng mới – tức là một bảng dữ liệu nghịch đảo bổ sung – được
ghi lên ổ đĩa
• Một điểm chuyển đổi mới được ghi lên ổ đĩa, bao gồm tên của phân vùng
mới
• Ổ đĩa ấy được đồng bộ cố định - tất cả ghi chép chờ trong bộ nhớ đệm hệ
thống tập tin được dồn vào ổ đĩa, để chắc rằng chúng được ghi về mặt vật
lý.
3. Phân vùng mới được mở ra, làm cho tài liệu mà nó chứa trở nên khả dụng đối
với tìm kiếm.
4. Vùng đệm ghi nhớ được làm sạch, và sẵn sàng chấp nhận tài liệu mới.

25