Này Habr! Tên tôi là Maxim Vasiliev, tôi là nhà phân tích và quản lý dự án tại FINCH. Hôm nay tôi muốn cho bạn biết làm thế nào, bằng cách sử dụng Tìm kiếm đàn hồi, chúng tôi có thể xử lý 15 triệu yêu cầu trong 6 phút và tối ưu hóa tải hàng ngày trên trang web của một trong những khách hàng của chúng tôi. Thật không may, chúng tôi sẽ phải làm mà không có tên, vì chúng tôi có NDA, chúng tôi hy vọng rằng nội dung của bài viết sẽ không bị ảnh hưởng bởi điều này. Đi nào.
Cách thức hoạt động của dự án
Trên phần phụ trợ của chúng tôi, chúng tôi tạo ra các dịch vụ đảm bảo hiệu suất của các trang web và ứng dụng di động của khách hàng. Cấu trúc chung có thể được nhìn thấy trong sơ đồ:
Trong quá trình làm việc, chúng tôi xử lý một số lượng lớn giao dịch: mua hàng, thanh toán, thao tác với số dư người dùng mà chúng tôi lưu trữ rất nhiều nhật ký, cũng như nhập và xuất dữ liệu này sang hệ thống bên ngoài.
Cũng có những quy trình ngược lại khi chúng ta nhận dữ liệu từ client và chuyển đến user. Ngoài ra, vẫn còn các quy trình làm việc với các khoản thanh toán và chương trình tiền thưởng.
Tóm tắt tiểu sử
Ban đầu, chúng tôi sử dụng PostgreSQL làm nơi lưu trữ dữ liệu duy nhất. Ưu điểm tiêu chuẩn của nó đối với một DBMS: sự hiện diện của các giao dịch, ngôn ngữ lấy mẫu dữ liệu được phát triển, một loạt các công cụ để tích hợp; kết hợp với hiệu suất tốt đáp ứng nhu cầu của chúng tôi trong một thời gian khá dài.
Chúng tôi lưu trữ hoàn toàn tất cả dữ liệu trong Postgres: từ giao dịch đến tin tức. Nhưng số lượng người dùng tăng lên và cùng với đó là số lượng yêu cầu.
Để dễ hiểu, số phiên hàng năm chỉ trong năm 2017 trên trang web dành cho máy tính để bàn là 131 triệu. Năm 2018 - 125 triệu. Năm 2019 lại là 130 triệu. Thêm 100-200 triệu khác từ phiên bản di động của trang web và ứng dụng di động, và bạn sẽ nhận được một số lượng lớn các yêu cầu.
Với sự phát triển của dự án, Postgres ngừng đối phó với tải, chúng tôi không có thời gian - một số lượng lớn các truy vấn khác nhau xuất hiện mà chúng tôi không thể tạo đủ số lượng chỉ mục.
Chúng tôi hiểu rằng cần có các kho lưu trữ dữ liệu khác để đáp ứng nhu cầu của chúng tôi và giảm tải cho PostgreSQL. Elaticsearch và MongoDB được coi là các tùy chọn khả thi. Cái sau thua ở những điểm sau:
- Tốc độ lập chỉ mục chậm khi lượng dữ liệu trong các chỉ mục tăng lên. Với Elastic, tốc độ không phụ thuộc vào lượng dữ liệu.
- Không có tìm kiếm toàn văn
Vì vậy, chúng tôi đã chọn Đàn hồi cho mình và chuẩn bị cho quá trình chuyển đổi.
Chuyển sang đàn hồi
1. Chúng tôi bắt đầu chuyển đổi từ dịch vụ tìm kiếm điểm bán hàng. Khách hàng của chúng tôi có tổng cộng khoảng 70 điểm bán hàng và điều này yêu cầu một số loại tìm kiếm trên trang web và trong ứng dụng:
- Tìm kiếm văn bản theo tên thành phố
- Tìm kiếm địa lý trong một bán kính nhất định từ một số điểm. Ví dụ người dùng muốn xem điểm bán hàng nào gần nhà mình nhất.
- Tìm kiếm theo một hình vuông nhất định - người dùng vẽ một hình vuông trên bản đồ và tất cả các điểm trong bán kính này được hiển thị cho anh ta.
- Tìm kiếm bằng các bộ lọc bổ sung. Các điểm bán hàng khác nhau trong các loại
Nếu chúng ta nói về tổ chức, thì trong Postgres, chúng ta có nguồn dữ liệu cho cả bản đồ và tin tức, còn trong Ảnh chụp nhanh đàn hồi được lấy từ dữ liệu gốc. Thực tế là ban đầu Postgres không thể đối phó với việc tìm kiếm theo tất cả các tiêu chí. Không chỉ có nhiều chỉ mục mà chúng còn có thể chồng lên nhau, vì vậy bộ lập lịch Postgres bị lạc và không hiểu nên sử dụng chỉ mục nào.
2. Tiếp theo là phần tin tức. Các ấn phẩm xuất hiện trên trang web mỗi ngày để người dùng không bị lạc trong luồng thông tin, dữ liệu phải được sắp xếp trước khi phát hành. Đây là mục đích tìm kiếm: bạn có thể tìm kiếm trang web bằng cách khớp văn bản, đồng thời kết nối các bộ lọc bổ sung, vì chúng cũng được tạo thông qua Đàn hồi.
3. Sau đó, chúng tôi chuyển sang xử lý giao dịch. Người dùng có thể mua một sản phẩm nhất định trên trang web và tham gia rút thăm trúng thưởng. Sau những lần mua như vậy, chúng tôi xử lý một lượng lớn dữ liệu, đặc biệt là vào cuối tuần và ngày lễ. Để so sánh, nếu vào những ngày bình thường, số lượng mua vào khoảng 1,5-2 triệu, thì vào những ngày lễ, con số này có thể lên tới 53 triệu.
Đồng thời, dữ liệu phải được xử lý trong thời gian ngắn nhất có thể - người dùng không muốn đợi kết quả trong vài ngày. Không có cách nào để đạt được thời hạn như vậy thông qua Postgres - chúng tôi thường nhận được các khóa và trong khi chúng tôi đang xử lý tất cả các yêu cầu, người dùng không thể kiểm tra xem họ có nhận được giải thưởng hay không. Điều này không dễ chịu cho doanh nghiệp, vì vậy chúng tôi đã chuyển quá trình xử lý sang Elaticsearch.
Định kỳ
Giờ đây, các bản cập nhật được định cấu hình dựa trên sự kiện, theo các điều kiện sau:
- Điểm bán hàng. Ngay khi chúng tôi nhận được dữ liệu từ một nguồn bên ngoài, chúng tôi sẽ bắt đầu cập nhật ngay lập tức.
- Tin tức. Ngay sau khi bất kỳ tin tức nào được chỉnh sửa trên trang web, nó sẽ tự động được gửi đến Elastic.
Ở đây một lần nữa, điều đáng nói là những lợi thế của Đàn hồi. Trong Postgres, khi gửi yêu cầu, bạn phải đợi cho đến khi nó xử lý tất cả các bản ghi một cách trung thực. Bạn có thể gửi 10 bản ghi đến Đàn hồi và bắt đầu làm việc ngay lập tức mà không cần chờ các bản ghi được phân phối trên tất cả các Phân đoạn. Tất nhiên, một số Shard hoặc Replica có thể không nhìn thấy dữ liệu ngay lập tức, nhưng mọi thứ sẽ sớm có sẵn.
phương pháp tích hợp
Có 2 cách để tích hợp với Elastic:
- Thông qua một máy khách gốc qua TCP. Trình điều khiển gốc đang dần chết đi: nó không còn được hỗ trợ, nó có một cú pháp rất bất tiện. Do đó, chúng tôi thực tế không sử dụng nó và cố gắng từ bỏ nó hoàn toàn.
- Thông qua giao diện HTTP có thể sử dụng cả yêu cầu JSON và cú pháp Lucene. Cái cuối cùng là một công cụ văn bản sử dụng Đàn hồi. Trong phiên bản này, chúng tôi có khả năng Batch thông qua các yêu cầu JSON qua HTTP. Đây là tùy chọn chúng tôi đang cố gắng sử dụng.
Nhờ giao diện HTTP, chúng tôi có thể sử dụng các thư viện cung cấp triển khai không đồng bộ cho ứng dụng khách HTTP. Chúng ta có thể tận dụng Batch và API không đồng bộ, mang lại hiệu suất cao, giúp ích rất nhiều trong những ngày khuyến mãi lớn (thêm về điều đó bên dưới)
Một số con số để so sánh:
- Lưu người dùng tiền thưởng Postgres trong 20 chủ đề mà không cần nhóm: 460713 bản ghi trong 42 giây
- Máy khách đàn hồi + phản ứng cho 10 luồng + lô cho 1000 phần tử: 596749 bản ghi trong 11 giây
- Máy khách đàn hồi + phản ứng cho 10 luồng + đợt cho 1000 phần tử: 23801684 mục trong 4 phút
Bây giờ chúng tôi đã viết trình quản lý yêu cầu HTTP xây dựng JSON dưới dạng Batch / not Batch và gửi nó qua bất kỳ ứng dụng khách HTTP nào, bất kể thư viện. Bạn cũng có thể chọn gửi yêu cầu đồng bộ hoặc không đồng bộ.
Trong một số tích hợp, chúng tôi vẫn sử dụng ứng dụng khách truyền tải chính thức, nhưng đây chỉ là vấn đề của lần tái cấu trúc tiếp theo. Trong trường hợp này, một ứng dụng khách tùy chỉnh được xây dựng trên cơ sở Spring WebClient được sử dụng để xử lý.
khuyến mãi lớn
Mỗi năm một lần, dự án tổ chức một chương trình khuyến mãi lớn cho người dùng - đây cũng là Highload, vì tại thời điểm này, chúng tôi làm việc với hàng chục triệu người dùng cùng một lúc.
Thông thường, lượng tải cao nhất xảy ra trong các ngày lễ, nhưng chương trình khuyến mãi này ở một cấp độ hoàn toàn khác. Năm ngoái, vào ngày khuyến mãi, chúng tôi đã bán được 27 đơn vị hàng hóa. Dữ liệu được xử lý trong hơn nửa giờ, gây bất tiện cho người dùng. Người dùng đã nhận được giải thưởng khi tham gia, nhưng rõ ràng là quá trình này cần phải được đẩy nhanh hơn.
Vào đầu năm 2019, chúng tôi quyết định rằng chúng tôi cần Tìm kiếm đàn hồi. Trong cả năm, chúng tôi đã tổ chức xử lý dữ liệu nhận được trong Đàn hồi và phát hành chúng trong api của ứng dụng di động và trang web. Kết quả là, năm tiếp theo trong chiến dịch, chúng tôi đã xử lý 15 mục nhập trong 131 phút.
Vì chúng tôi có rất nhiều người muốn mua hàng và tham gia bốc thăm trúng thưởng trong các chương trình khuyến mãi nên đây chỉ là biện pháp tạm thời. Hiện tại, chúng tôi đang gửi thông tin cập nhật đến Elastic, nhưng trong tương lai, chúng tôi dự định chuyển thông tin được lưu trữ trong những tháng qua sang Postgres dưới dạng lưu trữ vĩnh viễn. Để không làm tắc nghẽn chỉ số Đàn hồi, cũng có những hạn chế của nó.
Kết luận/Kết luận
Hiện tại, chúng tôi đã chuyển tất cả các dịch vụ mà chúng tôi muốn sang Đàn hồi và hiện đã tạm dừng dịch vụ này. Bây giờ chúng tôi đang xây dựng một chỉ mục trong Đàn hồi trên bộ lưu trữ liên tục chính trong Postgres, bộ lưu trữ này đảm nhận tải của người dùng.
Trong tương lai, chúng tôi dự định chuyển dịch vụ nếu chúng tôi hiểu rằng yêu cầu dữ liệu trở nên quá đa dạng và được tìm kiếm với số lượng cột không giới hạn. Đây không còn là một nhiệm vụ cho Postgres.
Nếu chúng tôi cần chức năng tìm kiếm toàn văn hoặc nếu chúng tôi có nhiều tiêu chí tìm kiếm khác nhau, thì chúng tôi đã biết rằng điều này cần được dịch sang Đàn hồi.
⌘⌘⌘
Cảm ơn vì đã đọc. Nếu công ty của bạn cũng sử dụng Tìm kiếm đàn hồi và có các trường hợp triển khai riêng, hãy cho chúng tôi biết. Sẽ rất thú vị khi biết người khác thế nào 🙂
Nguồn: www.habr.com