bởi Neha Gupta, Kanica Mandhania và Vishal Gupta | vào ngày 22 tháng 12 năm 2023 |

Bài viết này được viết chung với Neha Gupta & Kanica Mandhania từ Zomato.

Zomato, một công ty tập đoàn nhà hàng, giao hàng thức ăn và ăn tại chỗ có trụ sở tại Ấn Độ, hoạt động tại hơn 1.000 thành phố và liệt kê hơn 350.000 nhà hàng. Từ khi thành lập vào năm 2008, Zomato đã phát triển mạnh mẽ, cả về phạm vi và quy mô — và đã trở thành nhà cung cấp hàng đầu trong ngành công nghệ thực phẩm của Ấn Độ. Khi nhu cầu đặt hàng thức ăn trực tuyến tiếp tục tăng, Zomato nhận ra tầm quan trọng của sự đổi mới trong việc đáp ứng yêu cầu về khả năng mở rộng.

Xem xét tính chất của doanh nghiệp của chúng tôi, lưu lượng khách hàng chủ yếu tập trung vào các thời gian ăn, dẫn đến sự khác biệt đáng kể trong công việc giữa giờ cao điểm và giờ không cao điểm. Ngoài ra, vào các dịp đặc biệt như Diwali và Lễ Năm mới, Zomato trải qua làn sóng lưu lượng lớn với các đỉnh cao đáng kể so với các ngày thông thường. Do đó, việc lựa chọn một cơ sở dữ liệu đảm bảo độ trễ thấp và ổn định liên tục là rất quan trọng cho Zomato, bất kể quy mô, và có khả năng xử lý các đỉnh lưu lượng mà không cần chi phí đắt đỏ trong các thời kỳ hoạt động thấp hơn.

Trong bài viết này, chúng tôi giải thích những yếu tố chính đã thúc đẩy Zomato chuyển từ cơ sở dữ liệu quan hệ và TiDB sang Amazon DynamoDB, một cơ sở dữ liệu NoSQL key-value hoàn toàn được quản lý, không máy chủ, không máy chủ. Điều này cho phép chúng tôi quản lý hiệu quả các đỉnh lưu lượng mà không cần chi phí đắt đỏ trong các giai đoạn hoạt động giảm và thậm chí chi phí sở hữu tổng thể còn thấp hơn (TCO).

Nền tảng Thanh toán của Zomato

Nền tảng Thanh toán của Zomato chịu trách nhiệm quản lý các quy trình sau đặt hàng, chủ yếu tập trung vào việc duy trì sổ cái và xử lý thanh toán cho các dự án kinh doanh khác nhau như Đặt hàng trực tuyến, Ăn tại chỗ, Blinkit, Hyperpure và Feeding India. Nền tảng này hiệu quả quản lý việc phân phối thanh toán cho các đối tác nhà hàng và người giao hàng với quy mô lớn.

Tính đến thời điểm viết bài này, Nền tảng Thanh toán của Zomato xử lý khoảng 10 triệu sự kiện trong một ngày bình thường. Điều này dẫn đến khoảng 1 triệu thanh toán mỗi tuần. Bởi vì việc tạo hóa đơn và xử lý thanh toán là một chức năng quan trọng đối với Zomato, tính sẵn có và sự linh hoạt của hệ thống thanh toán là quan trọng cho sự thành công của doanh nghiệp của chúng tôi.

Kiến trúc Nền tảng Thanh toán của Zomato tuân theo một phương pháp gửi tin nhắn không đồng bộ sử dụng Kafka để tích hợp các dịch vụ micro dựa trên nhau một cách lỏng lẻo để hoạt động với quy mô và phát triển một cách độc lập và linh hoạt. Nền tảng này hoạt động như cả người sản xuất và người tiêu thụ của các sự kiện kafka tiêu thụ đơn đặt hàng thanh toán, xử lý nó và sản xuất sổ cái được xử lý cho các trường hợp sử dụng kinh doanh khác nhau. Sơ đồ sau mô tả kiến trúc kế thừa.

