Телеграмм чат группы tarantoolru страница 7645

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Tarantool

1151 membersпожаловаться на группу

2021 February 09

AL

Andrey L in Tarantool

@a_lyapunov рассказывает про новый менеджер транзакций в Tarantool 2.6

https://habr.com/ru/company/mailru/blog/540842/

---

Для нового менеджера транзакций memtx мы сформировали список требований, которому не удовлетворяли ни текущая реализация транзакций memtx, ни менеджер транзакций vinyl:

1. Дешево по памяти и производительности по принципу «не используешь — не платишь». Если разные транзакции работают с непересекающимися данными, то хочется иметь обычную производительность, как без менеджера.

2. При пересекающихся множествах данных производительность также должна оставаться на достойном уровне.

3. Реализация должна быть максимально независимой от типа индекса.

4. Serializable без блокировок (то есть с абортами при конфликте), как в vinyl.

Менеджер транзакций для базы данных в оперативной памяти

В этот статье я хочу еще раз пройтись по особенностям работы транзакций в Tarantool, применительно к движку в памяти и дисковому движку. И главное — расскажу п...

Крайне тяжело читать. Как будто пишет разработчик тарантула для разработчика тарантула (все обо всем в курсе).
*Уровни изоляции в постгресовой доке значительно проще описаны.

источник

11:08пожаловаться #1

AL

Aleksandr Lyapunov in Tarantool

это жаль. я старался.

источник

11:13пожаловаться #2

KO

Konstantin Osipov in Tarantool

Aleksandr Lyapunov

1. транзакция 1 читаем вторичный ключ 1
2. транзакция 2 пишет что-то, что имеет вторичный ключ 1
3. транзакция 2 пишет 42
4. транзакция 1 читает ключ 42 - и НЕ должна увидеть то, что записала 2я.
значит нам надо трекать чтение по вторичному ключу

идея в том что тебе для первичного ключа всё равно нужно хранить гэп локи, если хэш изменить на bps, для первичного ключа проблема с гэп локами решится.

источник

11:15пожаловаться #3

KO

Konstantin Osipov in Tarantool

по вторичным ключам ты можешь предполагать что любое чтение по вторичному ключу берёт гэп лок на весь первичный.

источник

11:16пожаловаться #4

KO

Konstantin Osipov in Tarantool

(если очень хочется serializable)

источник

11:16пожаловаться #5

AL

Aleksandr Lyapunov in Tarantool

а. ну это злобно слишком.

источник

11:16пожаловаться #6

KO

Konstantin Osipov in Tarantool

и просто ждать завершения транзакции в случае обнаружения конфликта по гэп локу.

источник

11:16пожаловаться #7

AL

Aleksandr Lyapunov in Tarantool

но ждать при любом селекте по вторичному ключу.. звучит как адища же.

источник

11:17пожаловаться #8

KO

Konstantin Osipov in Tarantool

я предлагал это делать только при конфликте по гэп локу

источник

11:20пожаловаться #9

KO

Konstantin Osipov in Tarantool

а не при любом конфликте

источник

11:20пожаловаться #10

AL

Andrey L in Tarantool

Вам бы форк. Одну ветку развивать как тарантул - супер-быструю, в известных рамках. На второй развлекаться попытками приблизить её к постгресу, снова изобретать ctid, xmin, xmax, развивать sql и проч.

источник

11:23пожаловаться #11

AL

Aleksandr Lyapunov in Tarantool

да. ну все равно злобно.
имхо блокировка ценный механизм, но не панацея.
мы сделаем блокировки как альтернативу abort by conflict. это в общем-то ортогональная задача - mvcc и conflict manager будут работать так же.

источник

11:23пожаловаться #12

AL

Aleksandr Lyapunov in Tarantool

новый mvcc сделан по принципу "не используешь - не платишь". нам не нужен форк.

источник

11:25пожаловаться #13

AL

Andrey L in Tarantool

Постгрес из-за своей реализации версионности плохо работает при интенсивном обновлении одних и тех же кортежей (по сути, не работает нормально). Взяли на эту зону тарантул. И вот опять..

источник

11:28пожаловаться #14

AL

Aleksandr Lyapunov in Tarantool

я не думаю, что стоит на нас распространять проблемы посгреса

источник

12:00пожаловаться #15

DS

Dmitry Sharonov in Tarantool

Постгрес из-за своей реализации версионности плохо работает при интенсивном обновлении одних и тех же кортежей (по сути, не работает нормально). Взяли на эту зону тарантул. И вот опять..

и на что наехали?

источник

12:01пожаловаться #16

AS

Anatoliy Shipitcyn in Tarantool

Постгрес из-за своей реализации версионности плохо работает при интенсивном обновлении одних и тех же кортежей (по сути, не работает нормально). Взяли на эту зону тарантул. И вот опять..

Это не мы такие это жись такая

источник

12:02пожаловаться #17

AL

Andrey L in Tarantool

Dmitry Sharonov

и на что наехали?

Не наехали. Печалька в том, что позиционирование меняется, приоритеты меняются. И в той нише, которую можно было занять, так и остается пол тарантула. А там, куда всё движется, и без тарантула неплохо живут. КМК

источник

12:12пожаловаться #18

AL

Andrey L in Tarantool

постгресовая засада:

do
$$
declare
  _t1 timestamp;
begin
  create unlogged table if not exists hot_test(num int primary key, amount numeric);
  for n in 1..3 loop
    insert into hot_test values (1, 1234), (2, 2345), (3, 3456), (4, 4567);
    _t1 := clock_timestamp();

    for i in 1..(n*n*1000) loop
      update hot_test
      set amount = amount;
    end loop;

    raise notice '%: %', n*n*1000, clock_timestamp() - _t1;
    truncate table hot_test;
  end loop;
  drop table hot_test;
end
$$

источник

12:24пожаловаться #19

MA

Mons Anderson in Tarantool

Постгрес из-за своей реализации версионности плохо работает при интенсивном обновлении одних и тех же кортежей (по сути, не работает нормально). Взяли на эту зону тарантул. И вот опять..

транзакционный менеджер опционально включаемый.
режим с non-yield-transactions остаётся, так как он очень удобный. и мы не планируем его выкорчёвывать и уходить в сторону mvcc.
если интерактивные транзакции не нужны, то разницы не заметите.

источник

12:34пожаловаться #20