3.3.1. Giới thiệu
BigTable là một hệ thống lưu trữ phân tán dùng để quản lý dữ liệu có cấu trúc được thiết kế có thể mở rộng đến một kích thước rất lớn: hàng petabytes dữ liệu thông qua hàng ngàn server. Dự án Bigtable được Google phát triển từ năm 2004 và bắt đầu đưa vào sử dụng từ khoảng tháng 2 năm 2005. Bigtable đã đạt được một số mục tiêu đặt ra ban đầu, như: khả năng ứng dụng rộng rãi, hiệu năng sử dụng cao, có tính mở rộng ... Đã có rất nhiều sản phẩm cũng như dự án của Google có sử dụng Bigtable, nổi bật trong đó có thể kể đến Google Analytics, Google Finance, Orkut, Google Earth, … Những sản phẩm này tận dụng Bigtable theo nhiều cách khác nhau, và các cụm Bigtable được sử dụng cũng được config khác nhau, từ một vài đến hàng ngàn server, lưu trữ lên đến vài trăm terabytes dữ liệu.
Xét trên nhiều phương diện thì Bigtable giống với một cơ sở dữ liệu, nó cũng có các chiến lược thực thi cài đặt như cơ sở dữ liệu. Các cơ sở dữ liệu song song và cơ sở dữ liệu bộ nhớ chính cũng có tính mở rộng và hiệu năng cao, nhưng Bigtable cung cấp một giao diện khác so với những hệ thống đó. Bigtable không hỗ trợ mô hình dữ liệu quan hệ đầy đủ, thay vào đó nó cung cấp cho các máy trạm một mô hình dữ liệu đơn giản nhưng hỗ trợ cơ chế điều khiển động trên bố cục và định dạng dữ liệu, và cho phép các máy trạm suy được các tính chất cục bộ của dữ liệu biểu diễn ở bộ nhớ cơ sở. Dữ liệu được đánh chỉ mục qua tên hàng và cột có thể ở dạng chuỗi trừu tượng. Bigtable cũng xem dữ liệu như các chuỗi không cần thông dịch, mặc dù các máy trạm thường sắp xếp các dạng khác nhau của dữ liệu có cấu trúc hoặc nửa cấu trúc (semi- structured) vào các chuỗi đó. Máy trạm có thể điều khiển vùng dữ liệu của họ thông qua việc chọn lựa các mô hình một cách cẩn thận. Cuối cùng, các tham số trong sơ đồ Bigtable cho phép các máy trạm điều khiển động được xem nên xử lý dữ liệu ngoài bộ nhớ hay là từ ổ đĩa. [15]
BigTable được xây dựng dựa trên Google File System (GFS), Chubby Lock Service, SSTable và một số chương trình khác.
3.3.2. Mô hình dữ liệu
Bigtable có thể xem như một ánh xạ thưa, phân tán, sắp xếp đa chiều ổn định. Ánh xạ đó được xác định qua khóa hàng (row key), khóa cột (column key) và mốc thời gian (timestamp), mỗi giá trị trong ánh xạ là một chuỗi (string) không thông dịch.
(row: string, column: string, timestamp: int64) cell content: string;
Xét một ví dụ cụ thể: Webtable – một bảng lưu trữ tập hợp các trang web và các thông tin liên quan được sử dụng trong rất nhiều dự án. Trong ví dụ này, ta sử dụng các URL làm row key, các vấn đề khác ta để làm tên cột, nội dung thì chứa trong các ô (content) như trong hình 3.2. Trong hình 3.2 tên hàng là một chuỗi đảo ngược URL.
Cột contents chứa nội dung trang web, còn các cột anchor chứa text của các trang tham chiếu đến trang web đang xét (ở ví dụ trên có các trang Sport Illustrated và MY-look tham chiếu đến CNN). Mỗi ô ở cột anchor thì chỉ có 1 version, còn ô contents thì có thể nhiều version, ở các mốc thời gian khác nhau.
Hình 3. 2: Một lát cắt Webtable: 3.3.2.1. Row
Row key trong một bảng là một chuỗi bất kỳ (kích thước có thể lên tới 64KB, mặc dù các kích thước thông thường cho hầu hết người dùng là từ 10 – 100 byte). Mỗi lần đọc hoặc ghi dữ liệu lên row key, dữ liệu sẽ được ghi lên toàn bộ hàng bất kể số lượng các hàng khác nhau được đọc hoặc ghi, một quyết định tạo điều kiện thuận lợi cho client có thể suy luận được cách xử lý của hệ thống trong trường hợp việc cập nhật dữ liệu trên cùng một hàng xảy ra đồng thời.
Bigtable lưu trữ dữ liệu theo thứ tự bảng chữ cái đối với row key. Khối hàng của một bảng được phân hoạch động, mỗi khối hàng được gọi là 1 tablet, coi như một đơn vị phân tán và tải nạp. Vệc đọc ghi trên 1 khối hàng như vậy trở nên dễ dàng và hiệu quả hơn với các máy trạm. Như trong Webtable, các trang cùng 1 domain được nhóm vào các hàng liên tiếp nhau bằng cách đảo ngược tên host trong URL. Ví dụ ta lưu dữ liệu của trang http://maps.google.com/index.html theo key com.google.maps/index.html. Việc lưu trữ các trang web cùng domain gần nhau như thế làm cho việc phân tích hiệu quả hơn.
3.3.2.2. Column families:
Các column key được nhóm lại thành column family, tạo nên đơn vị cơ bản cho các điều khiển truy cập. Dữ liệu trong cùng 1 column family luôn có cùng kiểu (để có thể nén dữ liệu trong cùng một column family lại với nhau). Mỗi column family cần phải tạo trước khi có dữ liệu lưu vào 1 trong các column key mà nó chứa. Sau khi column family được tạo, bất kỳ cột nào trong đó đều có thể được sử dụng. Về mặt lý thuyết, số lượng cột của một bảng là không giới hạn
Column key được đặt tên theo cú pháp: family:qualifier. Ví dụ trong Webtable có column family là language, gồm duy nhất một cột language lưu ngôn ngữ của 1 trang
web. Mỗi trang web có thể có nhiều ngôn ngữ, chẳng hạn tiếng Anh, tiếng Việt, tiếng Pháp… Một ví dụ khác là column family anchor, mỗi cột trong family này là một anchor như trong hình 3.2, qualifier là tên của trang web được tham chiếu đến, còn nội dung ô chứa các link text.
Điều khiển truy cập và các phép toán trên đĩa và bộ nhớ được thực hiện theo các column family. Trong ví dụ trên, những điều khiển này cho phép quản lý rất nhiều các ứng dụng khác nhau như: có thể tạo mới dữ liệu, có thể đọc dữ liệu và tạo ra các column family dẫn xuất nhưng đôi khi cũng chỉ cho hiển thị các dữ liệu đã có.
3.3.2.3. Timestamp
Mỗi ô trong Bigtable chứa các nội dung ở nhiều mốc thời gian khác nhau của cùng một dữ liệu, mỗi mốc ứng với 1 phiên bản. Các phiên bản này được đánh chỉ mục theo timestamp. Mỗi timestamp là một số nguyên 64 bit. Các mốc thời gian này có thể được ấn định bởi BigTable, khi đó nó biểu diễn “thời gian thực” theo microseconds hoặc có thể được ấn định bởi các ứng dụng của client. Để tránh sự xung đột, các trình ứng dụng phải có cơ chế để tự tạo ra các timestamp duy nhất cho mình. Các phiên bản sẽ được sắp xếp theo sự tăng dần của timestamp, do đó, phiên bản mới nhất sẽ được đọc đầu tiên.
3.3.3. Buiding Blocks
Bigtable được xây dựng dựa trên rất nhiều các thành phần của hạ tầng Google. Bigtable sử dụng Google File System (GFS) để lưu trữ dữ liệu.
Định dạng file Google SSTable được sử dụng nội bộ để lưu trữ dữ liệu Bigtable. SSTable cung cấp một ánh xạ ổn định, không thay đổi thứ tự từ khóa đến giá trị, trong khi mà cả khóa và giá trị đều là những chuỗi byte bất kỳ. Các phép toán được cung cấp để tìm kiếm các giá trị kết hợp với một khóa xác định và để lặp trên toàn bộ các cặp khóa/giá trị trong một phạm vi khóa nhất định. Mỗi khối SSTable chứa một chuỗi tuần tự các khối (mỗi khối thường có kích thước là 64 byte). Một chỉ mục khối (thường được lưu ở cuối của SSTable) thường được dùng để định vị các khối. Chỉ mục sẽ được nạp vào bộ nhớ khi khối đó được mở. Một lần dò tìm có thể được thực hiện với một lần tìm kiếm trên đĩa: Đầu tiên, chúng ta sẽ tìm khối thích hợp bằng phương pháp tìm kiếm nhị phân trên chỉ mục của bộ nhớ trong, sau đó sẽ đọc khối thích hợp đó từ đĩa.
Bigtable dựa vào một dịch vụ chất lượng cao và ổn định gọi là Chubby. Chubby gồm có 5 bản sao và một trong số chúng được chọn để làm bản chính và phục vụ các yêu cầu một cách có hiệu quả. Một dịch vụ vẫn được chạy nếu đa số các bản sao đang chạy và có thể liên lạc được với nhau. Chubby sử dụng thuật toán Paxos [16] để đảm bảo tính nhất quán cho các bản sao. Chubby cung cấp một không gian tên bao gồm các
thư mục và các tệp nhỏ. Mỗi thư mục hoặc tệp có thế sử dụng như một khóa, đọc hoặc ghi lên các file nguyên tử.
Bigtable sử dụng Chubby cho rất nhiều các tác vụ: để đảm bảo lúc nào cũng có nhiều nhất là một bản chính hoạt động; để lưu trữ vị trí của trình khởi động của dữ liệu Bigtable; để tìm ra các tablet server và các tablet server đã bị lỗi; để lưu trữ lược đồ thông tin Bigtable và để lưu trữ danh sách điều khiển truy cập. Nếu Chubby không sẵn sàng trong một thời gian dài, Bigtable cũng trở lên không sãn sàng.
3.3.4. Implementation – các vấn đề
Việc cài đặt Bigtable cần lưu ý 3 vấn đề chính: cần 1 thư viện kết nối với tất cả các máy trạm, một máy chủ chuyên dụng, và rất nhiều máy chủ tablet khác. Các máy chủ tablet có thể được thêm xóa tự động từ các cluster để đáp ứng sự thay đổi trong quá trình làm việc.
Máy chủ chuyên dụng chịu trách nhiệm gán các tablet cho các máy chủ tablet, phát hiện các máy chủ tablet được thêm vào hoặc bị lỗi, cân bằng tải cho các máy chủ tablet, tập hợp các file rác trong GFS. Nhìn chung, nó điều khiển các thay đổi như việc tạo ra các tablet hay các column family.
Mỗi máy chủ tablet quản lý một tập hợp tablet (có thể dao động từ 10 đến 1000 tablet trong 1 máy chủ tablet). Chúng có nhiệm vụ xử lý các yêu cầu đọc ghi đến các tablet được tải và tự động phân chia tablet ra tablet nhỏ hơn nếu như tablet đó quá lớn.
Cũng như rất nhiều các hệ thống lưu trữ phân tán một máy chủ chuyên dụng, dữ liệu client không được chuyển qua máy chuyên dụng: client liên lạc trực tiếp với các máy chủ tablet cho việc đọc và ghi dữ liệu. Do Bigtable client không phụ thuộc vào máy chủ chuyên dụng trong việc định vị các thông tin trong tablet nên trên thực tế, hầu hết các client không bao giờ liên lạc với máy chủ chuyên dụng.
Trong Bigtable, mỗi cụm lưu giữ một số các bảng, mỗi bảng gồm nhiều bảng con (tablet), mỗi bảng con lại chứa tất cả các thông tin có liên quan tới một khối hàng. Ban đầu mỗi bảng chỉ gồm 1 bảng con, về sau kích thước lớn dần lên thì nó tự động chia thành các bảng nhỏ hơn, mặc định mỗi bảng vào khoảng 100-200MB)
3.3.4.1. Tablet location:
Bigtable sử dụng phân cấp 3 mức tương tự như cây B+ [10] để lưu trữ thông tin định vị tablet.
Hình 3. 3: Định vị tablet phân cấp
Mức đầu tiên là các tệp được lưu trữ trong Chubby, nó bao gồm vị trí của các bảng con gốc (root tablet). Root tablet chứa vị trí của tất cả các tablet trong một bảng riêng biệt METADATA. Mỗi METADATA tablet chứa vị trí của một tập các UserTable. Root tablet là bảng đầu tiên trong METADATA table nhưng được xử lý riêng biệt – không bao giờ được phân chia – để đảm bảo sự phân cấp là không quá 3 mức.
3.3.4.2. Tablet assignment
Tại một thời điểm, mỗi tablet sẽ được gán cho một tablet server. Máy chủ chuyên dụng theo dõi tập các server tablet hoạt động, các phép gán hiện thời và cả các tablet nào chưa được thực hiện phép gán. Nó sẽ thực hiện việc gán dữ liệu cho các tablet bằng việc gửi các truy vấn nạp tablet cho các tablet server đã sẵn sàng cho phép gán.
Bigtable sử dụng Chubby để theo dõi các tablet server. Mỗi khi tablet server khởi động, nó tạo ra, dành được khóa dành riêng trên một tệp được đặt tên duy nhất trong thư mục đặc biệt của Chubby. Máy chủ chuyên dụng sẽ điều khiển thư mục này tìm ra được tablet server. Tablet server sẽ ngừng phục vụ các tablet khi nó bị mất khóa dành riêng, ví dụ như do sự phân hoạch mạng làm cho server mất phiên làm việc của Chubby (Chubby cung cấp một thiết bị hiệu quả cho phép tablet server kiểm tra khi nào khóa của nó vẫn còn hiệu quả mà không cần quan tâm đến giao thông mạng). Tablet server sẽ cố gắng để dành lại khóa dành riêng trên file nếu như file đó còn tồn tại. Nếu file đó không còn tồn tại nữa, tablet server sẽ không bao giờ phục vụ nữa, do đó nó sẽ tự hủy. Bất cứ lúc nào tablet table kết thúc (có thể là do hệ thống quản lý cụm đã xóa tablet server đó khỏi cụm), nó sẽ nhả khóa dành riêng của nó do đó, máy chủ chuyên dụng sẽ gán khóa đó cho các tablet server được hiệu quả hơn.
Máy chủ chuyên dụng sẽ có nhiệm vụ tìm ra các tablet server không còn phục vụ các tablet của nó nữa để thực hiện phép gán lại cho các tablet này nhanh nhất có thể. Để làm được việc này, máy chủ chuyên dụng sẽ có một cơ chế để hỏi định kỳ các tablet server về trạng thái khóa của chúng. Nếu tablet server trả lời là nó đã bị mất khóa hoặc máy chuyên dụng đã nhiều lần không liên lạc được với tablet server thì nó sẽ cố gắng lấy lại khóa của file trên server đó. Nếu máy chủ chuyên dụng còn lấy lại được khóa, Chubby còn tồn tại và tablet server có thể đã chết hoặc không liên lạc được với Chubby, máy chủ chuyên dụng chắc chắn rằng tablet server không thể tiếp tục phục vụ nữa nên nó sẽ xóa tệp của server đó. Mỗi lần máy chủ chuyên dụng xóa một file của server nào đó, nó sẽ chuyển tất các các tablet mà nó đã gán cho server đó lúc trước vào tập các tablet chưa được gán. Để các cụm Bigtable là không thể bị tấn công do sự liên lạc giữa máy chủ chuyên dụng và Chubby, máy chủ chuyên dụng sẽ tự hủy khi mà phiên làm việc của Chubby kết thúc, do đó nếu máy chủ bị lỗi cũng không ảnh hưởng tới các phép gán của tablet cho tablet server.
Khi một master được khởi động bởi hệ thống quản lý cụm, nó cần tìm ra các phép gán cho tablet hiện thời trước khi nó thay đổi chúng. Master sẽ thực hiện các bước sau lúc khởi động: (1) Master sẽ chiếm đoạt một khóa master duy nhất trong Chubby, khóa này dùng để ngăn chặn việc tạo nhiều master đồng thời. (2) Master sẽ quét danh sách các server trong Chubby để tìm ra các server vẫn đang hoạt động. (3) Master sẽ liên lạc với các server để tìm ra các tablet đã được gán của từng server. (4) Master sẽ quét bảng METADATA để biết tập các tablet. Bất cứ khi nào nó tìm ra được tablet vẫn chưa được gán, nó sẽ thêm vào danh sách các tablet chưa gán, để làm cho phép gán cho tablet đó được hợp lệ. Một sự rắc rối là sự quét bảng METADATA không được thực hiện nếu như bảng đó chưa được gán. Do đó trước khi thực hiện bước 4, nếu như phép gán cho root table chưa được thực hiện ở bước 3, nó sẽ thêm root table vào tập các bảng chưa được gán. Việc thêm này để đảm bảo rằng root table cũng sẽ được gán. Do root table chứa tên tất cả các tablet nên master sẽ biết toàn bộ bảng sau khi nó thực hiện việc quét root table.
Tập các bảng có sẵn chỉ bị thay đổi khi có một tablet được tạo ra hoặc xóa đi, khi 2 tablet đã có gộp lại thành một tablet lớn hơn hoặc khi một tablet được phân chia thành 2 tablet nhỏ hơn.
3.3.4.3. Tablet serving
Trạng thái bền vững của tablet được lưu trong GFS, như minh họa trong hình 3.4. Các cập nhật sẽ được lưu lại tại nhật ký xác nhận để giúp cho việc thực hiện lại các bản ghi. Để thực hiện, các cập nhật này trước tiên sẽ được lưu trong bộ nhớ là một bộ đệm được sắp xếp gọi là memtable. Các cập nhập cũ hơn sẽ được lưu trữ lần lượt trong SSTable.
Hình 3. 4: Biểu diễn tablet
Khi một thao tác ghi được gửi tới tablet server, server sẽ kiểm tra định dạng của thao tác đó, sau đó người giử sẽ được cấp quyền để thực hiện các thay đổi. Sự ủy