Nền tảng Thanh toán của Zomato sử dụng TiDB, một cơ sở dữ liệu SQL phân tán mã nguồn mở hỗ trợ xử lý giao dịch trực tuyến (OLTP) và xử lý phân tích trực tuyến (OLAP). Nó kết hợp khả năng mở rộng của cơ sở dữ liệu NoSQL với tính tuân thủ ACID của các cơ sở dữ liệu quan hệ truyền thống. Kiến ​​trúc phân tán của nó cho phép khả năng mở rộng theo chiều ngang, khả năng chịu lỗi và khả năng có sẵn cao. Hệ thống TiDB bao gồm nhiều thành phần tương tác với nhau để tạo thành một hệ thống hoàn chỉnh.

Các thành phần chính sau của hệ thống TiDB cần được bảo trì:

• Máy chủ TiDB – Máy chủ TiDB hoạt động như một lớp SQL không trạng thái, cung cấp truy cập bên ngoài thông qua giao thức MySQL. Nó có thể được mở rộng theo chiều ngang và cung cấp một giao diện thống nhất thông qua các thành phần cân bằng tải.
• Máy chủ Placement Driver – Máy chủ Placement Driver (PD) quản lý siêu dữ liệu và các lệnh lập lịch dữ liệu trong cụm. Nó hoạt động như bộ não của cụm bằng cách lưu trữ siêu dữ liệu và gán nhiệm vụ phân phối dữ liệu động cho các nút TiKV dựa trên các báo cáo thời gian thực.
• Máy chủ TiKV – Máy chủ TiKV chịu trách nhiệm lưu trữ dữ liệu phân tán và hoạt động như một bộ lưu trữ khóa-giá trị có tính chất giao dịch.
• Máy chủ TiFlash – Máy chủ TiFlash là một máy chủ lưu trữ cột chuyên biệt được tối ưu hóa cho việc xử lý phân tích nhanh chóng, lưu trữ dữ liệu theo cột để cải thiện hiệu suất.

Những thách thức với thiết kế ban đầu

Ban đầu, Zomato đã tích hợp TiDB vào thiết kế ban đầu để quản lý các khối công việc OLTP của chúng tôi. Quyết định sử dụng TiDB được dựa trên chuyên môn của đội ngũ kỹ thuật của Zomato trong mô hình quan hệ và MySQL, cũng như khả năng của nó để mở rộng theo chiều ngang và đáp ứng nhu cầu về mức mở rộng.

Qua các năm, quy mô mà Zomato hoạt động đã phát triển mạnh mẽ, và với sự thêm vào của Blinkit và HyperPure, chúng tôi cũng cần nền tảng thanh toán của mình phải hỗ trợ nhiều người dùng. Chúng tôi đã phải đối mặt với một số thách thức khi mở rộng và duy trì cơ sở dữ liệu TiDB của chúng tôi:

