Comments 15
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-блокировка не даст этого сделать в рамках одного чтения
Вы забыли про Hive. Берем паркет, и опа — получаем столбцовую БД, вообще говоря. Ну, может не совсем — но таки почти.
Это что ещё за "No lock" в Postgres выдумали? Уровень изоляции "Read uncommitted" там не поддерживается.
Про эскалацию блокировок на уровень таблицы тоже очень расплывчато написано. Будто бы так делают все РСУБД. Это неправда.
Cassandra и HBase это не столбцовые БД, если брать определение из вашей же лекции. Это "wide column store", которые по сути являются key-value БД c небольшим сахаром поверх.
Нет. Cassandra (ScyllaDB) и HBase реализуют одинаковую идеалогию двух-уровневого key-value: partition key + clustering key. Отличие: в Cassandra partition key распределяется в distributed hash table, а в HBase он тоже "сортирован".
Каждый ((pk, ck), value) - это отдельная запись в сторадже с временем вставки и возможным маркером удаления. В HBase даже можно использовать время вставки как третий ключ, и получать историю изменения одного value.
Колоночными их назвали по ошибке, потому что в английском они использовали понятие wide column : в одной Row (которая есть value для partition key) может быть огромное множество полей (field) с не фиксированными именами.
https://en.wikipedia.org/wiki/Wide-column_store
Wide-column stores such as Bigtable and Apache Cassandra are not column stores
Вот ClickHouse - истинно колоночная база данных. А также Amazon RedShift, Greenplum, Sybase IQ (SAP IQ), KDB и другие
https://en.wikipedia.org/wiki/List_of_column-oriented_DBMSes
Так же можно считать "колоночными базами" различные Hadoop/BigData движки запросов (Presto, Hive, Spark) поверх специальных форматов файлов (Parquet, ORC).
Ну да, наверное. Только надо понимать, что умение читать из паркета одну или две колонки из 100 — это не совсем неотъемлемое свойство движка, т.е. это делает оптимизатор, а он не факт что безгрешен в этом плане. Вполне могу представить ситуацию, когда оптимизатору спарке не хватит информации для принятия решения, что можно выбрать всего одну колонку.
Можно ещё порекомендовать пару книг на эту тему для тех кто хочет копнуть немного поглубже:
Database Internals и Designing Data-Intensive Applications.
Отзывы у обеих, ИМО, немного завышены, но они стоят прочтения.
При оптимистическом — переговорка не блокируется пока юзер (процесс обновления)
думает. И параллельный процесс может ее взять и забронировать пока первый все еще думает. Первый додумав и решившись таки — получит ошибку вида «упс, кто-то уже забронировал вы не успели». Оптимизм в том что мы думаем что никто другой не успеет взять наш ресурс.
При пессимистической блокировке — переговорка блокируется на запись сразу же как первый юзер ее открыл и начал думать. Понятно конкуренты могут ее видеть но сделать ничего с ней ничего не могут, пока первый не или не закоммитится или тайм-аут блокировки не пройдет. Пессимизм в том что мы сразу думаем что мы тут не одни, и обязательно кто-то нашу переговорку захватить захочет.
Плюсы оптимистической стратегии блокировок — нет захвата ресурсов, и конкурентам не надо ждать конца тайм-аута пока освободится ресурс. Хорошо подходит там где все заходят «я только посмотреть», а % реальных броней переговорок мал.
Плюсы пессимистической стратегии — не надо пытаться успеть, если ты уже нашел свободный ресурс. Думай свои 15 минут, переговорку не уведут. Подходит там где люди не толпятся чисто посмотреть, а заходят реально забронировать ресурс и % ресурсов разблокирующихся по таймауту мал.
Базы данных: большой обзор типов и подходов. Доклад Яндекса