Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them Tải công việc cơ sở dữ liệu nặng viết mang lại một tập hợp các thách thức khác nhau rõ ràng so với những người nặng đọc. Tăng quy mô chữ viết có thể tốn kém, đặc biệt nếu bạn trả tiền cho mỗi hoạt động và chữ viết tốn kém hơn 5 lần so với chữ đọc. Locking có thể thêm sự chậm trễ và giảm thông lượng I/O bottlenecks có thể dẫn đến viết amplification và phức tạp crash recovery Backpressure cơ sở dữ liệu có thể thổi tải vào Trong khi chi phí quan trọng - khá nhiều, trong nhiều trường hợp - đó không phải là một chủ đề mà chúng tôi muốn đề cập ở đây.Thay vào đó, hãy tập trung vào những phức tạp liên quan đến hiệu suất mà các đội thường phải đối mặt và thảo luận về các lựa chọn của bạn để giải quyết chúng. Chúng tôi có nghĩa là gì bởi "một thời gian thực viết tải công việc nặng"? Đầu tiên, chúng ta hãy làm rõ những gì chúng ta có nghĩa là một khối lượng công việc "thời gian thực viết nặng". chúng ta đang nói về khối lượng công việc mà: Lấy một lượng lớn dữ liệu (ví dụ, hơn 50K OPS) Tham gia nhiều bài viết hơn là đọc Được ràng buộc bởi các SLA độ trễ nghiêm ngặt (ví dụ, độ trễ P99 đơn số tỷ giây) Trong tự nhiên, chúng xảy ra trên mọi thứ từ trò chơi trực tuyến đến các sàn giao dịch chứng khoán thời gian thực. Internet of Things (IoT) khối lượng công việc có xu hướng liên quan đến nhỏ nhưng thường xuyên chỉ viết phụ lục của dữ liệu chuỗi thời gian. Ở đây, tỷ lệ tiêu thụ chủ yếu được xác định bởi số lượng điểm cuối thu thập dữ liệu. Các hệ thống lưu trữ và giám sát cũng đối phó với việc xâm nhập dữ liệu thường xuyên, nhưng chúng không có tỷ lệ xâm nhập cố định. chúng có thể không nhất thiết phải chỉ đính kèm, cũng như có thể dễ bị điểm nóng, chẳng hạn như khi một điểm cuối hành vi sai. Nền tảng chơi game trực tuyến cần phải xử lý tương tác người dùng theo thời gian thực, bao gồm thay đổi trạng thái trò chơi, hành động của người chơi và nhắn tin. tải công việc có xu hướng cao, với sự gia tăng đột ngột trong hoạt động. Các khối lượng công việc thương mại điện tử và bán lẻ thường được cập nhật nặng và thường liên quan đến xử lý hàng loạt. các hệ thống này phải duy trì mức hàng tồn kho chính xác, xử lý đánh giá của khách hàng, theo dõi trạng thái đơn đặt hàng và quản lý hoạt động giỏ hàng, thường yêu cầu đọc dữ liệu hiện có trước khi thực hiện cập nhật. Công nghệ quảng cáo và hệ thống đấu thầu thời gian thực đòi hỏi các quyết định phân chia giây. Các hệ thống này xử lý xử lý đấu thầu phức tạp, bao gồm theo dõi ấn tượng và kết quả đấu giá, đồng thời theo dõi tương tác người dùng như nhấp chuột và chuyển đổi. Hệ thống chứng khoán thời gian thực phải hỗ trợ các hoạt động giao dịch tần số cao, cập nhật giá cổ phiếu liên tục và các quy trình phù hợp đơn hàng phức tạp - tất cả trong khi duy trì sự nhất quán tuyệt đối của dữ liệu và độ trễ tối thiểu. Tiếp theo, chúng ta hãy xem xét các cân nhắc kiến trúc và cấu hình chính ảnh hưởng đến hiệu suất viết. Kiến trúc Storage Engine Sự lựa chọn của kiến trúc công cụ lưu trữ cơ bản ảnh hưởng đến hiệu suất viết trong cơ sở dữ liệu. Có hai cách tiếp cận chính: cây LSM và cây B. Cơ sở dữ liệu được biết đến để xử lý chữ viết hiệu quả – chẳng hạn như ScyllaDB, Apache Cassandra, HBase, và Google BigTable – sử dụng Log-Structured Merge Trees (LSM). Kiến trúc này là lý tưởng để xử lý khối lượng lớn chữ viết. Vì chữ viết được đính kèm ngay lập tức vào bộ nhớ, điều này cho phép lưu trữ ban đầu rất nhanh chóng. Một khi “memtable” trong bộ nhớ được lấp đầy, chữ viết gần đây được rửa ra đĩa theo thứ tự sắp xếp. Ví dụ, đây là cách đường dẫn viết ScyllaDB trông như thế nào: Với cấu trúc cây B, mỗi hoạt động viết đòi hỏi phải tìm và sửa đổi một nút trong cây – và điều đó liên quan đến cả I/O hàng loạt và ngẫu nhiên Khi tập dữ liệu phát triển, cây có thể yêu cầu các nút bổ sung và tái cân bằng, dẫn đến nhiều I/O đĩa, có thể ảnh hưởng đến hiệu suất. Payload kích thước Kích thước tải trọng cũng ảnh hưởng đến hiệu suất. Với tải trọng nhỏ, thông lượng là tốt nhưng xử lý CPU là chướng ngại vật chính. Khi kích thước tải trọng tăng lên, bạn có được thông lượng tổng thể thấp hơn và việc sử dụng đĩa cũng tăng lên. Cuối cùng, một bản ghi nhỏ thường phù hợp với tất cả các bộ đệm và mọi thứ có thể được xử lý khá nhanh chóng. Đó là lý do tại sao nó dễ dàng để có được lượng thông lượng cao. Đối với tải trọng lớn hơn, bạn cần phân bổ các bộ đệm lớn hơn hoặc nhiều bộ đệm. tải trọng lớn hơn, tài nguyên nhiều hơn (mạng và đĩa) được yêu cầu để phục vụ các tải trọng đó. Compression Sử dụng đĩa là một cái gì đó để theo dõi chặt chẽ với một khối lượng công việc viết nặng.Mặc dù lưu trữ liên tục trở nên rẻ hơn, nó vẫn không phải là miễn phí. Nén có thể giúp giữ mọi thứ trong kiểm soát – vì vậy chọn chiến lược nén của bạn một cách khôn ngoan. tốc độ nén nhanh hơn là quan trọng đối với khối lượng công việc nặng, nhưng cũng xem xét nguồn lực CPU và bộ nhớ sẵn có của bạn. Hãy chắc chắn để xem các Compression về cơ bản chia dữ liệu của bạn thành các khối nhỏ hơn (hoặc khối) và sau đó nén từng khối riêng lẻ.Khi điều chỉnh thiết lập này, hãy nhận ra rằng các khối lớn hơn tốt hơn cho đọc trong khi các khối nhỏ hơn tốt hơn cho viết, và xem xét kích thước tải trọng có lợi của bạn. Compression Chunk kích thước Parameter Đồng cảm Đối với cơ sở dữ liệu dựa trên LSM, chiến lược nén bạn chọn cũng ảnh hưởng đến hiệu suất viết. nén liên quan đến việc sáp nhập nhiều SSTables vào ít hơn, tập tin có tổ chức hơn, để tối ưu hóa hiệu suất đọc, lấy lại không gian đĩa, giảm phân mảnh dữ liệu và duy trì hiệu quả tổng thể của hệ thống. Khi chọn chiến lược nén, bạn có thể nhắm mục tiêu tăng cường đọc thấp, làm cho đọc hiệu quả nhất có thể. Hoặc, bạn có thể nhắm mục tiêu tăng cường viết thấp bằng cách tránh nén quá hung hăng. Hoặc, bạn có thể ưu tiên tăng cường không gian thấp và có dữ liệu làm sạch nén hiệu quả nhất có thể. Ví dụ, ScyllaDB cung cấp (và Cassandra cung cấp những cái tương tự): Một số chiến lược phối hợp Chiến lược nén kích thước (STCS): Được kích hoạt khi hệ thống có đủ (bốn theo mặc định) SSTables kích thước tương tự. Chiến lược nồng độ nén (LCS): Hệ thống sử dụng nhỏ, kích thước cố định (theo mặc định 160 MB) SSTables phân phối trên các cấp độ khác nhau. Chiến lược nén gia tăng (ICS): Chia sẻ cùng một yếu tố tăng cường đọc và viết như STCS, nhưng nó sửa chữa vấn đề tăng cường không gian tạm thời 2x của nó bằng cách phá vỡ sstables khổng lồ thành chạy SSTable, bao gồm một tập hợp được sắp xếp của nhỏ hơn (1 GB theo mặc định), không trùng lặp SSTables. Chiến lược nén cửa sổ thời gian (TWCS): Được thiết kế cho dữ liệu chuỗi thời gian. Đối với tải trọng làm việc nặng về việc viết, chúng tôi cảnh báo người dùng tránh nới lỏng bằng mọi giá. Chiến lược này được thiết kế cho các trường hợp sử dụng nặng về việc đọc. Sử dụng nó có thể dẫn đến tăng cường viết 40x đáng tiếc. Batching Trong các cơ sở dữ liệu như ScyllaDB và Cassandra, batching thực sự có thể là một cái bẫy - đặc biệt là đối với khối lượng công việc khó viết. Nếu bạn quen với cơ sở dữ liệu quan hệ, batching có vẻ như là một lựa chọn tốt để xử lý một khối lượng lớn các bản ghi. Nhưng nó thực sự có thể làm chậm mọi thứ nếu nó không được thực hiện cẩn thận. Chủ yếu, đó là bởi vì các lô lớn hoặc không có cấu trúc cuối cùng tạo ra rất nhiều sự phối hợp và mạng lưới giữa các nút. Tuy nhiên, đó không phải là những gì bạn muốn trong một cơ sở dữ liệu phân tán như ScyllaDB. Dưới đây là cách suy nghĩ về việc đóng gói khi bạn đang đối phó với các bài viết nặng: Batch by the Partition Key: Nhóm các bài viết của bạn bằng phím phân vùng để lô đi đến một nút điều phối cũng sở hữu dữ liệu.Bằng cách đó, điều phối viên không phải tiếp cận các nút khác để có thêm dữ liệu.Thay vào đó, nó chỉ xử lý riêng của nó, làm giảm lưu lượng truy cập mạng không cần thiết. Giữ các lô nhỏ và được nhắm mục tiêu: Phân chia các lô lớn thành các lô nhỏ hơn theo phân vùng giữ cho mọi thứ hiệu quả. Nó tránh quá tải mạng và cho phép mỗi nút chỉ làm việc trên dữ liệu mà nó sở hữu. Tiếp tục với các lô không đăng nhập: Xem xét bạn làm theo các điểm trước, tốt nhất là sử dụng các lô không đăng nhập. các lô đăng nhập thêm kiểm tra tính nhất quán, có thể thực sự làm chậm việc viết. Vì vậy, nếu bạn đang ở trong một tình huống khó viết, hãy cấu trúc các lô của bạn cẩn thận để tránh sự chậm trễ mà các lô chéo lớn có thể giới thiệu. Wrapping lên Chúng tôi đã cung cấp khá nhiều cảnh báo, nhưng đừng lo lắng.Thật dễ dàng để biên soạn một danh sách các bài học đã học được bởi vì rất nhiều nhóm đang làm việc cực kỳ thành công với tải trọng công việc nặng trong thời gian thực. Nếu bạn muốn tìm hiểu thêm, đây là một số quan điểm đầu tiên từ các đội đã giải quyết những thách thức khá thú vị: Zillow: Tiêu thụ các bản ghi từ nhiều nhà sản xuất dữ liệu, dẫn đến các bản ghi không đúng thứ tự có thể dẫn đến các bản cập nhật không chính xác Tractian: Chuẩn bị cho sự tăng trưởng 10X trong dữ liệu tần số cao viết từ các thiết bị IoT Fanatics: Các hoạt động viết nặng như xử lý đơn đặt hàng, giỏ hàng và cập nhật sản phẩm cho nhà bán lẻ thể thao trực tuyến này Zillow Tracy Fanatics Ngoài ra, hãy xem video sau đây, nơi chúng tôi đi sâu hơn vào những thách thức khó viết này và cũng đi qua những tải công việc này trông như thế nào trên ScyllaDB.