• Khi các hoạt động của chúng tôi mở rộng, chúng tôi đã gặp phải những thách thức trong việc xử lý thay đổi schema và quan sát sự giảm hiệu suất truy vấn, đặc biệt là trong các bảng lớn với hàng tỷ hàng và dữ liệu có dung lượng nhiều terabyte. Hơn nữa, các vấn đề hiệu suất đã nảy sinh trong các khối công việc cụ thể liên quan đến các truy vấn phụ hoặc kết hợp nhiều bảng.
• Tính phân tán của TiDB đã đưa ra thêm phức tạp so với các cơ sở dữ liệu đơn nút. Một ví dụ như thêm các nút có dung lượng lớn hơn vào một cụm cân bằng để mở rộng. Điều này dẫn đến việc nút được chỉ định trở thành nút chính cho các hoạt động ghi, dẫn đến việc sử dụng CPU cao hơn và ảnh hưởng tiêu cực đến hiệu suất tổng thể của dịch vụ. Điều này, lần lượt, dẫn đến việc đảm bảo mức dịch vụ kém, trải nghiệm khách hàng bị ảnh hưởng và việc thanh toán bị trì hoãn.
• Chúng tôi đã mở rộng kích thước cụm từ 5 nút lên 25 nút trong cả các cụm chính và sao chép để phù hợp với quy mô và dữ liệu ngày càng tăng. Ngoài ra, vào các ngày cao điểm với dự đoán lưu lượng cao, cơ sở hạ tầng đã được mở rộng thủ công và giữ ở trạng thái quá mức để ngăn ngừa các vấn đề hiệu suất. Tất cả điều này đã dẫn đến sự tăng về TCO và khiến nó trở thành một giải pháp ít có khả năng mở rộng hơn.
• Chúng tôi đã lựa chọn TiDB khi TiDB Cloud chưa được ra mắt. Vì cơ sở dữ liệu TiDB được tự quản lý, đội ngũ của chúng tôi đã tiếp tục thực hiện phần lớn công việc để đảm bảo hoạt động đáng tin cậy của nó. Điều này bao gồm các nhiệm vụ như đồng bộ hóa sao chép, giám sát lưu trữ, thêm các nút bổ sung và quản lý sao lưu. Việc di chuyển sang các phiên bản mới cũng đòi hỏi nỗ lực và thời gian lớn. Theo thời gian, tất cả những yếu tố này kết hợp lại trở thành một gánh nặng đối với các đội của chúng tôi.
• Khi kích thước của cơ sở dữ liệu tăng lên, các nhiệm vụ sao lưu trở nên mất thời gian hoàn thành hơn do khối lượng dữ liệu lớn được xử lý. Điều này làm tăng độ trễ trong quá trình sao lưu tổng thể và dẫn đến tình trạng chúng tôi không thể đáp ứng được các SLA đã thỏa thuận.

Tại sao chọn DynamoDB

DynamoDB là một dịch vụ cơ sở dữ liệu hoàn toàn được quản lý, không cần máy chủ, NoSQL, với thời gian phản hồi trong phạm vi một số chữ số mili giây ở mọi quy mô, cho phép bạn phát triển và vận hành các ứng dụng hiện đại chỉ bằng cách thanh toán cho những gì bạn sử dụng.

Ngoài việc rằng chúng tôi đã sử dụng DynamoDB cho nhiều dịch vụ quan trọng cho doanh nghiệp tại Zomato, các tính năng chính sau của DynamoDB làm nổi bật các tính năng quan trọng tăng tính mở rộng, tăng năng suất của nhà phát triển, giảm thời gian bỏ ra cho các nhiệm vụ lặp đi lặp lại và giảm tổng chi phí của chúng tôi:

• DynamoDB duy trì hiệu suất nhất quán khi ứng dụng của bạn mở rộng, đảm bảo rằng bất kỳ hoạt động nào cũng sẽ có thời gian phản hồi đáng tin cậy trong khoảng vài mili giây, không phụ thuộc vào kích thước cơ sở dữ liệu hoặc số lượng truy vấn đồng thời.
• Theo một quy tắc chung cho việc mô hình hóa dữ liệu, các dữ liệu liên quan được giữ cùng nhau. Do đó, DynamoDB không cần một trình lập kế hoạch truy vấn để phân tích một truy vấn thành một quy trình đa bước để đọc, kết hợp và tổng hợp dữ liệu từ các vị trí khác nhau trên đĩa. Điều này cho phép DynamoDB hỗ trợ tìm kiếm với độ trễ thấp và làm cho các truy vấn hiệu quả khi quy mô tăng lên. Nó cũng giải phóng nhà phát triển và DBA khỏi trách nhiệm tinh chỉnh hiệu suất vì bạn không cần phải dành thời gian để gỡ lỗi các kế hoạch truy vấn hoặc tìm hiểu tại sao hiệu suất truy vấn giảm khi quy mô tăng lên.
• DynamoDB cung cấp tính năng tự động điều chỉnh khả năng mở rộng có thể sửa đổi tài nguyên cơ sở dữ liệu của chúng tôi (khả năng thông lượng được cung cấp) theo lưu lượng người dùng. Điều này giúp chúng tôi mở rộng cho các đợt tăng lưu lượng đột ngột và không mở rộng quá mức cho các khối công việc cao điểm so với TiDB—tất cả đều trong khi duy trì thời gian trễ nhất quán một cách hiệu quả và tiết kiệm chi phí.
• Khác với TiDB, DynamoDB loại bỏ nhu cầu cho các tác vụ thiết lập và quản lý thủ công. Nó không cần máy chủ, có nghĩa là bạn không cần phải xử lý việc cung cấp phần cứng, cấu hình, sao chép, vá phần mềm, sao lưu cơ sở dữ liệu hoặc mở rộng cụm mình.

