36
4
Được dịch từ wiki chính thức: https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide Vui lòng ghi rõ nguồn in lại: https://www.cnblogs.com/morningli/p/16788424.html. .
rockdb có cấu hình cao và linh hoạt. Mặt khác,rockdb đã cải thiện khả năng thích ứng trong những năm qua. Nếu ứng dụng của bạn chạy bình thường trên SSD, chúng tôi khuyên bạn không nên điều chỉnhrockdb. Chúng tôi khuyên người dùng nên thiết lập các tùy chọn và điều chỉnh cơ bản nhưng không cần phải gỡ lỗi trừ khi bạn thấy có vấn đề rõ ràng. Một mặt, các cấu hình điển hình được đề xuất trên trang này và thậm chí cả các cấu hình sẵn có thường hợp lý cho các tải thông thường. Mặt khác, việc điều chỉnhrocksdb thường dễ bị hồi quy hiệu suất lớn hơn khi tải hoặc phần cứng thay đổi. Người dùng thường cần liên tục gỡ lỗirocksdb để duy trì cùng mức hiệu suất.
Khi bạn cần điều chỉnh rockdb, trước khi điều chỉnh, chúng tôi khuyên bạn trước tiên nên hiểu thiết kế cơ bản của rockdb (có nhiều bài nói và một số ấn phẩm), đặc biệt là cách triển khai và nén cây LSM củarockdb.
Để hiểu những điểm nghẽn củarockdb, có một số công cụ có thể giúp bạn:
số liệu thống kê -- được đặt thànhrockdb::CreateDBStatistics(), bạn có thể nhận được số liệu thống kê vềrockdb có thể đọc được bằng cách gọi options.statistics.ToString() bất kỳ lúc nào. Xem số liệu thống kê để biết chi tiết.
Thống kê nén và DB rockdb luôn lưu một số thống kê nén và trạng thái vận hành db cơ bản. Đây là cách đơn giản nhất để hiểu hình dạng của cây LSM, có thể được sử dụng để đánh giá hiệu suất đọc và ghi. Xem số liệu thống kê về nén và DB để biết chi tiết.
Bối cảnh hoàn hảo và bối cảnh thống kê IO Bối cảnh hoàn hảo và bối cảnh thống kê IO có thể giúp hiểu số lượng tương đối của một câu lệnh cụ thể.
Đôi khi, hiệu suất bị hạn chế do số liệu hệ thống bão hòa và đôi khi xuất hiện các triệu chứng không mong muốn. Người dùng tinh chỉnh RocksDB sẽ có thể truy vấn các số liệu hệ thống từ hệ điều hành và xác định xem mức độ sử dụng một số liệu hệ thống cụ thể có cao hay không.
Băng thông ghi đĩa Thông thường, quá trình nén rockdb sẽ cố gắng ghi nhiều dữ liệu hơn mức mà ổ SSD có thể xử lý. Triệu chứng có thể là việc ghi của rockdb bị đình trệ (xem Số liệu thống kê về độ nén hoặc STALL_MICROS của số liệu thống kê). Hoặc nó có thể khiến yêu cầu đọc bị chậm do nén tồn đọng và cấu trúc dữ liệu LSM bị lệch. Bối cảnh Perf cho yêu cầu đọc đôi khi có thể hiển thị rằng có quá nhiều tệp SST được mở cho một yêu cầu đọc. Nếu điều này xảy ra, việc nén phải được gỡ lỗi.
IOP đọc đĩa Lưu ý rằng IOPS đọc liên tục cần thiết để đảm bảo hiệu suất đọc hợp lý thường thấp hơn nhiều so với thông số kỹ thuật phần cứng. Chúng tôi khuyến khích người dùng đo IOPS đã đọc mà họ muốn sử dụng thông qua các công cụ hệ thống (chẳng hạn như fio) và kiểm tra số liệu hệ thống theo phép đo này. Nếu IOPS đã bão hòa, bạn nên bắt đầu kiểm tra độ nén. Nó cũng có thể cải thiện tốc độ truy cập bộ đệm khối. Đôi khi vấn đề nằm ở việc đọc chỉ mục, bộ lọc hoặc khối dữ liệu lớn và có nhiều cách khác nhau để xử lý chúng.
CPU CPU thường do đường dẫn đọc gây ra, nhưng cũng có thể do quá trình nén. Nhiều tùy chọn có thể bị ảnh hưởng, chẳng hạn như nén, nén, lọc nở, kích thước khối, v.v.
Dung lượng ổ đĩa về mặt kỹ thuật không phải là một nút cổ chai. Nhưng khi các chỉ báo hệ thống chưa bão hòa, hiệu suất đủ tốt và chúng ta gần như lấp đầy dung lượng SSD thì chúng ta nói đó là tắc nghẽn không gian. Nếu người dùng muốn cung cấp nhiều dữ liệu hơn thông qua máy này, thì việc nén và nén là những lĩnh vực chính cần được điều chỉnh. Space tune sẽ hướng dẫn bạn cách giảm mức sử dụng dung lượng ổ đĩa.
Các thuật ngữ chúng tôi sử dụng để gỡ lỗi quá trình nén RocksDB là các hệ số khuếch đại: khuếch đại ghi, khuếch đại đọc và khuếch đại không gian. Các hệ số khuếch đại này liên quan đến kích thước của các yêu cầu logic của người dùng với các yêu cầu của RocksDB với phần cứng cơ bản. Đôi khi chúng ta cần gỡ lỗirocksdb, rõ ràng những yếu tố nào cần được điều chỉnh, nhưng đôi khi lại không rõ ràng. Bất kể tình huống thế nào, việc nén chặt là chìa khóa để thay đổi sự cân bằng giữa ba điều này.
Khuếch đại ghi là tỷ lệ giữa số byte được ghi vào bộ lưu trữ với số byte được ghi vào cơ sở dữ liệu.
Ví dụ: nếu bạn đang ghi 10MB/s dữ liệu vào cơ sở dữ liệu nhưng bạn quan sát thấy tốc độ đọc và ghi của đĩa là 30MB/s thì khả năng khuếch đại ghi của bạn là 3. Nếu khả năng khuếch đại ghi cao, khối lượng công việc này có thể bị giới hạn bởi thông lượng ổ đĩa. Ví dụ: nếu hệ số khuếch đại ghi là 50 và thông lượng ghi tối đa là 500MB/s thì cơ sở dữ liệu của bạn có thể hỗ trợ tốc độ ghi là 10MB/s. Trong trường hợp này, việc giảm khuếch đại ghi sẽ trực tiếp tăng tốc độ ghi.
Khả năng khuếch đại ghi cao cũng sẽ làm giảm tuổi thọ của đèn flash. Có hai cách để quan sát khả năng khuếch đại ghi của bạn. Cách đầu tiên là đọc qua kết quả đầu ra của DB::GetProperty("rocksdb.stats", &stats). Thứ hai là lấy băng thông ghi đĩa của bạn và chia cho tốc độ ghi cơ sở dữ liệu.
Khuếch đại đọc là số lần đọc đĩa trên mỗi yêu cầu. Nếu bạn cần đọc 5 trang để phản hồi yêu cầu thì mức khuếch đại đọc là 5. Đọc logic đề cập đến việc lấy dữ liệu từ bộ đệm, bao gồm bộ đệm khốirockdb và bộ đệm của hệ điều hành. Việc đọc vật lý được xử lý bởi các thiết bị lưu trữ như flash hoặc đĩa. Đọc logic rẻ hơn nhiều so với đọc vật lý, nhưng nó vẫn ảnh hưởng đến mức tiêu thụ CPU. Bạn có thể đánh giá tốc độ đọc vật lý từ đầu ra iostat, nhưng điều này sẽ bao gồm các yêu cầu đọc và yêu cầu nén.
Khuếch đại không gian là tỷ lệ kích thước của tệp cơ sở dữ liệu trên đĩa với kích thước của dữ liệu. Nếu bạn đặt 10 MB dữ liệu vào cơ sở dữ liệu và nó chiếm 100 MB trên đĩa thì mức khuếch đại không gian là 10. Bạn thường muốn đặt giới hạn cứng cho việc khuếch đại không gian để không hết dung lượng ổ đĩa hoặc bộ nhớ. Space tune sẽ hướng dẫn bạn cách giảm mức sử dụng dung lượng ổ đĩa.
Để tìm hiểu thêm về ba yếu tố khuếch đại này trong bối cảnh các thuật toán cơ sở dữ liệu khác nhau, bạn nên tham khảo bài nói chuyện của Mark Callaghan tại Highload.
Thông thường các chỉ số hệ thống chưa bão hòa nhưngrockdb vẫn không thể đạt được tốc độ như mong đợi. Có thể có những lý do khác nhau. Có một số tình huống phổ biến:
Quá trình nén không đủ nhanh Đôi khi SSD còn lâu mới bão hòa nhưng quá trình nén vẫn không thể bắt kịp. Có thể khả năng nén của rockdb bị hạn chế bởi cấu hình nén song song và không tối đa hóa việc sử dụng tài nguyên. Cấu hình mặc định thường ở mức thấp và có rất nhiều chỗ cần cải thiện. Xem các tùy chọn song song.
Tốc độ ghi không đủ nhanh. Mặc dù thao tác ghi thường bị tắc nghẽn do ghi I/O, nhưng có những trường hợp I/O không đủ nhanh và rockdb không thể ghi vào WAL và memtable đủ nhanh. Người dùng có thể thử ghi không theo thứ tự, xóa WAL thủ công và/hoặc phân chia cùng một dữ liệu thành nhiều DB và ghi song song vào chúng.
Vấn đề là gì khi muốn độ trễ đọc thấp hơn? Không người dùng nào chỉ muốn độ trễ đọc thấp hơn. Bạn có thể kiểm tra trạng thái của từng câu lệnh thông qua Ngữ cảnh Perf và Ngữ cảnh thống kê IO để tìm ra các vấn đề về CPU hoặc IO gây ra độ trễ cao và cố gắng điều chỉnh các tùy chọn phản hồi.
Xả và nén là những điều chỉnh quan trọng đối với nhiều nút thắt cổ chai và rất phức tạp. Bạn có thể tìm hiểu cách hoạt động của quá trình nén củarocksdb từ quá trình nén.
Khi đĩa chưa đầy sau khi nén, bạn có thể thử tăng độ song song của nén.
Trong kiến trúc LSM, có hai chương trình nền: tuôn ra và nén. Cả hai có thể được thực thi đồng thời thông qua các luồng để tận dụng tính đồng thời của công nghệ lưu trữ. Luồng xả nằm trong nhóm có mức độ ưu tiên cao và luồng nén nằm trong nhóm có mức độ ưu tiên thấp. Có thể thực hiện tăng số lượng luồng trong mỗi nhóm bằng cách gọi:
Trung tâm cá nhân
Điều phát hành
từ bỏ
tùy chọn.env->SetBackgroundThreads(num_threads, Env::Priority::HIGH); tùy chọn.env->SetBackgroundThreads(num_threads, Env::Priority::LOW);
Để hưởng lợi từ nhiều luồng hơn, bạn cần đặt các tùy chọn này để sửa đổi số lần nén và xả đồng thời tối đa.
max_background_compactions là mức độ đồng thời tối đa của việc nén nền. Giá trị mặc định là 1, nhưng để tận dụng tối đa CPU và bộ lưu trữ của bạn, bạn có thể muốn tăng giá trị này lên mức tối thiểu bằng số lượng CPU và thông lượng ổ đĩa của hệ thống chia cho thông lượng trung bình của một luồng nén.
**max_background_flushes ** là mức xử lý đồng thời tối đa, thường đặt nó thành 1 là đủ.
compaction_pri=kMinOverlappingRatio là giá trị mặc định củarocksdb, giá trị này đã tối ưu trong hầu hết các trường hợp. Chúng tôi sử dụng nó trong cả UDB và msgdb. So với giá trị mặc định trước đó, khả năng khuếch đại ghi đã giảm hơn một nửa (https://fb.workplace.com/groups/MyRocks.Internal/permalink/1364925913556020/).
Khi xóa nhiều dòng, một số file sst sẽ chứa đầy bia mộ, ảnh hưởng đến hiệu suất quét phạm vi. Chúng tôi đã mở rộng tính năng nén rockdb để theo dõi các bia mộ dài và gần. Nếu tìm thấy một phạm vi khóa Tombstone mật độ cao, nó sẽ ngay lập tức kích hoạt một quá trình nén khác để nén chúng. Điều này giúp giảm độ lệch hiệu suất quét phạm vi do quét quá nhiều bia mộ. Trong rockdb, lớp tương ứng là CompactOnDeletionCollectorFactory.
Mặc dù các kiểu nén đôi khi thường ưu tiên xóa các file chứa nhiều file bị xóa hơn nhưng điều này không được đảm bảo. Có một số lựa chọn khác có thể hữu ích. options.ttl chỉ định giới hạn thời gian mà sau đó dữ liệu hết hạn sẽ bị xóa khỏi tệp sst. options. Periodic_compaction_seconds đảm bảo rằng thỉnh thoảng một tệp sẽ vượt qua bộ lọc nén, do đó bộ lọc nén sẽ xóa dữ liệu tương ứng.
Tất cả các yêu cầu ghi vàorocksdb sẽ bị hạn chế và chèn vào cấu trúc dữ liệu bộ nhớ được gọi là memtable. Sau khi bảng ghi nhớ đang hoạt động được lấp đầy, chúng tôi tạo một bảng mới và đánh dấu bảng này là chỉ đọc. Chúng tôi gọi các bản ghi nhớ chỉ đọc là bất biến. Chỉ có một memtable hoạt động và không có hoặc nhiều memtable bất biến bất cứ lúc nào. Memtable bất biến đang chờ được chuyển vào bộ lưu trữ. Có ba tùy chọn để kiểm soát hành vi xả.
write_buffer_size đặt kích thước của memtable. Khi memtyable vượt quá kích thước này. Nó sẽ được đánh dấu là bất biến và một cái mới được tạo.
max_write_buffer_number đặt số lượng bảng ghi nhớ tối đa, bao gồm cả những bảng đang hoạt động và không thể thay đổi. Nếu memtable đang hoạt động đầy và tổng số memtable lớn hơn max_write_buffer_number chúng ta sẽ dừng (stall) tiếp tục viết. Điều này xảy ra nếu thành ngữ tuôn ra chậm hơn tốc độ viết.
min_write_buffer_number_to_merge là số lượng memtble tối thiểu cần hợp nhất trước khi chuyển vào bộ lưu trữ. Ngoài ra, nếu tùy chọn này được đặt thành 2, thì khả năng ghi nhớ bất biến sẽ chỉ bị xóa nếu có hai - một khả năng ghi nhớ bất biến sẽ không bao giờ bị xóa. Nếu nhiều memtable được hợp nhất với nhau, có thể sẽ có ít dữ liệu được ghi vào bộ lưu trữ hơn vì hai bản cập nhật được hợp nhất thành một khóa duy nhất. Tuy nhiên, mỗi lần Get() phải duyệt tuyến tính tất cả các bảng ghi nhớ bất biến để kiểm tra xem khóa có tồn tại hay không. Đặt tùy chọn này quá cao có thể dễ dàng ảnh hưởng đến hiệu suất đọc.
Ví dụ: Các tùy chọn là:
write_buffer_size = 512MB; max_write_buffer_number = 5; min_write_buffer_number_to_merge = 2;
Tốc độ ghi là 16MB/s. Trong trường hợp sử dụng này, một bảng ghi nhớ mới sẽ được tạo sau mỗi 32 giây, hai bảng ghi nhớ này sẽ được hợp nhất với nhau và xóa sau mỗi 64 giây. Tùy thuộc vào kích thước bộ làm việc, kích thước xóa sẽ nằm trong khoảng từ 512MB đến 1GB. Để ngăn việc xả theo kịp tốc độ ghi, giới hạn trên của bộ nhớ mà memtable sử dụng là 5*512MB = 2,5GB. Khi đạt đến giới hạn bộ nhớ, các thao tác ghi tiếp theo sẽ bị chặn cho đến khi quá trình xóa kết thúc và bộ nhớ mà memtable sử dụng được giải phóng.
Xem phần tính toán theo cấp độ để biết chi tiết.
Trong nén kiểu cấp độ, các tệp cơ sở dữ liệu được tổ chức thành các cấp độ khác nhau. Bảng ghi nhớ được chuyển vào tệp ở mức 0, chứa dữ liệu mới nhất. Các lớp cao hơn chứa dữ liệu cũ hơn. Các tệp ở cấp 0 có thể chồng lên nhau, nhưng các tệp ở cấp 1 trở lên sẽ không chồng lên nhau. Kết quả là Get() thường kiểm tra mọi tệp ở cấp 0, nhưng ở mỗi cấp kế tiếp, không có nhiều hơn một tệp chứa khóa cùng một lúc. Mỗi lớp lớn hơn 10 lần so với lớp trước (bội số có thể cấu hình được).
Quá trình nén có thể lấy một số tệp N-layer và nén chúng cùng với các tệp chồng chéo trong N+1 lớp. Hai thao tác nén ở các cấp độ khác nhau hoặc các phạm vi khóa khác nhau độc lập và có thể được thực hiện đồng thời. Tốc độ nén tỷ lệ thuận với tốc độ ghi tối đa. Nếu việc nén không thể cải thiện tốc độ ghi, dung lượng ổ đĩa được cơ sở dữ liệu sử dụng sẽ tiếp tục tăng. Điều quan trọng là phải định cấu hìnhrockdb để thực hiện nén với tính đồng thời cao và tận dụng tối đa dung lượng lưu trữ.
Việc nén giữa lớp 0 và lớp 1 là một vấn đề khó khăn. Các tệp ở mức 0 thường trải rộng trên toàn bộ không gian khóa. Khi nén L0->L1 (lớp 0 đến lớp 1), việc nén bao gồm tất cả các tệp ở lớp đầu tiên. Khi tất cả các tệp trong lớp 1 đang được nén bằng lớp 0, việc nén L1->L2 không thể thực hiện được; bạn phải đợi L0->L1 kết thúc. Nếu quá trình nén L0->L1 chậm, hầu hết thời gian sẽ chỉ có một lần nén đang chạy vì các lần nén khác phải đợi cho đến khi quá trình nén kết thúc.
Nén L0->L1 là nén đơn luồng. Rất khó để đạt được thông lượng tốt bằng cách nén đơn luồng. Để kiểm tra xem điều này có gây ra sự cố hay không, hãy kiểm tra việc sử dụng đĩa. Nếu đĩa không được sử dụng hết, có thể có vấn đề trong cấu hình nén. Chúng tôi thường khuyên bạn nên tạo L0->L1 càng nhanh càng tốt bằng cách giữ kích thước của lớp 0 gần với kích thước của lớp 1.
Khi bạn quyết định kích thước thích hợp của một lớp, bạn phải quyết định hệ số nhân cấp độ. Giả sử kích thước cấp 1 của bạn là 512MB, hệ số nhân cấp là 10 và kích thước cơ sở dữ liệu là 500GB. Kích thước sẽ là 5GB cho Cấp 2, 51GB cho Cấp 3 và 512GB cho Cấp 4. Vì kích thước cơ sở dữ liệu của bạn là 500GB nên các cấp trên 5 sẽ trống.
Việc mở rộng kích thước rất dễ tính toán. (512 MB + 512 MB + 5GB + 51GB + 512GB) / (500GB) = 1,14. Khuếch đại ghi có thể được tính như sau: mỗi byte được ghi ở mức 0 trước tiên. Sau đó nén xuống lớp 1. Vì kích thước của lớp 1 giống với kích thước của lớp 0 nên mức khuếch đại ghi của L0->L1 là 2. Tuy nhiên, khi nén bản thân từ lớp 1 xuống lớp 2 thì sẽ lớn hơn lớp 2 10 byte (vì lớp 2 lớn hơn lớp 1 10 lần). L2-L3 và L3->L4 giống nhau.
Vì vậy, tổng mức khuếch đại ghi gần bằng 1 + 2 + 10 + 10 + 10 = 33. Truy vấn điểm phải truy vấn tất cả các tệp ở cấp độ 0 và nhiều nhất là một tệp ở cấp độ khác. Tuy nhiên, bộ lọc Bloom làm giảm đáng kể khả năng khuếch đại đọc. Tuy nhiên, truy vấn phạm vi tạm thời đắt hơn. Không thể sử dụng bộ lọc Bloom để quét phạm vi, do đó mức khuếch đại đọc là number_of_level0_files + number_of_non_empty_levels.
Hãy bắt đầu bằng cách tìm hiểu các tùy chọn để nén mức. Trước tiên, chúng tôi sẽ đề cập đến các tùy chọn quan trọng nhất, sau đó là những tùy chọn ít quan trọng hơn.
level0_file_num_compaction_trigger -- Khi tệp ở cấp 0 đạt đến con số này, quá trình nén L0->L1 sẽ được kích hoạt ngay lập tức. Do đó, chúng ta có thể ước tính kích thước của mức 0 ở trạng thái ổn định là write_buffer_size * min_write_buffer_number_to_merge * level0_file_num_compaction_trigger.
max_bytes_for_level_base và max_bytes_for_level_multiplier - max_bytes_for_level_base là tổng kích thước của lớp 1. Chúng tôi khuyên bạn nên đặt kích thước ở mức 0. Mỗi lớp kế tiếp có kích thước max_bytes_for_level_multiplier gấp lần kích thước của lớp trước đó. Mặc định là 10, chúng tôi khuyên bạn không nên thay đổi nó.
target_file_size_base và target_file_size_multiplier -- Tệp cấp 1 có byte target_file_size_base. Kích thước tệp của mỗi lớp lớn hơn target_file_size_multiplier lần so với lớp trước. Tuy nhiên, target_file_size_multiplier mặc định là 1, do đó kích thước tệp L1...Lmax là như nhau. Việc tăng target_file_size_base sẽ làm giảm số lượng tệp trong cơ sở dữ liệu, đây thường là một điều tốt. Chúng tôi khuyên bạn nên đặt target_file_size_base thành max_bytes_for_level_base/10, như vậy sẽ có 10 tệp ở cấp 1.
nén_per_level – Sử dụng tùy chọn này để đặt thuật toán nén cho mỗi lớp. Thông thường lớp giáp 0 và 1 sẽ không bị nén, chỉ nén dữ liệu ở lớp cao hơn. Bạn có thể đặt thuật toán nén chậm hơn ở lớp cao nhất và sử dụng thuật toán nén nhanh hơn ở lớp dưới (lớp cao nhất đại diện cho Lmax).
num_levels -- Sẽ an toàn khi có num_levels lớn hơn số cấp cơ sở dữ liệu dự kiến. Một số lớp cao hơn có thể trống nhưng điều này sẽ không ảnh hưởng đến hiệu suất. Chỉ khi âm của bạn có nhiều hơn 7 lớp, bạn mới cần sửa đổi tùy chọn này (mặc định là 7).
Xem nén phổ quát để biết chi tiết.
Khả năng khuếch đại ghi của mức nén kiểu cấp độ có thể rất cao trong một số trường hợp sử dụng. Trong khối lượng công việc có tỷ lệ yêu cầu ghi lớn, bạn có thể bị giới hạn bởi thông lượng ổ đĩa. Để tối ưu hóa khối lượng công việc như vậy,rockdb giới thiệu một tình huống nén mới gọi là nén phổ quát để giảm khả năng khuếch đại ghi. Tuy nhiên, nó có thể tăng khả năng khuếch đại đọc và luôn tăng khả năng khuếch đại không gian. Nén phổ quát có giới hạn kích thước. Hãy cẩn thận khi kích thước cơ sở dữ liệu (hoặc họ cột) của bạn lớn hơn 100GB. Bạn có thể tìm hiểu thêm thông qua việc nén phổ quát.
Sử dụng nén phổ quát, quá trình nén có thể tạm thời tăng gấp đôi kích thước. Nói cách khác, nếu bạn lưu 10GB vào cơ sở dữ liệu, quá trình nén có thể tiêu tốn thêm 10GB ngoài việc khuếch đại không gian.
Tuy nhiên, có những kỹ thuật giúp giảm khả năng phòng thủ không gian tạm thời. Nếu bạn sử dụng tính năng nén phổ quát, chúng tôi thực sự khuyên bạn nên phân chia dữ liệu của mình và lưu dữ liệu đó vào các phiên bảnrockdb khác nhau. Giả sử bạn có phân đoạn S. Định cấu hình nhóm luồng Env để chỉ có N luồng nén. Chỉ N phân đoạn S sẽ có khuếch đại không gian bổ sung, giúp giảm khuếch đại không gian bổ sung từ 1 xuống N/s. Ví dụ: nếu cơ sở dữ liệu của bạn là 10 GB và bạn định cấu hình cơ sở dữ liệu để có 100 phân đoạn thì mỗi phân đoạn chứa 100 MB dữ liệu. Nếu bạn định cấu hình nhóm luồng của mình cho 20 luồng nén đồng thời, bạn sẽ chỉ tiêu tốn thêm 2GB thay vì 10GB và quá trình nén sẽ được thực thi song song, tận dụng tối đa khả năng lưu trữ đồng thời của bạn.
max_size_amplification_percent -- Khuếch đại kích thước, được định nghĩa là không gian bổ sung (phần trăm) cần thiết để lưu trữ một byte trong cơ sở dữ liệu. Giá trị mặc định là 200, có nghĩa là cơ sở dữ liệu 100 byte sẽ yêu cầu dung lượng lưu trữ 300 byte. 200 byte trong số 300 byte là tạm thời và sẽ chỉ được sử dụng trong quá trình nén. Việc tăng giới hạn này sẽ làm giảm khả năng khuếch đại ghi, nhưng (rõ ràng) sẽ tăng khả năng khuếch đại không gian.
nén_size_percent – Phần trăm dữ liệu được cơ sở dữ liệu nén. Dữ liệu cũ hơn sẽ được nén, dữ liệu mới hơn sẽ không được nén. Nếu đặt thành -1 (mặc định), tất cả dữ liệu sẽ được nén. Việc giảm nén_size_percent giúp giảm mức sử dụng CPU và tăng khả năng khuếch đại không gian.
filter_policy -- Nếu bạn đang thực hiện truy vấn điểm trên cơ sở dữ liệu chưa được nén, chắc chắn bạn sẽ muốn bật bộ lọc nở. Chúng tôi sử dụng bộ lọc nở để tránh việc đọc đĩa không cần thiết. Bạn nên đặt filter_policy thànhrockdb::NewBloomFilterPolicy(bits_per_key). Bits_per_key mặc định là 10, tạo ra tỷ lệ dương tính giả khoảng 1%. Bit_per_key lớn hơn sẽ giảm tỷ lệ dương tính giả nhưng sẽ tăng mức sử dụng bộ nhớ và khuếch đại không gian.
block_cache -- Chúng tôi thường khuyên bạn nên đặt cấu hình này thành kết quả củarockdb::NewLRUCache(cache_capacity, shard_bits). khối bộ nhớ đệm khối được giải nén. Mặt khác, hệ điều hành lưu trữ khối nén (vì đây là cách nó được lưu trữ trong tệp). Vì vậy có lý do để sử dụng cả block_cache và cache của hệ điều hành. Chúng ta cần lock khi vào block cache nên đôi khi sẽ thấy nút thắt cổ chai củarockdb chính là mutex của block cache, đặc biệt khi kích thước cơ sở dữ liệu nhỏ hơn bộ nhớ. Trong trường hợp này, việc phân chia bộ đệm khối bằng cách đặt shard_bits thành số lớn hơn là hợp lý. Nếu shard_bits là 4 thì tổng số phân đoạn là 16.
allow_os_buffer -- [Không được dùng nữa] Nếu được đặt thành sai, chúng tôi sẽ không lưu các tệp trong bộ đệm của hệ thống vào bộ nhớ đệm.
**max_open_files ** --rocksdb lưu tất cả các bộ mô tả tệp trong bộ đệm của bảng. Nếu bộ mô tả tệp vượt quá max_open_files, một số tệp sẽ bị xóa khỏi bộ đệm của bảng và bộ mô tả tệp của chúng sẽ bị đóng. Điều này có nghĩa là mỗi yêu cầu đọc phải tìm bộ mô tả tệp được yêu cầu thông qua bộ đệm của bảng. Đặt max_open_files thành -1 sẽ luôn mở tất cả các tệp, tránh các lệnh gọi bộ đệm bảng tốn kém.
table_cache_numshardbits - Đây là một tùy chọn được sử dụng để kiểm soát việc phân bổ bộ đệm của bảng. Tùy chọn này có thể được thêm vào nếu mutex của bộ đệm bảng có tác động.
**block_size ** -- rockdb gói dữ liệu người dùng thành các khối. Khi đọc cặp khóa-giá trị từ tệp nhãn, toàn bộ khối sẽ được tải vào bộ nhớ. Kích thước khối mặc định là 4K. Mỗi tệp bảng chứa một chỉ mục của tất cả các khối. Tăng block_size có nghĩa là chỉ mục sẽ chứa ít mục hơn (vì có ít khối hơn trên mỗi tệp) và do đó sẽ nhỏ hơn. Việc tăng block_size làm giảm mức sử dụng bộ nhớ và khuếch đại không gian nhưng lại tăng khả năng khuếch đại đọc.
Một lần nữa, bạn có thể muốn chạy nhiều phiên bản củarocksdb trong cùng một quy trình. RocksDB cung cấp các phương thức để các phiên bản này chia sẻ bộ nhớ đệm khối và nhóm luồng. Để chia sẻ bộ đệm khối, hãy gán một đối tượng bộ đệm cho tất cả các phiên bản:
first_instance_options.block_cache = second_instance_options.block_cache = rocksdb::NewLRUCache(1GB)
Bằng cách này, cả hai phiên bản đều chia sẻ bộ đệm khối với tổng kích thước là 1GB.
Nhóm luồng được liên kết với phiên bản Env. Khi bạn xây dựng Tùy chọn, options.env sẽ được đặt thành Env::Default() theo mặc định, điều này tốt nhất trong hầu hết các trường hợp. Vì tất cả các tùy chọn đều sử dụng cùng một đối tượng tĩnh Env::Default() nên nhóm luồng được chia sẻ theo mặc định. Bằng cách này, bạn có thể đặt giới hạn trên cho số lượng thao tác nén và xóa, ngay cả khi chạy nhiều phiên bảnrockdb.
Xem Viết quầy hàng để biết chi tiết.
rockdb lưu trữ tất cả dữ liệu và hỗ trợ lặp lại theo thứ tự. Tuy nhiên, một số ứng dụng không yêu cầu các khóa phải được sắp xếp hoàn toàn. Họ chỉ muốn sắp xếp các khóa bằng tiền tố chung.
Các ứng dụng này sẽ được hưởng lợi từ việc thiết lập prefix_extractor của cơ sở dữ liệu.
prefix_extractor – Đối tượng SliceTransform xác định tiền tố khóa. Tiền tố chính có thể được sử dụng để đạt được một số tối ưu hóa thú vị:
Để biết thêm chi tiết về 1 và 2, hãy xem Nhà máy sản xuất bảng và bảng ghi nhớ tùy chỉnh. Lưu ý rằng 1 thường đủ để giảm IO. 2 và 3 có thể giảm mức tiêu thụ CPU trong một số trường hợp nhất định, nhưng thường tiêu tốn một lượng bộ nhớ nhất định. Bạn chỉ nên cố gắng điều chỉnh nó nếu CPU là nút cổ chai của bạn và bạn đã sử dụng tất cả các cách dễ dàng hơn để giảm mức tiêu thụ CPU, điều này không phổ biến. Đảm bảo kiểm tra nhận xét về prefix_extractor trong include/rocksdb/options.h.
Bộ lọc Bloom là cấu trúc dữ liệu xác suất được sử dụng để kiểm tra xem một phần tử có phải là một phần của tập hợp hay không. Bộ lọc Bloom trongrockdb được kiểm soát thông qua tùy chọn filter_policy. Khi người dùng nhỏ hơn Get(key), sẽ có một loạt tệp có thể chứa khóa này. Đây thường là tất cả các tệp ở lớp 0 và một tệp trên mỗi lớp ở các lớp khác. Tuy nhiên, trước khi đọc từng tệp, trước tiên chúng ta hãy tham khảo bộ lọc Bloom. Bộ lọc Bloom sẽ lọc hầu hết các lần đọc tệp không chứa khóa. Trong hầu hết các trường hợp, Get() chỉ cần đọc một tệp. Bộ lọc Bloom luôn được lưu trong bộ nhớ cho các tệp đang mở trừ khi BlockBasedTableOptions::cache_index_and_filter_blocks được đặt thành true. Số lượng tệp đang mở được kiểm soát bởi tùy chọn max_open_files.
Có hai loại bộ lọc Bloom: lọc theo khối và lọc đầy đủ.
Các bộ lọc dựa trên khối có thể được đặt bằng cách gọi options.filter_policy.reset(rocksdb::NewBloomFilterPolicy(10, true)). Bộ lọc nở hoa dựa trên khối được xây dựng riêng cho từng khối. Đối với yêu cầu đọc, trước tiên chúng tôi tham khảo chỉ mục và chỉ mục sẽ trả về khối mà chúng tôi đang tìm kiếm. Bây giờ chúng ta đã có khối, chúng ta hãy tham khảo bộ lọc Bloom của khối này.
Có thể đặt lọc đầy đủ bằng cách gọi options.filter_policy.reset(rocksdb::NewBloomFilterPolicy(10, false)). Lọc đầy đủ được xây dựng một cho mỗi tập tin. Chỉ có một bộ lọc nở cho mỗi tệp. Điều này có nghĩa là chúng ta có thể bỏ qua chỉ mục và tham khảo bộ lọc Bloom trước. So với các bộ lọc Bloom dựa trên khối, chúng tôi tiết kiệm thời gian truy vấn chỉ mục một lần khi khóa không có trong bộ lọc Bloom.
Lọc đầy đủ có thể được phân vùng thêm: Bộ lọc được phân vùng.
Người dùng nâng cao có thể định cấu hình các định dạng bảng và bảng ghi nhớ tùy chỉnh.
**memtable_factory ** -- Xác định memtable. Dưới đây là danh sách các memtables chúng tôi hỗ trợ:
**table_factory ** -- Xác định định dạng bảng. Dưới đây là danh sách các bảng chúng tôi hỗ trợ:
Để tìm hiểu thêm, hãy xem https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB.
Xem Tuning RocksDB trên đĩa quay 。
Trong chương này, chúng tôi sẽ trình bày một số cấu hình củarocksdb mà chúng tôi thực sự sử dụng trong môi trường sản xuất.
Dịch vụ này sử dụngrocksdb để triển khai các truy vấn phạm vi tiền tố và truy vấn điểm, đồng thời dịch vụ này chạy trên bộ lưu trữ flash.
tùy chọn.prefix_extractor.reset(CustomPrefixExtractor mới());
Vì dịch vụ này không yêu cầu lặp lại mức độ ưu tiên đầy đủ (xem Cơ sở dữ liệu tiền tố), nên chúng tôi xác định trình trích xuất tiền tố.
rocksdb::BlockBasedTableOptions bảng_tùy chọn; table_options.index_type = rocksdb::BlockBasedTableOptions::kHashSearch; table_options.block_size = 4 * 1024; options.table_factory.reset(NewBlockBasedTableFactory(table_options));
Chúng tôi sử dụng chỉ mục băm trong tệp bảng để tăng tốc độ tra cứu tiền tố, nhưng nó sẽ tăng dung lượng lưu trữ và mức sử dụng bộ nhớ.
options.compression = rocksdb::kLZ4Compression;
Nén LZ4 giúp giảm mức sử dụng CPU nhưng tăng dung lượng lưu trữ.
tùy chọn.max_open_files = -1;
Cài đặt này vô hiệu hóa việc tra cứu tệp trong bộ đệm của bảng, giúp tăng tốc tất cả các yêu cầu. Nếu máy chủ của bạn có giới hạn trên tương đối lớn về số lượng tệp đang mở thì cài đặt này là một điều tốt.
tùy chọn. tùy chọn. nén_style = kCompactionStyleLevel; tùy chọn. số_tệp_level0_kích_thước_tệp_số_kích_thước_tệp = 10; tùy chọn. tốc_độ_ghi_level0_kích_thước_ghi_level0 = 20; tùy chọn. dừng_ghi_level0_kích_thước_ghi_level0 = 40; tùy chọn. kích_thước_đệm_ghi = 64 * 1024 * 1024; tùy chọn. kích_thước_tệp_mục_đích_cơ_sở = 64 * 1024 * 1024; tùy chọn. byte_tối_đa_cho_cấp_cơ_sở ...cấp = 512 * 1024 * 1024;
Chúng tôi sử dụng nén mức. Kích thước có thể ghi nhớ là 64 MB và lớp 0 sẽ được xóa thường xuyên. nén L0->L1 được kích hoạt khi có 10 tệp cấp 0 (tổng cộng 640 MB). Khi L0 là 640 MB, quá trình nén sẽ được kích hoạt thành L1 với kích thước tối đa là 512 MB. Tổng kích thước cơ sở dữ liệu? ? ?
options.max_background_compactions = 1 options.max_background_flushes = 1
Chỉ có một lần nén đồng thời và một lần xả đang được thực thi bất kỳ lúc nào. Tuy nhiên, có nhiều phân đoạn trong hệ thống nên nhiều lần nén có thể xảy ra ở các phân bổ khác nhau. Nếu không, chỉ có hai luồng ghi vào bộ nhớ sẽ không cho phép sử dụng hết bộ nhớ.
tùy chọn.memtable_prefix_bloom_bits = 1024 * 1024 * 8;
Sử dụng bộ lọc nở có thể ghi nhớ có thể tránh được một số quyền truy cập vào có thể ghi nhớ.
tùy chọn.block_cache = rocksdb::NewLRUCache(512 * 1024 * 1024, 8);
Bộ đệm khối được cấu hình thành 512MB. (Nó có được chia sẻ bởi tất cả các phân bổ không?).
Cơ sở dữ liệu này thực hiện cả phép lặp Get() và phép lặp sắp xếp đầy đủ. Phân mảnh?
tùy chọn.env->SetBackgroundThreads(4);
Trước tiên, chúng tôi đặt số lượng luồng trong nhóm luồng là 4.
tùy chọn. tùy chọn. nén_style = kCompactionStyleLevel; tùy chọn. kích thước_đệm_ghi = 67108864; // 64MB tùy chọn. số_đệm_ghi_tối đa = 3; tùy chọn. kích thước_tệp_đích_đích_cơ_sở = 67108864; // 64MB tùy chọn. nén_tối đa_nền = 4; tùy chọn. số_tệp_số_đệm_tối đa = 8; tùy chọn. kích thước_chậm_ghi_tối_đa = 17; tùy chọn. kích thước_dữ_liệu_mức_tối_đa = 24; tùy chọn. số_mức_tối_đa = 4; tùy chọn. byte_tối_đa_cho_mức_cơ_sở ...
Chúng tôi sử dụng nén ở mức đồng thời cao. Kích thước có thể ghi nhớ là 64 MB và số lượng tệp lớp 0 là 8. Đây là thời điểm quá trình nén được kích hoạt khi kích thước của L0 tăng lên 512 MB. Kích thước của L1 là 512MB và mỗi lớp lớn hơn lớp trước 8 lần. L2 là 4GB và L3 là 32GB.
Trong ví dụ này, cơ sở dữ liệu được gắn trên hệ thống tệp tmpfs.
Sử dụng mmap để đọc:
options.allow_mmap_reads = đúng;
Tắt bộ đệm khối, bật bộ lọc nở và giảm khoảng thời gian khởi động lại mã hóa gia tăng:
Tùy chọn bảng BlockBasedTableOptions; tùy chọn bảng.filter_policy.reset(NewBloomFilterPolicy(10, đúng)); tùy chọn bảng.no_block_cache = đúng; tùy chọn bảng.block_restart_interval = 4; tùy chọn bảng.reset(NewBlockBasedTableFactory(tùy chọn bảng));
Nếu bạn muốn ưu tiên tốc độ, bạn có thể tắt tính năng nén:
options.compression = rocksdb::CompressionType::kNoCompression;
Ngoài ra, hãy bật tính năng nén nhẹ, LZ4 hoặc snappy.
Đặt nén mạnh mẽ hơn và phân bổ nhiều luồng hơn để xả và nén:
tùy chọn.level0_file_num_compaction_trigger = 1; tùy chọn.max_background_flushes = 8; tùy chọn.max_background_compactions = 8; tùy chọn.max_subcompactions = 4;
Giữ tất cả các tập tin mở:
tùy chọn.max_open_files = -1;
Khi đọc dữ liệu, hãy cân nhắc việc đặt ReadOptions.verify_checksums = false.
Trong sự phân tách này, cơ sở dữ liệu được gắn trên hệ thống tệp tmpfs. Chúng tôi sử dụng các định dạng tùy chỉnh để tăng tốc và một số tính năng không được hỗ trợ. Chúng tôi chỉ hỗ trợ quét phạm vi tiền tố và Get(). Nhật ký ghi trước (WAL) được lưu trữ trên đĩa cứng để tránh tiêu tốn bộ nhớ ở những nơi khác ngoài truy vấn. Pre() không được hỗ trợ.
Vì cơ sở dữ liệu nằm trong bộ nhớ nên chúng tôi không quan tâm đến việc khuếch đại ghi. Chúng tôi quan tâm nhiều hơn đến khả năng khuếch đại đọc và khuếch đại không gian. Đây là một sự khởi đầu thú vị vì chúng tôi đã nén chặt đến mức cực đoan và thường chỉ có một bảng sst trong hệ thống. Chúng tôi ẩn khả năng khuếch đại đọc và không gian giảm, khuếch đại ghi rất lớn.
Vì sử dụng phương pháp nén phổ quát nên chúng tôi sẽ tăng gấp đôi mức sử dụng không gian một cách hiệu quả trong quá trình nén. Điều này rất nguy hiểm trong cơ sở dữ liệu trong bộ nhớ. Chúng tôi ẩn việc phân chia dữ liệu thành 400 phiên bảnrockdb. Chúng tôi chỉ cho phép nén hai lần đồng thời, do đó chỉ có hai phân đoạn cùng một lúc có thể tăng gấp đôi không gian.
Trong ví dụ này, băm tiền tố có thể được sử dụng để chạy hệ thống bằng cách sử dụng chỉ mục băm thay vì chỉ mục nhị phân, đã sử dụng bộ lọc nở để lặp lại nếu có thể:
tùy chọn.prefix_extractor.reset(CustomPrefixExtractor mới());
Sử dụng định dạng bảng có thể định địa chỉ theo bộ nhớ được xây dựng để truy cập có độ trễ thấp, yêu cầu bật chế độ đọc mmap:
tùy chọn.table_factory = std::shared_ptr(rocksdb::NewPlainTableFactory(0, 8, 0.85)); tùy chọn.allow_mmap_reads = true; tùy chọn.allow_mmap_writes = false;
Sử dụng danh sách liên kết băm có thể ghi nhớ để thay đổi tìm kiếm trong bảng bộ nhớ từ tìm kiếm nhị phân sang tìm kiếm băm:
tùy chọn.memtable_factory.reset(rocksdb::NewHashLinkListRepFactory(200000));
Bật bộ lọc Bloom cho bảng băm để giảm quyền truy cập bộ nhớ khi khóa không tồn tại trong bảng trong bộ nhớ (thường có nghĩa là bộ đệm CPU bị thiếu):
tùy chọn.memtable_prefix_bloom_bits = 10000000; tùy chọn.memtable_prefix_bloom_probes = 6;
Đặt nén để bắt đầu nén hoàn toàn miễn là có hai tệp:
options.compaction_style = kUniversalCompaction; options.compaction_options_universal.size_ratio = 10; options.compaction_options_universal.min_merge_width = 2; options.compaction_options_universal.max_size_amplification_percent = 1; options.level0_file_num_compaction_trigger = 1; options.level0_slowdown_writes_trigger = 8; options.level0_stop_writes_trigger = 16;
Thiết lập bộ lọc nở để giảm thiểu quyền truy cập bộ nhớ:
tùy chọn.bloom_locality = 1;
Các đối tượng redser của tất cả các bảng luôn được lưu vào bộ đệm để tránh truy cập vào bộ đệm của bảng khi đọc:
tùy chọn.max_open_files = -1;
Sử dụng một bảng bộ nhớ tại một thời điểm. Kích thước của nó phụ thuộc vào khoảng thời gian mà chúng ta có thể chấp nhận nén toàn bộ. Chúng tôi điều chỉnh độ nén sao cho mỗi lần xả sẽ kích hoạt quá trình nén hoàn toàn, việc này sẽ tiêu tốn CPU. Kích thước memtable càng lớn thì khoảng thời gian nén càng dài. Đồng thời, chúng ta thấy hiệu suất bộ nhớ thấp hơn, hiệu suất truy vấn kém hơn và thời gian khôi phục khi khởi động lại DB dài hơn.
tùy chọn.write_buffer_size = 32 << 20; tùy chọn.max_write_buffer_number = 2; tùy chọn.min_write_buffer_number_to_merge = 1;
Nhiều phân đoạn cơ sở dữ liệu chia sẻ một nhóm luồng nén với giới hạn là 2:
tùy chọn.max_background_compactions = 1; tùy chọn.max_background_flushes = 1; tùy chọn.env->SetBackgroundThreads(1, rocksdb::Env::Priority::HIGH); tùy chọn.env->SetBackgroundThreads(2, rocksdb::Env::Priority::LOW);
Thiết lập nhật ký WAL:
tùy chọn.bytes_per_sync = 2 << 20;
hash_index: Trong phiên bản mới, chỉ mục băm được bật cho bảng cơ sở khối. So với chỉ mục tìm kiếm nhị phân, nó sẽ sử dụng thêm 5% dung lượng nhưng tăng tốc độ đọc ngẫu nhiên lên 50%.
table_options.index_type = rocksdb::BlockBasedTableOptions::kHashSearch;
block_size: Theo mặc định, giá trị này được đặt thành 4K. Nếu tính năng nén được bật, kích thước blcok nhỏ hơn sẽ dẫn đến tốc độ đọc ngẫu nhiên cao hơn do chi phí giải nén giảm. Tuy nhiên, kích thước khối không thể được đặt quá nhỏ, khiến quá trình nén không thành công. Nên đặt nó thành 1k.
verify_checksum: Chúng tôi lưu trữ dữ liệu vào tmpfs và để có hiệu suất đọc phù hợp hơn, bạn có thể tắt tổng kiểm tra.
Thật không may, việc điều chỉnhrockdb không phải là vấn đề đơn giản. Mặc dù chúng tôi, với tư cách là nhà phát triển củarocksdb, không biết đầy đủ về tác động của từng sửa đổi cấu hình, Nếu muốn tối ưu hóa hoàn toàn khối lượng công việc của mình, bạn nên thử nghiệm và đo điểm chuẩn đồng thời tập trung vào ba yếu tố khuếch đại. Trong thời gian chờ đợi, vui lòng liên hệ với chúng tôi trong Nhóm thảo luận của nhà phát triển RocksDB để được trợ giúp.
Cuối cùng, bài viết về hướng dẫn gỡ lỗirocksdb [Dịch] này kết thúc tại đây. Nếu bạn muốn biết thêm về hướng dẫn gỡ lỗi [Dịch]rockdb, vui lòng tìm kiếm bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ hỗ trợ tôi trong tương lai. blog! .
36
4
0
Tôi là một lập trình viên xuất sắc, rất giỏi!