gh-1413 bloom_fpr => vinyl_bloom_fpr, page_size => vinyl_page_size

Author: Onvember

doc/book/box/engines/vinyl.rst

@@ -567,7 +567,7 @@ simultaneously occurring in all of the bit arrays is infinitesimal.
 
 The key advantage of Bloom filters in Tarantool is that they’re easily
 configurable. The only parameter that can be specified separately for each index
-is called ``bloom_fpr`` (FPR stands for "false positive ratio") and it has the
+is called ``vinyl_bloom_fpr`` (FPR stands for "false positive ratio") and it has the
 default value of 0.05, which translates to a 5% FPR. Based on this parameter,
 Tarantool automatically creates Bloom filters of the optimal size for partial-
 key and full-key searches. The Bloom filters are stored in the `.index` file,

doc/reference/reference_lua/box_stat.rst

@@ -177,8 +177,8 @@ We can expect that "L0 = 0" immediately after a dump.
 ``box.stat.vinyl().memory.page_index`` and  ``box.stat.vinyl().memory.bloom_filter``
 have the current amount being used for index-related structures.
 The size is a function of the number and size of keys,
-plus :ref:`page_size <cfg_storage-vinyl_page_size>`,
-plus :ref:`bloom_fpr <cfg_storage-vinyl_bloom_fpr>`.
+plus :ref:`vinyl_page_size <cfg_storage-vinyl_page_size>`,
+plus :ref:`vinyl_bloom_fpr <cfg_storage-vinyl_bloom_fpr>`.
 This is not a count of bloom filter "hits"
 (the number of reads that could be avoided because the
 bloom filter predicts their presence in a run file) --

locale/book/box/engines/index.pot

@@ -395,7 +395,7 @@ msgstr ""
 msgid "To minimize the number of disk reads, especially for nonexistent data, nearly all LSM trees use probabilistic data structures, and Tarantool is no exception. A classical Bloom filter is made up of several (usually 3-to-5) bit arrays. When data is written, several hash functions are calculated for each key in order to get corresponding array positions. The bits at these positions are then set to 1. Due to possible hash collisions, some bits might be set to 1 twice. We’re most interested in the bits that remain 0 after all keys have been added. When looking for an element within a run, the same hash functions are applied to produce bit positions in the arrays. If any of the bits at these positions is 0, then the element is definitely not in the run. The probability of a false positive in a Bloom filter is calculated using Bayes’ theorem: each hash function is an independent random variable, so the probability of a collision simultaneously occurring in all of the bit arrays is infinitesimal."
 msgstr ""
 
-msgid "The key advantage of Bloom filters in Tarantool is that they’re easily configurable. The only parameter that can be specified separately for each index is called ``bloom_fpr`` (FPR stands for \"false positive ratio\") and it has the default value of 0.05, which translates to a 5% FPR. Based on this parameter, Tarantool automatically creates Bloom filters of the optimal size for partial- key and full-key searches. The Bloom filters are stored in the `.index` file, along with the page index, and are cached in RAM."
+msgid "The key advantage of Bloom filters in Tarantool is that they’re easily configurable. The only parameter that can be specified separately for each index is called ``vinyl_bloom_fpr`` (FPR stands for \"false positive ratio\") and it has the default value of 0.05, which translates to a 5% FPR. Based on this parameter, Tarantool automatically creates Bloom filters of the optimal size for partial- key and full-key searches. The Bloom filters are stored in the `.index` file, along with the page index, and are cached in RAM."
 msgstr ""
 
 msgid "Caching"

locale/reference/reference_lua/box_stat.pot

@@ -123,7 +123,7 @@ msgstr ""
 msgid "``box.stat.vinyl().memory.level0`` is the \"level0\" memory area, sometimes abbreviated \"L0\", which is the area that vinyl can use for in-memory storage of an LSM tree."
 msgstr ""
 
-msgid "Therefore we can say that \"L0 is becoming full\" when the amount in ``memory.level0`` is close to the maximum, which is :ref:`regulator.dump_watermark <box_introspection-box_stat_vinyl_regulator>`. We can expect that \"L0 = 0\" immediately after a dump. ``box.stat.vinyl().memory.page_index`` and  ``box.stat.vinyl().memory.bloom_filter`` have the current amount being used for index-related structures. The size is a function of the number and size of keys, plus :ref:`page_size <cfg_storage-vinyl_page_size>`, plus :ref:`bloom_fpr <cfg_storage-vinyl_bloom_fpr>`. This is not a count of bloom filter \"hits\" (the number of reads that could be avoided because the bloom filter predicts their presence in a run file) -- that statistic can be found with :ref:`index_object:stat() <box_index-stat>`."
+msgid "Therefore we can say that \"L0 is becoming full\" when the amount in ``memory.level0`` is close to the maximum, which is :ref:`regulator.dump_watermark <box_introspection-box_stat_vinyl_regulator>`. We can expect that \"L0 = 0\" immediately after a dump. ``box.stat.vinyl().memory.page_index`` and  ``box.stat.vinyl().memory.bloom_filter`` have the current amount being used for index-related structures. The size is a function of the number and size of keys, plus :ref:`vinyl_page_size <cfg_storage-vinyl_page_size>`, plus :ref:`vinyl_bloom_fpr <cfg_storage-vinyl_bloom_fpr>`. This is not a count of bloom filter \"hits\" (the number of reads that could be avoided because the bloom filter predicts their presence in a run file) -- that statistic can be found with :ref:`index_object:stat() <box_index-stat>`."
 msgstr ""
 
 msgid "**Details about box.stat.vinyl().tx:** This is about requests that affect transactional activity (\"tx\" is used here as an abbreviation for \"transaction\"):"

