LINUX.ORG.RU

История изменений

Исправление aist1, (текущая версия) :

Просто, не нужно впадать в крайности вроде «только ACID» или «только Eventual Consistency».

Можно так? «EC только при условии, что вы точно знаете, что вам нужно именно это и осознаете, во что это вам обойдется».

Насчет кластера из 3-5 узлов (или стоек), я не про Pg говорил. Этот еще лет 10 будет пытаться лечить ограничения своей архитектуры. Я говорил про то, что само такое железо, благодаря своему профилю отказоустойчивости, может в принципе обеспечить высокую абсолютную производительность. Задача софта — утилизировать её. Pg в этом смысле — не лучший вариант. Хотя и хороший во всех остальных смыслах.

Дело в том, что имея Меморию на руках, я технически могу это железо утилизировать. Потому что Мемория дизайнится для scale-up-сценариев: я там контролирую весь путь от io_uring/SPDK-exposed устройства и до обработки данных на акселераторах. Там по умолчанию SWMR-сериализованные транзакции с MVCC, но можно делать высокоуровневый шардинг, чтобы ослаблять консистентность там, где надо, и на столько, на сколько надо.

SWMR (single writer, multiple readers), кстати, очень классная схема. Вообще гениальная, если в сочетании с ПСД. Она позволяет атомарно сбрасывать состояние RAM на NVmem так, что новые данные никогда не перезатирают старые, и не требует сборки мусора (но все равно требует не-атомарных счетчиков).

Что касается софта в такой модели. Я буду на основе ПСД делать хранилище для системы сборки в своем форке Clang. Это будет BaaS для IDE-шек, который возьмет на себя весь цикл: редактирование, сборка, аналитика и т.д. Компилятор там умеет в метафункции и через них будет тесно интегрирован с системой сборки.

Исходная версия aist1, :

Просто, не нужно впадать в крайности вроде «только ACID» или «только Eventual Consistency».

Можно так? «EC только при условии, что вы точно знаете, что вам нужно именно это и осознаете, во что это вам обойдется».

Насчет кластера из 3-5 узлов (или стоек), я не про Pg говорил. Этот еще лет 10 будет пытаться лечить ограничения своей архитектуры. Я говорил про то, что само такое железо, благодаря своему профилю отказоустойчивости, может в принципе обеспечить высокую абсолютную производительность. Задача софта — утилизировать её. Pg в этом смысле — не лучший вариант. Хотя и хороший во всех остальных смыслах.

Дело в том, что имея Меморию на руках, я технически могу это железо утилизировать. Потому что Мемория дизайнится для scale-up-сценариев: я там контролирую весь путь от io_uring/SPDK-exposed устройства и до обработки данных на акселераторах. Там по умолчанию SWMR-сериализованные транзакции с MVCC, но можно делать высокоуровневый шардинг, чтобы ослаблять консистентность там, где надо, и на столько, на сколько надо.

SWMR (single writer, multiple readers), кстати, очень классная схема. Вообще гениальная, если в сочетании с ПСД. Она позволяет атомарно сбрасывать состояние RAM на NVmem так, что новые данные никогда не перезатирают старые, и не требует сборки мусора (но все равно требует не-атомарных счетчиков).

Что касается софта в такой модели. Я буду на основе ПСД делать хранилище для системы сборки в своем форке Clang. Это будет BaaS для IDE-шек, который возьмет на себя весь цикл: редактирование, сборка, аналитика и т.д.