TÌM HIỂU CÁCH THỨC CÁC ĐẠI GIA CÔNG NGHỆ QUẢN LÝ DỮ LIỆU

13 Mar, 2013

• Thương mại điện tử
• Tin công nghệ

(No Ratings Yet)

 Loading ...

Trong thế giới hiện đại ngày nay, đằng sau mỗi thao tác đơn giản của chúng ta trên thế giới mạng là cả một hệ thống đồ sộ đang vận hành. Vậy rốt cuộc, những người khổng lồ công nghệ này quản lý dữ liệu của mình như thế nào để đáp ứng nhu cầu ngày càng gia tăng đó?

Từng giờ, từng giây trên thế giới có hàng chục triệu người đang sử dụng dịch vụ của các hãng công nghệ lớn trên thế giới như Google, Yahoo, Microsoft, Facebook..v.v.. Điều này đòi hỏi sức mạnh từ của hàng ngàn bộ xử lý trên hàng ngàn server của các hãng này. Chỉ tính riêng công việc trả về kết quả tìm kiếm mỗi khi người dùng gõ từ khóa vào search box, Google dã phải vận hành hàng loạt server đặt khắp thế giới, liên tục thực hiện thuật toán tìm kiếm cũng như sục sạo khắp thế giới web để có được một bức tranh toàn cảnh sẵn sàng được sử dụng để phục vụ người dùng một cách nhanh nhất. Với cường độ hoạt động 24/7, 365 ngày/ năm không có lấy một giây ngơi nghỉ, riêng việc phục vụ nhu cầu tìm kiếm đã đòi hỏi các hệ thống của Google xử lý xấp xỉ 20 petabyte dữ liệu mỗi ngày, một con số mà người bình thường khó có thể tưởng tượng ra nổi.

Ở tầm vóc này, mọi sai lầm dù là nhỏ nhất, dù là trong khâu thiết kế hay triển khai cũng có tiềm năng gây hậu quả lâu dài. Mọi công việc từ bổ sung dung lượng lưu trữ đến thay đổi đôi chút kết cấu cơ sở dữ liệu đều sẽ cần được được cân nhắc kỹ lưỡng, và quan trọng nhất là cần một thiết kế hợp lý để không làm ảnh hưởng đến hàng triệu người dùng đang “kêu gào” đòi hỏi ngoài kia. Với hàng trăm ngàn người dùng đang online và hàng ngàn terabyte dữ liệu được đọc/ghi ngay cả vào những thời điểm hệ thống đang được nâng cấp, các giải pháp công nghệ đơn giản của các trung tâm dữ liệu thông thường sẽ khó mà phù hợp cho quy mô này.

Qua bài viết của Arcstechnica, chúng ta hãy cùng điểm qua một vài giải pháp dễ hiểu nhất mà Google , Amazon và Microsoft sử dụng.

Google File System

Không lấy gì làm lạ khi Google là một trong những hãng đầu tiên phải đối mặt với bài toán về lưu trữ khi xét đến số lượng người dùng mà hãng này phục vụ. Lời giải được các kỹ sư của hãng đưa ra vào năm 2003 là hệ thống lưu trữ phân tán, được tối ưu cho các dịch vụ mà Google cung cấp: Google File System (GFS). Có thể nói GFS là xương sống cho hầu hết mọi dịch vụ mà Google cung cấp. Hệ thống cơ sở dữ liệu người dùng đồ sộ, các dịch vụ điện toán đám mây và lượng dữ liệu khổng lồ phục vụ việc tìm kiếm, tất cả đều được quản lý dựa trên GFS.