locale/ru/LC_MESSAGES/book/box/engines/index.po

@@ -1223,21 +1223,21 @@ msgstr ""
 msgid ""
 "The key advantage of Bloom filters in Tarantool is that they’re easily "
 "configurable. The only parameter that can be specified separately for "
-"each index is called ``bloom_fpr`` (FPR stands for \"false positive "
-"ratio\") and it has the default value of 0.05, which translates to a 5% "
+"each index is called ``vinyl_bloom_fpr`` (FPR stands for \"false positive"
+" ratio\") and it has the default value of 0.05, which translates to a 5% "
 "FPR. Based on this parameter, Tarantool automatically creates Bloom "
 "filters of the optimal size for partial- key and full-key searches. The "
 "Bloom filters are stored in the `.index` file, along with the page index,"
 " and are cached in RAM."
 msgstr ""
 "Ключевым преимуществом реализации фильтров Блума в Tarantool'е является "
 "простота настройки. Единственный параметр, который можно менять "
-"независимо для каждого индекса, называется ``bloom_fpr`` (FPR в данном "
-"случае означает сокращение от \"false positive ratio\" -- коэффициент "
-"ложноположительного срабатывания), который по умолчанию равен 0,05, или "
-"5%. На основе этого параметра Tarantool автоматически строит фильтры "
-"Блума оптимального размера для поиска как по полному ключу, так и по "
-"компонентам ключа. Сами фильтры Блума хранятся вместе с постраничным "
+"независимо для каждого индекса, называется ``vinyl_bloom_fpr`` (FPR в "
+"данном случае означает сокращение от \"false positive ratio\" -- "
+"коэффициент ложноположительного срабатывания), который по умолчанию равен"
+" 0,05, или 5%. На основе этого параметра Tarantool автоматически строит "
+"фильтры Блума оптимального размера для поиска как по полному ключу, так и"
+" по компонентам ключа. Сами фильтры Блума хранятся вместе с постраничным "
 "индексом в файле `.index` и кэшируются в оперативной памяти."
 
 msgid "Caching"

locale/ru/LC_MESSAGES/reference/reference_lua/box_stat.po

@@ -336,11 +336,12 @@ msgid ""
 "after a dump. ``box.stat.vinyl().memory.page_index`` and  "
 "``box.stat.vinyl().memory.bloom_filter`` have the current amount being "
 "used for index-related structures. The size is a function of the number "
-"and size of keys, plus :ref:`page_size <cfg_storage-vinyl_page_size>`, "
-"plus :ref:`bloom_fpr <cfg_storage-vinyl_bloom_fpr>`. This is not a count "
-"of bloom filter \"hits\" (the number of reads that could be avoided "
-"because the bloom filter predicts their presence in a run file) -- that "
-"statistic can be found with :ref:`index_object:stat() <box_index-stat>`."
+"and size of keys, plus :ref:`vinyl_page_size <cfg_storage-"
+"vinyl_page_size>`, plus :ref:`vinyl_bloom_fpr <cfg_storage-"
+"vinyl_bloom_fpr>`. This is not a count of bloom filter \"hits\" (the "
+"number of reads that could be avoided because the bloom filter predicts "
+"their presence in a run file) -- that statistic can be found with "
+":ref:`index_object:stat() <box_index-stat>`."
 msgstr ""
 "Таким образом, можно сказать, что \"L0 заполняется\", когда объем данных "
 "в ``memory.level0`` приближается к максимальному, а именно "
@@ -349,11 +350,11 @@ msgstr ""
 "создания дампа. Текущий объем в ``box.stat.vinyl().memory.page_index`` и"
 "  ``box.stat.vinyl().memory.bloom_filter`` используется для структур, "
 "связанных с индексами. Размер -- это количество и размер ключей плюс "
-":ref:`page_size <cfg_storage-vinyl_page_size>` плюс :ref:`bloom_fpr "
-"<cfg_storage-vinyl_bloom_fpr>`. Это не счетчик совпадений по фильтру "
-"Блума (количество чтений, которых можно избежать, поскольку фильтра Блума"
-" предсказывает их наличие в файле типа run) -- эта статистика указана в "
-":ref:`index_object:stat() <box_index-stat>`."
+":ref:`vinyl_page_size <cfg_storage-vinyl_page_size>` плюс "
+":ref:`vinyl_bloom_fpr <cfg_storage-vinyl_bloom_fpr>`. Это не счетчик "
+"совпадений по фильтру Блума (количество чтений, которых можно избежать, "
+"поскольку фильтра Блума предсказывает их наличие в файле типа run) -- эта"
+" статистика указана в :ref:`index_object:stat() <box_index-stat>`."
 
 msgid ""
 "**Details about box.stat.vinyl().tx:** This is about requests that affect"