Tổng quan giải pháp

Để giải quyết các vấn đề đã nêu, nhóm kỹ thuật của Zomato đã xác định nhu cầu phải thiết kế lại lớp lưu trữ dữ liệu. Sau khi tiến hành một đánh giá kỹ lưỡng của các cơ sở dữ liệu khác nhau, nhóm kỹ thuật quyết định sử dụng DynamoDB. Phần này làm nổi bật các điểm chính đã hướng dẫn quy trình tiếp cận của chúng tôi.

Thiết kế bảng duy nhất

Trong thiết kế gốc của TiDB, chúng tôi tuân theo phương pháp quản lý cơ sở dữ liệu quan hệ truyền thống (RDBMS). Mỗi bảng được dành riêng để lưu trữ dữ liệu cho một thực thể cụ thể và có một khóa duy nhất kết nối với một khóa ngoại trong bảng khác. Để truy xuất dữ liệu từ các bảng liên quan và hiển thị kết quả dưới dạng một cái nhìn thống nhất, một hoạt động JOIN liên quan đến nhiều bảng được thực hiện. Ví dụ, chúng tôi có các tập hợp bảng riêng biệt cho mỗi ngành kinh doanh (như Giao hàng đồ ăn, Ăn tại nhà và HyperPure), chứa các thực thể như chi tiết thanh toán, sổ cái thanh toán, ánh xạ đơn thanh toán và phân rã thanh toán, như minh họa trong hình dưới đây.

Dựa trên kinh nghiệm sử dụng DynamoDB cho nhiều dịch vụ microservices, chúng tôi quyết định tinh giản mô hình quan hệ này thành một bảng DynamoDB thống nhất bằng cách sử dụng mẫu thiết kế danh sách kề, bao gồm tất cả các doanh nghiệp và lưu trữ dữ liệu cho các thực thể khác nhau. Chiến lược này hiệu quả hóa việc tập trung dữ liệu liên quan vào một bảng duy nhất (xem hình dưới đây), tăng hiệu suất bằng cách loại bỏ nhu cầu truy xuất dữ liệu từ các vị trí khác nhau trên đĩa. Nó cũng giảm chi phí, đặc biệt là cho các hoạt động đọc, vì một hoạt động đọc duy nhất bây giờ truy xuất tất cả dữ liệu cần thiết thay vì nhiều truy vấn cho các thực thể khác nhau.

Trong DynamoDB, dữ liệu được phân tán qua các phân vùng, là các đơn vị lưu trữ vật lý. Mỗi bảng có thể có nhiều phân vùng, và trong hầu hết các trường hợp, khóa phân vùng xác định nơi lưu trữ dữ liệu. Đối với các bảng có khóa chính kết hợp, khóa sắp xếp có thể được sử dụng làm ranh giới phân vùng. DynamoDB chia phân vùng theo khóa sắp xếp nếu kích thước bộ sưu tập lớn hơn 10 GB. Thiết kế một lược đồ và xác định khóa phân vùng là rất quan trọng để truy cập dữ liệu một cách hiệu quả. Sự mất cân đối trong việc truy cập dữ liệu có thể dẫn đến các phân vùng nóng, nơi một phân vùng gặp phải một khối lượng công việc lớn hơn, gây ra hạn chế và sử dụng không hiệu quả của năng lượng I/O.

