Открыть список
Как стать автором
Обновить

Комментарии 13

Read committed, чтение фиксированных данных. Этот уровень изоляции используется по умолчанию в большинстве реляционных баз, в том числе и в PostgreSQL, и в Oracle. Он гарантирует, что вы никогда не прочитаете «грязные» данные. То есть другая транзакция никогда не видит промежуточных этапов первой транзакции. Преимущество в том, что это очень хорошо подходит для маленьких коротких запросов. Мы гарантируем, что у нас никогда не будет ситуации, когда мы видим какие-то части данных, недописанные данные. Например, увеличиваем зарплату целому отделу и не видим, когда только часть людей получили прибавку, а вторая часть сидит с неиндексированной зарплатой. Потому что если у нас будет такая ситуация, логично, что наша аналитика сразу «поедет».

в целом написана ерунда. read committed из стандарта ANSI не гарантирует консистентность данных на момент старта запроса. такие гарантии дают оракл и постгрес т.к. на самом деле у них более строгий read committed, чем требует стандарт. тот же mssql на read committed может прочесть одну и ту же запись несколько раз, если по мере чтения запись куда-то переезжала (например из одной партиции в другую). по той же причине может пропустить запись. и такая лажа, как минимум по мнению майкрософт, соответствует стандарту.
sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level
Полезный комментарий и спасибо за ссылку! Пометила в комментариях к лекции.
Этот случай как нельзя лучше подсвечивает, что общие лекции показывают направления, которые нужно иметь в виду и в которые можно копать. Каждый продукт имеет свои особенности, и путь к успеху — не смотреть слепо на стандарты, а, берясь за то или иное решение, изучать как именно оно устроено изнутри.

Не говорите ерунды, S-блокировка не даст этого сделать в рамках одного чтения

блокировочный read committed ставит shared блокировку лишь на одну единственную запись из огромной выборки необходимой для чтения, соответственно параллельным транзакциям ничего не мешает апдейтить записи, что уже были считаны.
ознакомьтесь с основами.
Ладно-ладно, признаю, может такое быть в принципе, но на практике ни разу с таким не сталкивался, да и блокировку стараюсь держать до конца транзакции, где это необходимо
>Самые популярные столбцовые — это, наверное, Cassandra, HBase и ClickHouse.
Вы забыли про Hive. Берем паркет, и опа — получаем столбцовую БД, вообще говоря. Ну, может не совсем — но таки почти.
Вообще как-то их называют больше Колоночные БД aka «Columnstore». И их очень много — я бы самыми популярными Snowflake и Redshift назвал.
Ну, тут написано самые популярные, мне сложно оценить, на самом ли деле так для всех. Я просто к тому что в мире BigData самая популярная точно Hive, и она на выбор — хочешь по строкам храни, хочешь — по колонкам.

Это что ещё за "No lock" в Postgres выдумали? Уровень изоляции "Read uncommitted" там не поддерживается.


Про эскалацию блокировок на уровень таблицы тоже очень расплывчато написано. Будто бы так делают все РСУБД. Это неправда.

Cassandra и HBase это не столбцовые БД, если брать определение из вашей же лекции. Это "wide column store", которые по сути являются key-value БД c небольшим сахаром поверх.

Ну, хранят в HBase вроде все-таки в порядке column group, насколько я помню (хотя могу ошибаться)? Скорее всего эти понятия могут перемешиваться, на уровне API — key-value, на уровне физического хранения — по колонкам.
Спасибо за статью.
Можно ещё порекомендовать пару книг на эту тему для тех кто хочет копнуть немного поглубже:
Database Internals и Designing Data-Intensive Applications.
Отзывы у обеих, ИМО, немного завышены, но они стоят прочтения.
Добавлю про кейс «Блокирование переговорки» — это классическая задача имеющая классических же 2 подхода — «оптимистическую» и «пессимистическую» типы блокировки.
При оптимистическом — переговорка не блокируется пока юзер (процесс обновления)
думает. И параллельный процесс может ее взять и забронировать пока первый все еще думает. Первый додумав и решившись таки — получит ошибку вида «упс, кто-то уже забронировал вы не успели». Оптимизм в том что мы думаем что никто другой не успеет взять наш ресурс.
При пессимистической блокировке — переговорка блокируется на запись сразу же как первый юзер ее открыл и начал думать. Понятно конкуренты могут ее видеть но сделать ничего с ней ничего не могут, пока первый не или не закоммитится или тайм-аут блокировки не пройдет. Пессимизм в том что мы сразу думаем что мы тут не одни, и обязательно кто-то нашу переговорку захватить захочет.

Плюсы оптимистической стратегии блокировок — нет захвата ресурсов, и конкурентам не надо ждать конца тайм-аута пока освободится ресурс. Хорошо подходит там где все заходят «я только посмотреть», а % реальных броней переговорок мал.
Плюсы пессимистической стратегии — не надо пытаться успеть, если ты уже нашел свободный ресурс. Думай свои 15 минут, переговорку не уведут. Подходит там где люди не толпятся чисто посмотреть, а заходят реально забронировать ресурс и % ресурсов разблокирующихся по таймауту мал.

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

Информация

Дата основания
Местоположение
Россия
Сайт
www.yandex.ru
Численность
свыше 10 000 человек
Дата регистрации

Блог на Хабре