
Ở 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. 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 đó? 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.

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.

Để đá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.

Đ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 đủ

Để đổ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
