Pull to refresh

Comments 9

Сломался на этом месте

Перед началом выполнения новой транзакции система анализирует, какие записи она будет использовать,

Откуда это известно? Началась транзакция, в которой вызвана процедура Do something complicated, с кучей if и циклами...

Если приводить аналоги, которые уже реализованы: EXPLAIN и, если этого недостаточно, EXPLAIN ANALYZE на snapshot (в postgres).
Но да, вы правы, это самое слабое место в концепции.

Что бы удалить миллиард строк, надо записать миллиард строк в индекс, а потом удалить этот же миллиард строк из индекса.
А кроме того, ещё и индексы к таблице есть. И, по-хорошему, там тоже надо отдельную сущность инспектора на каждый индекс.

И, если я не ошибаюсь, в СУБД, которые работают на основе блокировок, всё это так и выглядит - есть структура в памяти, в которой учитываются блокировки строк, страниц, экстентов, таблиц, индексов, объектов и базы данных.

Если вы хотите удалить миллиард строк через обычный DELETE, то любой DBA вам скажет, что не надо так.

с индексами интересное замечание, есть над чем подумать, спасибо

разница в том, что там транзакции сами обеспечивают свою безопасность путем блокировок (и снапшотов), а тут мы делаем это централизованно. почему это более выгодно, я попытался объяснить в статье

концепция больше рассчитана на OLTP с большим потоком довольно простых транзакций

Интересно. Спасибо. Как раз сейчас думаю как реализовать механизм транзакций для графовой БД.
Бегло посмотрел. Есть несколько вопросов. Почитаю внимательнее.

У вас не будет проблем с транзакциями, если у вас не будет транзакций, а записи с разных узлов будут конвергировать без потерь.

Инвертированный индекс. Звучит как будто его построили, а потом перестроили. Упорядоченный в порядке убывания индекс. Desc Сухо и по делу

вы кажется неправильно поняли, инвертированный индекс это такая структура данных, структура которой "инвертирована" традиционному индексу. в postgres это GIN, насколько я знаю.

Sign up to leave a comment.

Articles