The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.

Overview

Project website www.tarantool.io/en/doc/latest
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository git@github.com:tarantool/doc.git
Repository branch test-weblate
Last remote commit updated pot afee6c42
TarantoolBot authored a year ago
Weblate repository http://weblate.tarantool.io/git/testing_project/documentation-conceptsenginesmemtx/
File mask locale/*/LC_MESSAGES/concepts/engines/vinyl.po
Translation file Not available
Last change None
Last author None

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 136 6,309 36,977
Translated 100% 136 100% 6,309 100% 36,977
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 136 100% 6,309 100% 36,977
Failing checks 3% 5 9% 616 9% 3,581
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 137 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb

Quick numbers

6,309
Hosted words
136
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

Tarantool does all of these calculations automatically, constantly updating the rolling average of the DBMS workload and the histogram of the disk speed. This allows using L0 as efficiently as possible and it prevents write requests from timing out. But in the case of workload surges, some wait time is still possible. That’s why we also introduced an insertion timeout (the ``vinyl_timeout`` parameter), which is set to 60 seconds by default. The write operation itself is executed in dedicated threads. The number of these threads (4 by default) is controlled by the ``vinyl_write_threads`` parameter. The default value of 2 allows doing dumps and compactions in parallel, which is also necessary for ensuring system predictability.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

If secondary indexes are not unique, then collecting "garbage" from them can be put off until a compaction, which is what we do in Tarantool. The append-only nature of LSM trees allowed us to implement full-blown serializable transactions in vinyl. Read-only requests use older versions of data without blocking any writes. The transaction manager itself is fairly simple for now: in classical terms, it implements the MVTO (multiversion timestamp ordering) class, whereby the winning transaction is the one that finished earlier. There are no locks and associated deadlocks. Strange as it may seem, this is a drawback rather than an advantage: with parallel execution, you can increase the number of successful transactions by simply holding some of them on lock when necessary. We’re planning to improve the transaction manager soon. In the current release, we focused on making the algorithm behave 100% correctly and predictably. For example, our transaction manager is one of the few on the NoSQL market that supports so-called "gap locks".
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

Update is not the only operation where optimizing hidden reads is critical. Even the replace operation, given secondary keys, has to read the older value: it needs to be independently deleted from the secondary indexes, and inserting a new element might not do this, leaving some garbage behind.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

Secondary keys
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

We solved the problem by adding a background process that performed readaheads on any keys that had more than a few dozen upserts piled up, so all those upserts were squashed and substituted with the read value.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

We started digging into the issue and found out that the distribution of requests across keys was significantly different from what we had seen in the test environment. It was...well, quite nonuniform. Most keys were updated once or twice a day, so the database was idle for the most part, but there were much hotter keys with tens of thousands of updates per day. Tarantool handled those just fine. But in the case of lookups by key with tens of thousands of upserts, things quickly went downhill. To return the most recent value, Tarantool had to read and "replay" the whole history consisting of all of the upserts. When designing upserts, we had hoped this would happen automatically during a compaction, but the process never even got to that stage: the L0 size was more than enough, so there were no dumps.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

Nevertheless, after a couple of days, the Tarantool process started eating up 100% of our CPU, and the system performance dropped close to zero.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

I’d like to tell you a short story about an upsert. It takes place back when vinyl was only beginning to "mature" and we were using an upsert in production for the first time. We had what seemed like an ideal environment for it: we had tons of keys, the current time was being used as values; update operations were inserting keys or modifying the current time; and we had few reads. Load tests yielded great results.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

Even though an upsert is a very important optimization and implementing it cost us a lot of blood, sweat, and tears, we must admit that it has limited applicability. If a table contains secondary keys or triggers, hidden reads can’t be avoided. But if you have a scenario where secondary keys are not required and the update following the transaction completion will certainly not cause any errors, then the operation is for you.
a year ago
User avatar None

New source string

testing_project / Documentation: concepts/engines/vinyl — English

A semantically similar operation exists in many products including PostgreSQL and MongoDB. But anywhere you look, it’s just syntactic sugar that combines the update and replace operations without avoiding hidden reads. Most probably, the reason is that LSM trees as data storage structures are relatively new.
a year ago
Browse all translation changes