Chúng tôi giải quyết vấn đề này bằng cách kết hợp khóa phân vùng với các thuộc tính kết hợp, cho phép phân phối dữ liệu qua nhiều phân vùng. Khóa phân vùng cho bảng duy nhất được xây dựng bằng cách kết hợp ID nhà cung cấp, chu kỳ thanh toán và ngành kinh doanh, với mỗi phần tử được phân tách bằng một dấu phân cách. Đối với công việc của chúng tôi, phương pháp này cải thiện độ mạnh của khóa phân vùng và đảm bảo rằng các hoạt động đọc và ghi được phân phối càng đều càng tốt trên các bảng, tránh hiện tượng hiệu suất kém.

Ngoài ra, chúng tôi sử dụng phương pháp chỉ mục nghịch đảo để truy vấn dữ liệu. Mẫu thiết kế chỉ mục phụ này thường được sử dụng với DynamoDB. Điều này cho phép truy vấn phía bên kia của mối quan hệ nhiều-nhiều, điều này thường không thực hiện được trong một phương pháp lưu trữ key-value tiêu chuẩn.

Tương tự như khóa phân vùng của bảng chính, việc đảm bảo phân phối đều các hoạt động đọc và ghi trên các phân vùng cho khóa phân vùng của một chỉ mục phụ toàn cầu (GSI) là rất quan trọng để ngăn chặn việc hạn chế. Điều này được đạt được bằng cách giới thiệu một số, được gọi là số phân chia (dựa trên một logic kinh doanh), cùng với khóa chỉ mục. Do đó, định dạng GSI được cập nhật bây giờ được biểu thị là <index-key>_<division-number>.

Phương pháp di chuyển

Chúng tôi muốn có một quá trình chuyển đổi mượt mà từ TiDB sang DynamoDB mà không có thời gian chết và không gây ra gián đoạn cho các hoạt động đang diễn ra. Chúng tôi đã sử dụng một phương pháp theo từng giai đoạn với các chiến lược như ghi đồng thời, sao chép, đồng bộ dữ liệu và cơ chế chuyển giao để đảm bảo sự sẵn có liên tục của dữ liệu của chúng tôi trong suốt quá trình di chuyển.

Biểu đồ dưới đây minh họa chi tiết từng giai đoạn.

Phương pháp này đã cho phép Zomato duy trì quyền truy cập không bị gián đoạn đến thông tin quan trọng của chúng tôi, đảm bảo hoạt động trôi chảy và giảm thiểu bất kỳ ảnh hưởng tiêu cực nào đối với năng suất hoặc trải nghiệm của khách hàng.

Kết quả di chuyển

Trong phần này, chúng tôi thảo luận về hiệu suất và khả năng mở rộng tăng lên mà Zomato đã đạt được với giải pháp này.

Hiệu suất

Quyết định chuyển từ TiDB sang DynamoDB chủ yếu được thúc đẩy bởi mục tiêu nâng cao hiệu suất của ứng dụng và giảm sự phức tạp trong vận hành. Sự cải thiện về hiệu suất được mô tả trong hình dưới đây cho thấy sự giảm trung bình 90% về thời gian phản hồi của các dịch vụ nhỏ. Một quan sát đáng chú ý khác là bất kể mức độ lưu lượng, thời gian phản hồi của các dịch vụ nhỏ vẫn luôn ổn định ở mức khoảng 75 mili giây.

Khả năng mở rộng