Các chi tiết kỹ thuật GFS dĩ nhiên là được Google…giữ kín cho riêng mình, nhưng chúng ta vẫn có thể hình dung ra phần nào cách hệ thống này vận hành dựa trên những gì mà kỹ sư trưởng Howard Gobioff và Shun-Tak Leung chia sẻ hồi năm 2003. Tiêu chí hoạt động của GFS có thể gói gọn trong một câu: binh quý hồ…đa. Nói cách khác, với quy mô dữ liệu mà mình phải vận hành, các kỹ sư thiết kế GFS coi trọng khả năng mở rộng hệ thống, tăng số lượng server và ổ cứng thay vì đầu tư quá nhiều vào việc tạo ra các server hay thiết bị lưu trữ chất lượng cao. Google muốn kết hợp các server cũng như thiết bị lưu trữ rẻ và đơn giản thành một hệ thống với khả năng chịu lỗi cao nhất có thể. Như thế nào ư? Hãy nhìn vào câu phát biểu sau đây.

Nói cụ thể ra một chút, với cường độ hoạt động mà người dùng và Google đòi hỏi, các server này sớm muộn cũng sẽ…ra đi. Và thiết kế của GFS được tạo ra để bảo đảm rằng, dù có phải thường xuyên thay đổi các server trong hệ thống, lượng dữ liệu bị mất đi vẫn sẽ được giữ ở mức tối thiểu. Trong các hệ thống của mình, Google thường lưu trữ dữ liệu trên các file dung lượng cực lớn, và các file này sẽ được đọc, ghi, sử dụng bởi rất nhiều ứng dụng tại cùng một thời điểm. Vì vậy GFS còn cần một đặc tính nữa là khả năng cung cấp lượng lớn dữ liệu ở tốc độ cao cho các ứng dụng này trong mọi thời điểm.

Để đáp ứng được 2 yêu cầu kể trên (tốc độ và khả năng chịu lỗi), hiển nhiên ta sẽ nghĩ ngay đến công nghệ RAID, và quả thực GFS hoạt động với cơ chế tương tự. Các tập hợp, gói file dữ liệu với dung lượng được định sẵn sẽ được rải đều trên một số cụm (cluster) server. Với cách tiếp cận như đã nêu: sử dụng các phần cứng giá thành rẻ, lấy số lượng lớn để bù đắp cho hiệu năng; sẽ là không ngoa khi nói các server này của Google“thăng” với tần suất khá thường xuyên, nhưng số lượng dữ liệu bị mất vẫn luôn được giữ ở mức hết sức tối thiểu.

Tuy nói là “tương tự”, nhưng quả thực trừ việc tăng tốc độ truy xuất và khả năng chịu lỗi, GFS khác rất nhiều so với RAID. Các server kể trên có thể nằm trong các dải mạng khác nhau, có lúc thuộc cùng datacenter, có lúc thậm chí còn không thuộc cùng một datacenter (tùy thuộc vào việc các file dữ liệu trên đó phục vụ việc gì). Quy mô của hai công nghệ rất chênh lệch. Với quy môt hoạt động của Google, khi nhắc đến “ lưu trữ” thì ổ đĩa cứng là cách nghĩ quá hạn hẹp.

Điều này còn được thể hiện trong cách nhìn nhận đơn vị dữ liệu. Trong GFS, các kỹ sư chú trọng đến việc cung cấp dữ liệu theo từng khối cho việc xử lý, vì vậy khả năng cho phép đọc lượng lớn dữ liệu ở tốc độ cao là quan trọng nhất, còn tốc độ đọc hay ghi từng file vẫn chỉ được xếp vào hàng thứ yếu. Như các kỹ sư đã nêu trong bài viết của mình “Việc thực hiện một thay đổi bất kỳ trên từng file dĩ nhiên vẫn được hỗ trợ trong GFS, nhưng không được ưu tiên và hiệu năng của việc này cũng không được chú trọng tối ưu”. Nói dễ hiểu hơn, với quy mô của mình – GFS chủ yếu làm việc với dữ liệu theo từng khối, có thể bao gồm hàng triệu file với dung lượng từ hàng trăm MB đến vài GB. Và bởi các file dữ liệu này sẽ được rất nhiều ứng dụng sử dụng tại cùng một thời điểm, một cơ chế chịu lỗi khác cũng được thiết kế để bảo đảm rẵng mối khi có một thao tác ghi (write) xảy ra lỗi, dữ liệu sẽ có thể được rollback lại thời điểm ngay trước đó mà không làm ảnh hưởng đến các ứng dụng khác. Làm được điều này một cách chính xác mà không gây ảnh hưởng lớn đến hiệu năng là cả một kỳ công.

