Комментарии 23
Неплохая статья, но, мне кажется, что concurrent в переводе на русский--это не конкурентный, а параллельный/одновременный/синхронный. В русском переводе Фаулера используется обычно «параллельный».
Термин «конкурентный» (competitive) выбрал чтобы подчеркнуть именно соревновательный аспект. У Фаулера данный термин не присутствует. А там где речь идёт о параллелизме используется термин «параллельный». Хотя соглашусь, что повсеместно использования термина «параллельный» было бы менее запутанным.
www.gnu.org/software/pth/pth-manual.html#item_o_concurrency_vs_2e_parallelism
Concurrency exists when at least two threads are in progress at the same time. Parallelism arises when at least two threads are executing simultaneously. Real parallelism can be only achieved on multiprocessor machines, of course. But one also usually speaks of parallelism or high concurrency in the context of preemptive thread scheduling and of low concurrency in the context of non-preemptive thread scheduling.
Так что, конкурентность здесь больше по смыслу
Concurrency exists when at least two threads are in progress at the same time. Parallelism arises when at least two threads are executing simultaneously. Real parallelism can be only achieved on multiprocessor machines, of course. But one also usually speaks of parallelism or high concurrency in the context of preemptive thread scheduling and of low concurrency in the context of non-preemptive thread scheduling.
Так что, конкурентность здесь больше по смыслу
Мне кажется, имело бы смысл, написать про возможные проблемы при использовании того или иного уровня изоляции транзакций: грязные чтения, неповторяющиеся чтения, etc.
НЛО прилетело и опубликовало эту надпись здесь
Будем надеяться что автор коснётся этих проблем в будущих статьях.
Одни из самых распространненых грабель у 1Сников
НЛО прилетело и опубликовало эту надпись здесь
К примеру, можно указать время блокировки или null вместо false, а в коде предусмотреть, что если блокировка поставлена больше 30 секунд назад (или любое другое время, в каждом случае выбираемое индивидуально: в первом случае это время было бы несколько секунд, во втором — несколько минут), то считать строку не заблокированной.
Как вариант, еще можно использовать уникальный идентификатор заблокировавшего процесса, соответственно, если блокировка по времени истекла и ее забрал кто-то другой, то первый процесс должен проверить, он ли ставил блокировку.
В общем, вариантов много можно выдумать и они не сложные, но в каждом конкретном случае подход может оказаться разным в зависимости от ТЗ.
Как вариант, еще можно использовать уникальный идентификатор заблокировавшего процесса, соответственно, если блокировка по времени истекла и ее забрал кто-то другой, то первый процесс должен проверить, он ли ставил блокировку.
В общем, вариантов много можно выдумать и они не сложные, но в каждом конкретном случае подход может оказаться разным в зависимости от ТЗ.
Есть такое хорошее слово 'совместный' — дословный перевод concurrent, и по смыслу подходит, и читать легче было бы.
Очень правильная статья, заставляет задуматься!
Основной ошибкой проектирования систем является непонимание архитектора, что ошибка выполнения транзакции — это НОРМАЛЬНОЕ состояние, а не исключительная ситуация. При optimistic locking справедливо правило: «let it fault!». Стандартное решение в данной ситуации — это отслеживать коллизии и делать повтор. Однако ни один фреймворк по дефолту это не предлагает.
На практике во всех движках вместо ТруЪ serializable level используют более слабый snapshot isolation en.wikipedia.org/wiki/Snapshot_isolation
Каждая транзакция видит «снимок» базы на момент ее начала. Метод базируется на сохранении нескольких версий измененных данных, доступных на время другим транзакциям: en.wikipedia.org/wiki/Multiversion_concurrency_control
MVCC вместе с write lock дает хорошую производительность, и уровень близкий к serializable. Различие заключается лишь в том, что последовательность обработки двух разных транзакций не гарантируется.
Основной ошибкой проектирования систем является непонимание архитектора, что ошибка выполнения транзакции — это НОРМАЛЬНОЕ состояние, а не исключительная ситуация. При optimistic locking справедливо правило: «let it fault!». Стандартное решение в данной ситуации — это отслеживать коллизии и делать повтор. Однако ни один фреймворк по дефолту это не предлагает.
На практике во всех движках вместо ТруЪ serializable level используют более слабый snapshot isolation en.wikipedia.org/wiki/Snapshot_isolation
Каждая транзакция видит «снимок» базы на момент ее начала. Метод базируется на сохранении нескольких версий измененных данных, доступных на время другим транзакциям: en.wikipedia.org/wiki/Multiversion_concurrency_control
MVCC вместе с write lock дает хорошую производительность, и уровень близкий к serializable. Различие заключается лишь в том, что последовательность обработки двух разных транзакций не гарантируется.
Большое спасибо за статью. Раньше всегда в таблицы вводил поле version, чтоб контролировать доступ и изменение. Теперь буду знать.
Как уже было сказано Serializable Postgree — не соответствует честному Serializable, который описан в стандарте. В частности он допускает аномалии типа write skew, чего честный Serializable делать не должен.
Вообще, класика подробностей про уровней изоляции — A Critique of ANSI SQL Isolation Levels research.microsoft.com/pubs/69541/tr-95-51.pdf
Вообще, класика подробностей про уровней изоляции — A Critique of ANSI SQL Isolation Levels research.microsoft.com/pubs/69541/tr-95-51.pdf
В PostgreSQL 9.1, beta которой вышла на днях, изменено поведение уровня Serializable. Новая фича называется SSI (Serializable Snapshot Isolation), и гарантирует True serializability без существенного замедления работы СУБД. Предыдущее поведение Serializable стало Repeatable Read. Подробнее: www.postgresql.org/docs/9.1/static/transaction-iso.html#XACT-SERIALIZABLE. PostgreSQL, кстати, первая СУБД, реализовавшая SSI.
Молодцы! =)) Другое дело что «без существенного замедления работы» вопрос открытый. В случае конфликта откат транзакции скорее всего будет дороже блокировки, хотя тут все от конкретных сценариев зависит. Но в любом случае, хорошо, что появился уровень изоляции гарантирующий честный Serializability без дополнительных приседаний.
Я имел ввиду без существенного замедления для случаев, когда конфликтов нет, т.е. в нормальных условиях для абсолютного большинства транзакций. В случае, когда конфликт есть, корректность важнее скорости, если же это не так — можно установить repeatable read и вернуться к поведению, которое было в 9.0 и более ранних версиях.
А я имел ввиду сравнение с традиционными блокировочными планировщиками =)
В отсутствие конфликтов накладные расходы в среднем одинаковые, а вот если конфликт случился, то в большинстве случаев подождать на блокировке будет дешевле чем откатывать транзакцию и пытаться выполнить ее снова.
В отсутствие конфликтов накладные расходы в среднем одинаковые, а вот если конфликт случился, то в большинстве случаев подождать на блокировке будет дешевле чем откатывать транзакцию и пытаться выполнить ее снова.
Вот только конфликты в такой системе будут происходить гораздо чаще, и они внесут больший вклад в общую производительность, чем откат транзакций при конфликте в MVCC.
С чего бы это им чаще происходить? В обычном MVCC-шном снэпшоте RW не конфликтуют, поэтому там потенциально число конфликтов меньше, однако в предложенной технике RW вполне себе конфликтующие операции. Что не удивительно, иначе транзакции нельзя было бы корректно сериализовать.
Таким образом, число конфликтов, при одинаковой схеме данных и запросах, при использовании обоих техник должно быть одинаковым, и это при условии что в SSI корректно реализовали все известные блокировочные оптимизации типа key-range lock-а.
Таким образом, число конфликтов, при одинаковой схеме данных и запросах, при использовании обоих техник должно быть одинаковым, и это при условии что в SSI корректно реализовали все известные блокировочные оптимизации типа key-range lock-а.
Хорошая статья, а не Пименов ли заказал ее для внутреннего обучения?
Нет. И понятие такого то нет «внутреннее обучение». Не знаю было ли)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конкурентный доступ к реляционным базам данных