Hiệu suất của lớp cơ sở dữ liệu trong kiến ​​trúc trước đó trở thành một rào cản đáng kể, dẫn đến việc các dịch vụ nhỏ chỉ đạt được một lưu lượng tối đa là 2.000 yêu cầu mỗi phút (xem hình dưới đây). Điều quan trọng là phải giải quyết hạn chế này trong lớp cơ sở dữ liệu để tăng khả năng xử lý của các dịch vụ nhỏ và hiệu suất tổng thể, đồng thời đáp ứng yêu cầu về khả năng mở rộng của Zomato.

Sau khi di chuyển sang DynamoDB, hiệu suất của cơ sở dữ liệu đã cải thiện đáng kể, giải quyết thành công rào cản tại cấp độ cơ sở dữ liệu. Do đó, với quy mô hiện tại, lưu lượng của dịch vụ nhỏ tăng lên 8.000 yêu cầu mỗi phút, cho phép Zomato xử lý bốn lần lưu lượng giao thông so với thiết kế trước đó. Sự tăng cường về lưu lượng đã dẫn đến việc giảm độ trễ và thanh toán gần thời gian thực, góp phần cải thiện SLA.

Chi phí

Trong giải pháp mới với DynamoDB, chúng tôi chỉ trả tiền cho những gì chúng tôi sử dụng, khác với phương pháp trước đó với TiDB, trong đó liên quan đến việc cung cấp quá nhiều cho cơ sở dữ liệu để đáp ứng các đỉnh lưu lượng đột ngột. Kết quả là, chi phí hàng tháng của hệ thống thanh toán của chúng tôi đã giảm đáng kể 50% do những thay đổi này.

Kết luận

Trong bài viết này, chúng tôi đã thảo luận về cách Zomato đã thành công trong việc di chuyển từ TiDB sang DynamoDB mà không gây ra bất kỳ thời gian chết nào hoặc ảnh hưởng tiêu cực đến trải nghiệm của khách hàng. Quá trình chuyển đổi được triển khai một cách mượt mà, cho phép Zomato phục vụ một cách hiệu quả cho cơ sở người dùng mở rộng của chúng tôi bằng cách xử lý bốn lần giao dịch hơn, giảm độ trễ gần như 90%, và tối ưu hóa chi phí cơ sở dữ liệu 50%. Ngoài ra, giải pháp này cũng cải thiện thời gian báo cáo tổng thể của chúng tôi, từ đó giúp chúng tôi ra quyết định tốt hơn hàng ngày. Nó cũng cải thiện thời gian phản hồi cho báo cáo tài khoản của các thương nhân, nâng cao trải nghiệm người dùng và SLA trên tất cả các bên liên quan.

Để tìm hiểu thêm về cách tối đa hóa hiệu suất và giảm thiểu chi phí lưu lượng khi sử dụng DynamoDB, xem Hướng dẫn thực hành tốt nhất cho thiết kế và kiến trúc với DynamoDB.

Về tác giả

Neha Gupta đang làm việc với tư cách là quản lý kỹ thuật tại Zomato với 7 năm kinh nghiệm. Cô chịu trách nhiệm thiết kế và phát triển các giải pháp mạnh mẽ và có khả năng mở rộng có thể xử lý lượng dữ liệu lớn một cách hiệu quả.

Kanica Mandhania đang làm việc với tư cách là SDE-III tại Zomato, mang theo 7 năm kinh nghiệm cho vai trò của mình. Cô ấy đam mê tận dụng công nghệ để giải quyết thách thức của khách hàng và thích xây dựng các sản phẩm làm đơn giản cuộc sống.

Vishal Gupta là một Kiến trúc sư Giải pháp Cấp cao tại AWS India, đóng trụ sở tại Delhi. Vishal làm việc với các tập đoàn lớn và các doanh nghiệp số người dân (DNB) và giúp họ thiết kế, kiến trúc và đổi mới các giải pháp có khả năng mở rộng và linh hoạt trên nền tảng AWS. Ngoài công việc, anh ấy thích đi du lịch đến các điểm đến mới và dành thời gian bên gia đình.