GFS gồm ba lớp: các GFS client sẽ xử lý các yêu cầu truy xuất dữ liệu của các ứng dụng; GFS master chuyên quản lý việc phân phối và theo dõi vị trí của các khối dữ liệu trên các cụm server (mỗi cụm chứa cùng loại dữ liệu), cũng như các file nằm trong đó (có thể nói dễ hiểu là các tiếp tân và một tay…thủ kho); cuối cùng chính là các server. Ngày trước, khi mà mọi thứ còn “đơn giản”, mô hình cơ bản sẽ là một master cho mỗi cụm server, các Client được đặt rải rác khắp nơi có thể liên lạc với bất kỳ Master nào khi cần. Nhưng hiện nay với nhu cầu ngày càng gia tăng của thế giới web, Google đã phải mở rộng mô hình phát triển một hệ thống master mới chuyên để quản lý các master cấp dưới, thông tin cụ thể về hệ thống này đáng tiếc lại chưa được hé lộ đầy đủ

Khi GFS client nhận được yêu cầu về một file dữ liệu từ một ứng dụng nào đó, nó sẽ gửi yêu cầu về thông tin vị trí của file này cho server master. server master sẽ cung cấp vị trí của một trong các server/cụm server có chứa file đó (nhớ rằng các máy này đóng vai trò như các RAID trong hệ thống nhỏ mà ta thường gặp). Nếu việc kết nối thành công, GFS Client sẽ làm việc trực tiếp với server dữ liệu đó để lấy file, Master sẽ không tham gia vào quá trình giao tiếp này trừ khi có lỗi xảy ra buộc Client phải quay lại “cầu cứu”.

Để đổi lại tốc độ cung cấp dữ liệu, các kỹ sư thiết kế GFS quyết định đánh đổi một phần tính nhất quán (consistency) của hệ thống. Hệ thống vẫn chịu lỗi tốt, vì như đã nói nếu có trục trặc trong quá trình ghi mọi thứ liên quan sẽ được rollback, đồng thời Client có thể sẽ được cung cấp một địa chỉ lưu trữ khác để tìm cách ghi dữ liệu đó lần nữa nếu trục trặc tiếp tục xảy ra. Nhưng do Master không trực tiếp theo dõi quá trình trao đổi giữa Client và các server dữ liệu, các thao tác “ghi” mà Client thực hiện trên một server sẽ không lập tức được đồng bộ với các bản sao của nó trong cùng cụm đó. Giải pháp của Google cho vấn đề này là “relaxed consistency model” (Tạm dịch: mô hình nhất quán lỏng). Nói một cách đơn giản thì lý thuyết này cho rằng nếu nhu cầu đang cấp thiết thì cung cấp cho Client địa chỉ của một server chứa dữ liệu hơi cũ cũng… chẳng sao, miễn sao sau đó các thay đổi trên khối dữ liệu sẽ được đồng bộ vào…một lúc nào đó. Theo từng chu kỳ, Master sẽ tìm kiếm thay đổi trên các khối dữ liệu của các server (được quản lý theo “phiên bản” – version) và bảo đảm việc đồng bộ được diễn ra thường xuyên nhất có thể mà vẫn không làm Client phải chờ lâu. Nếu có một server dữ liệu nào đó tụt lại quá xa – ví dụ như có quá nhiều khối dữ liệu cũ hoặc một khối nào đó quá cũ, Master sẽ bảo đảm nó không được “giới thiệu” cho Client nữa đến khi được cập nhật bằng bạn bằng bè.

