Вообще есть идея удалить и то и другое

ты не хочешь знать чем люди пользуются в sql

Ъ

Или есть перечень банковских счетов в ОЗУ, есть история движения денег между счетами. Ну, много таких примеров на тему OLTP придумать можно.

спасибо

Я знаю, что индексы скаляра нужны для смены типа индексируемого поля. Например, со строки на число. Меняешь тип, запросами ищешь по обоим ключам например, в фоне ковертируешь значения. Потом меняешь скаляр на нужный тип. Удалишь скаляр - придется либо удалять индекс (тогда поиск по нему будет фулскан), конвертировать значения, делать новый индекс. Либо придется добавлять новое поле, копировать в него значения из старого поля с новым типом, строить по этому полю индекс, и потом удалять старый индекс. Потом удалить видимо первые поля как-то, я не знаю как. Полей может быть и много.
Можно найти тикет, который просил добавить индексы скаляра, и там может быть больше инфы.

Отсюда вывод (да, я кэп), что для многих задач можно выкинуть vinyl и насладиться memtx, но тогда нужен отдельный богатый возможностями способ индексирования и обработки тарантуловских журналов.

Ок, спасибо, я подумаю

При чём, когда мы меняем содержимое кортежа, нужно не просто записать в журнал "списали со счёта номер 1234 деньги в размере 5 рублей, осталось 10 рублей", нужно написать, почему мы это сделали ("за 2 минуты телефонного разговора с номером 4321"), т.е. описание транзакции, потребное для последующей обработки, не сводится просто к описанию факта изменения состояния ОЗУ.

Я, наверное, повторяю разговоры, проговоренные в и во вне команды Тарантула сотни раз, но я новенький, поэтому, наверное, высказываю очевидности.

А так - приходится брать vinyl и ручками изобретать журналы поверх тарантуловских пространств кортежей.

Хотя, конечно, если бы была возможность писать в журнал дополнительную информацию и нахлобучивать на журнал независимые обработчики для последующей обработки, то vinyl в OLTP был бы не нужен.

можно пример?

Пример из дискашена:

tarantool> box.execute('CREATE TABLE t (i SCALAR PRIMARY KEY, a SCALAR);')
---
- row_count: 1
...

tarantool> box.execute('INSERT INTO t VALUES (10, 10);')
---
- row_count: 1
...

tarantool> box.execute([[SELECT * FROM t WHERE i < '1';]])
---
- metadata:
  - name: I
    type: scalar
  - name: A
    type: scalar
  rows:
  - [10, 10]
...

tarantool> box.execute([[SELECT * FROM t WHERE a < '1';]])
---
- metadata:
  - name: I
    type: scalar
  - name: A
    type: scalar
  rows: []
...

А вы знаете, что сравнительно недорого можно юзать мемтикс на оптане?

Что такое оптан и зачем на нём юзать мемтикс?

Если у вас большие объёмы данных (журналы), вы хотите по ним быстрый поиск, но вы не хотите связываться с выгрузкой в олап и винилом, то можете вместо RAM использовать Optane — в 4 раза дешевле, в несколько раз больше объёма на один юнит

Можно было бы и связаться, но всё равно не получается выжать из железа максимум. Memtx работает быстрее и удобнее всего, если не прерывать его на работу с внешним миром, так? А если связываться с выгрузкой куда бы то ни было, то начинается MVCC...

Не обязательно. Всё зависит от паттернов использования выгружаемых данных, в большинстве случаев достаточно асинхронности и eventual.

Если нужна транзакционная выгрузка (а в типичном OLTP именно она и нужна, мы не хотим ни терять записи о случившемся, ни читать из журнала фантомные записи о несовершившихся транзакциях как о совершившихся), то либо механизм записи расширенного журнала транзакций д.б. встроен в движок, либо мы приходим к распределённой транзакции (aka Two-phase commit). Двуфазный коммит можно делать и внешним менеджером (например, подцепив tarantool внутрь PostgreSQL в качестве расширения), но в этом случае караван будет двигаться со скоростью самого медленного корабля.