Nhưng vẫn còn hai vấn đề, tại thời điểm Master phát hiện ra kẻ “tụt hậu” này, các phiên làm việc của Client với nó vẫn tiếp diễn. Client sẽ không biết được các dữ liệu trên đó là phiên bản cũ cho đến khi Master cập nhật cơ sở dữ liệu của mình. Bản thân cơ sở dữ liệu này của Master cũng được sao lưu ra nhiều nơi phòng khi Master hỏng, và không có Master thì các cụm server dữ liệu đó sẽ trở nên vô dụng. Tuy nhiên các thay đổi mà Client thực hiện trên dữ liệu tại thời điểm Master “thăng” cũng sẽ mất và gây ảnh hưởng đến tính nhất quán, bất kể có backup thường xuyên thế nào đi chăng nữa. Một lần nữa điều này được giải quyết bằng lý thuyết chứ không phải bằng một công nghệ đột phá gì: đại đa số các dữ liệu phục vụ việc tìm kiếm không cần phải được cập nhật mới với tốc độ quá khủng khiếp (đó cũng là lí do cho phát biểu ở trên: việc lấy lượng lớn dữ liệu ra mới là quan trọng”), và các thay đổi thường là bổ sung dữ liệu mới, chứ không phải thay thế dữ liệu cũ. Hai vấn đề cùng được giải quyết chỉ bằng một lý luận ngắn gọn này, nhưng rốt cuộc điều đó chỉ đúng với bộ máy tìm kiếm mà thôi.

Bigtable
Như bạn đọc cũng đoán được, khi Google bổ sung các dịch vụ khác như Youtube, Google Docs .v.v.. việc chỉ dựa vào một hệ thống quản lý dữ liệu theo từng khối, tại không chú trọng tính nhất quán là hoàn toàn không phù hợp. Để giải quyết vấn đề này, trên nền GFS hãng đã bổ sung Bigtable, công nghệ quản lý dữ liệu có dạng như một cơ sở dữ liệu. Mọi thứ được quản lý dưới dạng “bảng” (table) (cũng là lý do nhiều người coi BigTable có dạng như cơ sở dữ liệu dù rằng nói chính xác thì không phải vậy). Với hàng tỷ (vâng, hàng tỷ) webpage cần được lưu, các BigTable có tên hàng là các URL và các đặc tính liên quan của webpage đó (keyword, ngôn ngữ.v.v. ) làm tên các cột. Nội dung của trang đó sẽ được lưu vào các ô tương ứng với thông tin về thời điểm ghi, phiên bản (timestamp). Về cơ bản, cách mà Bigtable xử lý dữ liệu cũng vẫn khá giống GFS: ưu tiên việc đọc dữ liệu hơn và các thay đổi chủ yếu được thực hiện dưới dạng bổ sung, đi kèm là một chỉ số “phiên bản” chứ không trực tiếp thay đổi các dữ liệu cũ (kể cả là các dữ liệu cho dịch vụ dạng Google Docs cũng được quản lý theo dạng này). Tuy vậy cách tổ chức dạng bảng này cũng đủ khác biệt để giúp khắc phục các khó khăn trước đó mà Google gặp phải khi mở rộng số lượng dịch vụ mà chỉ dựa vào GFS. Như chúng ta đều thấy, các dịch vụ mail, video, calendar.v.v.. chúng ta đang sử dụng ngày nay được cập nhật mới khá chính xác. Đi sâu hơn về chi tiết kỹ thuật, Bigtable sẽ khá khó hiểu cho những ai không có nền tảng về cơ sở dữ liệu cũng như hệ thống thông tin nói chúng, vì vậy chúng ta sẽ từ biệt Google ở đây để chuẩn bị “nhòm ngó” Amazon và Microsoft trong các bài sắp tới.

GenK