>>Операция получения (захвата) задачи — атомарна (один UPDATE запрос). Никаких проблем с блокировкой и RC.
>>Возможность неблокирующей работы с очередью реализована через использование пользовательских переменных в UPDATE запросе с их последующей выборкой. Посвящать этому приему целую статью — глупо.
Нет уж простите. В этом ведь и весь самый-самый цимес. Как это вы умудряетесь захватывать задачи без блокировок? Неужели сразу же после захвата фиксируете транзакцию? Уборщица помыла полы в серверной, сессия срубилась, не завершенная задача не освободилась?
>>А зачем при уровне изоляции read commited накапливать версии??
Чтобы обеспечить согласованность результата на время выполнения запроса, если данные, которые попадают в выборку в это самое время меняются другой транзакцией.
>>И откуда у вас информация что MySQL
Всю жизнь считал что это так.
Однако ж, похоже, я очень заблуждался. >>>
Прям таки разрыв шаблона
>>открываете одну транзакцию
Сессию или транзакцию? Если транзакцию открывать явно то да, ясно. Я говорил о неявных транзакциях — тех, которые открываются не start transaction, а которые система сама система, для выполнения стайтмента, если транзакция явно не открыта. Или я бред говорю, и такого нет в MySQL?
В случае же с явными транзакциями тут тонкий вопрос. Транзакцию явно открывают вполне для определенных целях. Да, дотошный программист самостоятельно установит нужный ему уровень изоляции. Но может и забыть, и на старуху бывает… И если приложение протестировано в одном уровне изоляции, приложение прошло проверку временем, то смена уровня изоляции может оказаться очень черевата для таких явно открытых тразнакций. Такое решение требует тщательного тестирования, а тестирование конкурирующих процессов весьма не просто организоываать.
>>Вы можете легко проверить что ошибаетесь
К сожалению не могу, в ареоле моего обитания нет ни одного инстанса MySQL. Но тема мне очень интересна.
>>Чем длиннее ваш запрос или транзакция, тем больше «старых» данных продолжает накапливать MySQL и есть основания предполагать, что происходит это с активным использованием основного пула памяти.
я ошибаюсь или MySQL — блокировочник? Он не накапливает данные, как это делают упомянутые Вами версионники оракл и постгр, он блокирует модификацю данных для получения согласованного результата. По этой причине и запись блокирует чтение и чтение блокирует запись. В оракле, постгре нет такого понятия как блокировки по чтению, они накапливают версии, скорее этим обуславливается преимущество этих СУБД, о котором вы упоминаете, нежели уровень изоляции транзакции по умолчанию. К слову, надо заметить, что ораклиный и постгровский read commited, за счет такой реализации, не в полной мере вписывается в стандарт ansi
Я ошибаюсь или действительно в MySQL открытая неявно транзакция закрывается сразу же после выполнения стейтмента? Если нет, то в чем разница блокировок, кинутых запросом в read commited и в repeatable read? Могу ошибаться, полагая, что стратегия блокирования на этих уровнях одинакова, разница лишь в том, что в read commited блокировки отпускаются сразу при завершении работы стейтмента, а в read commmited они отпускаются лишь при завершении транзакции. Если у нас транзакция закрывается сразу после выполнения запроса, разница, как бы, получается, не особо и проглядывается.
Было бы еще так же интересно почитать статьи «не ФС», «не Сборщик Мусора», «не Виртуализация», «не Веб». Определенно найдется не мало задач, где эти технологические компоненты не нужны, но используются.
Пробовали смотреть в сторону отложенных(deffered) ограничений целостности? Которые проверяются не при непосредственной вставки в таблицу, а при фиксации транзакции. Оракл — умеет. PG, слышал, — тоже. MS — низна
>>Я так и не понял, с чего взяли, что резервирование происходит на этапе оформления заказа…
я так понял из
при работе с заказом необходимо наличие таких функций, как:
резервирование товара
снятие товара с резерва
По всему видать — не правильно понял. Прошу прощения.
Это еще наложилось на мое разумение, что функция резервирования товара это таки функция учетной системы, но никак не портала… и рассуждение о резервировании в контексте принципа реализации личного кабинета досбило с толку.
>>1. Товар как раз резервируется при создании заказа.
Пользователь начал вводить заказ, отвлекся, забыл — заказ не дооформил, вспомнил по пути с работы, позвонил, оформил заказ по телефону. Или же пришел следующим утром, оформил новый заказ. Остатки по недооформленному заказу на три дня остались заморожены?
>>Дилер сможет резервировать товары в личном кабинете на сайте оптовой компании после того, как введет логин и пароль…
И что это дает? Как можно контролировать, что он не понарезервирует товара, а заказ так и не оформит? Ну вот будет бестолочь эдакая. Какие санкции ты можешь к нему применить? Отказаться от такого бестолкового покупателя?
Таки, мне кажется, куда разумнее резервировать остатки при утверждении(проведении) заказа, но никак не при его оформлении.
Резервировать остатки при оформлении можно лишь в случае, когда ты в состоянии контролировать пользователя, вводящего заказ, наказывать его за бестолковость. Например операционисту, недооформившего заказ продиктованный клиентом по телефону, можно длеать внушения, можно наказать рублем, уволить. А если делегировать функцию операциониста клиенту. Как ты его накажешь, чтоб себе не в наклад?
>>То есть обычно дилер звонит менеджеру и резервирует заказ
Именно что заказ. Ровно то, о чем я и говорил. Резервироваться товар должен именно что на основании заказа. Идея же предоставлять возможность резервировать запасы без оформления заказа, да еще и на публичном ресурсе… как то уж больно рискованно выглядит.
>>резервирование товара
Давать возможность внешнему контрагенту резервировать товар на вашем складе надо очень, очень, очень осторожно. Ретивые клиенты заморозят ваш товар себе впрок и вы останетесь без продаж. Лучше — вообще не давать. Резервироваться товар должен при проведении заказа, который, по факту, отражает уже намерение клиента приобрести товар, а не просто его желание.
Та статья интересна тем, что автор раскрыл карты — на каких данных, по каким показателям строятся прогнозы.
Здесь же сферический софт в вакууме, на сферических данных, по сферическим критериями, рисует сферические графики. Т.е. это выглядит скорее как описание внешней привлекательности волшенбной кнопки «сделать все зашибись». Тоска.
Я кажется понял, о чем вы недоумевали в предыдущем посте. B-tree — сбалансированное дерево. Т.е. все его листья расположены на одном уровне глубины. Получается они как бы и в дереве, но как бы и обособленно.
На иллюстрации автора, кстати, это не так. Page Y имеет большую глубину нежели Page 2. Но в контексте того, сколько я уже высказал собственных заблуждений в комментариях к этому топику, поостерегусь тут давать оценку еще и тут :D
Я полагаю физически упорядочены листья, не само дерево. Дерево используется для прямого доступа и доступа к первому значению при поиске по диапазону, дальше, при поиске по диапазону — последовательное сканирование листов.
Но мне все равно становится плохо при мысли, что данные физически упорядочиваются по ключу. Что если у нас ключ не монотонно растущий, а, например, — натуральный (номер паспорта, ИНН) или GUID, или составной, связанный с другими наборами данных, как, скажем, при реализации отношения многие-ко-многим… Добавление нового значения может повлечь за собой пересортировку чуть ли не всего набора данных. Если данные действительно физически упорядочены, пожалуй, используя этот движок, следует заведомо отказаться от использования естественных ключей в пользу суррогатных.
If the table has no PRIMARY KEY or suitable UNIQUE index, InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.
Тут подхрамывает мое знание английского. В последнем слове physically относится к orderd или к insertion order?
Наверное, это очень затратно при изменении индекса
Я так понял эти издержки пытаются минимизировать оставляя страницы недозаполненными…
Судя по всему вы действительно правы, а я — нет. Спасибо.
скажите, а где можно почитать про кросс-ссылки между нодами B-Tree?
Я это почерпнул из докуметнации по ораклу. Сейчас, погуглив по ключевому слову «B-tree», я что-то стал сомневаться, особенность ли это самой структуры или же это особенность ее реализации ораклом. Но, с другой стороны, если это не так — как организовывать поиск по диапазонам?
Спасибо за это замечание. B-tree таки не «двоичное дерево» (binary tree), я использовал не правильный термин. В структуре B-tree нода может иметь более двух дочерних, как и указано в статье.
В общем — тема интересная, важная. Но, увы, статья получилась не однозначная. Мне затруднительно оценить чего тут больше — введения в заблуждение или же разложения по полочкам.
Я бы упомянул это во первых. Упомянутое же вами во-первых и во-вторых, мне кажется, куда менее
Однако ж и это в-четвертых совсем же не так. Все индексы InnoDB имеют структуру двоичного дерева. И кластерные и не кластерные. А вы эту особенность приписываете только кластерным индексам. Кластерные и обычные индексы отличаются лишь т.н. «полезной нагрузкой». Кластерный индекс в качестве полезной нагрузки несет все поля таблицы, в то время, как обычный лишь значения кластерного индекса. В этом контексте преимущество кластерного индекса лишь в том, что отсутствует дополнительное чтение на вычитку не включенного в некластерный индекс значения.
Упорядоченность же индекса заключается в том, что все листья его двоичного дерева имеют кросс-ссылки на соседние листья. На вашей схеме это важное свойство опущено. Благодаря этой связанности оказывается возможным поиск по диапазонам (range). Т.е. отбор по предикату id > 10 сводится к поиску по дереву значения 10 и дальше, по связям листьев, отбираются все значения, которые больше 10.
Соответственно двоичного поиска, о котором вы упоминаете — здесь не существует. Есть поиск по двоичному дереву, суть совсем другое, хотя, чем то похоже — не спорю.
>>Возможность неблокирующей работы с очередью реализована через использование пользовательских переменных в UPDATE запросе с их последующей выборкой. Посвящать этому приему целую статью — глупо.
Нет уж простите. В этом ведь и весь самый-самый цимес. Как это вы умудряетесь захватывать задачи без блокировок? Неужели сразу же после захвата фиксируете транзакцию? Уборщица помыла полы в серверной, сессия срубилась, не завершенная задача не освободилась?
Тогда кпд, по идее надо бы сравнивать с [s]элиптической звездочкой[/s] овальной ведущей звездой.
Чтобы обеспечить согласованность результата на время выполнения запроса, если данные, которые попадают в выборку в это самое время меняются другой транзакцией.
>>И откуда у вас информация что MySQL
Всю жизнь считал что это так.
Однако ж, похоже, я очень заблуждался. >>>
Прям таки разрыв шаблона
Спасибо!
Сессию или транзакцию? Если транзакцию открывать явно то да, ясно. Я говорил о неявных транзакциях — тех, которые открываются не start transaction, а которые система сама система, для выполнения стайтмента, если транзакция явно не открыта. Или я бред говорю, и такого нет в MySQL?
В случае же с явными транзакциями тут тонкий вопрос. Транзакцию явно открывают вполне для определенных целях. Да, дотошный программист самостоятельно установит нужный ему уровень изоляции. Но может и забыть, и на старуху бывает… И если приложение протестировано в одном уровне изоляции, приложение прошло проверку временем, то смена уровня изоляции может оказаться очень черевата для таких явно открытых тразнакций. Такое решение требует тщательного тестирования, а тестирование конкурирующих процессов весьма не просто организоываать.
>>Вы можете легко проверить что ошибаетесь
К сожалению не могу, в ареоле моего обитания нет ни одного инстанса MySQL. Но тема мне очень интересна.
я ошибаюсь или MySQL — блокировочник? Он не накапливает данные, как это делают упомянутые Вами версионники оракл и постгр, он блокирует модификацю данных для получения согласованного результата. По этой причине и запись блокирует чтение и чтение блокирует запись. В оракле, постгре нет такого понятия как блокировки по чтению, они накапливают версии, скорее этим обуславливается преимущество этих СУБД, о котором вы упоминаете, нежели уровень изоляции транзакции по умолчанию. К слову, надо заметить, что ораклиный и постгровский read commited, за счет такой реализации, не в полной мере вписывается в стандарт ansi
Я ошибаюсь или действительно в MySQL открытая неявно транзакция закрывается сразу же после выполнения стейтмента? Если нет, то в чем разница блокировок, кинутых запросом в read commited и в repeatable read? Могу ошибаться, полагая, что стратегия блокирования на этих уровнях одинакова, разница лишь в том, что в read commited блокировки отпускаются сразу при завершении работы стейтмента, а в read commmited они отпускаются лишь при завершении транзакции. Если у нас транзакция закрывается сразу после выполнения запроса, разница, как бы, получается, не особо и проглядывается.
Было бы еще так же интересно почитать статьи «не ФС», «не Сборщик Мусора», «не Виртуализация», «не Веб». Определенно найдется не мало задач, где эти технологические компоненты не нужны, но используются.
Пробовали смотреть в сторону отложенных(deffered) ограничений целостности? Которые проверяются не при непосредственной вставки в таблицу, а при фиксации транзакции. Оракл — умеет. PG, слышал, — тоже. MS — низна
я так понял из
По всему видать — не правильно понял. Прошу прощения.
Это еще наложилось на мое разумение, что функция резервирования товара это таки функция учетной системы, но никак не портала… и рассуждение о резервировании в контексте принципа реализации личного кабинета досбило с толку.
Пользователь начал вводить заказ, отвлекся, забыл — заказ не дооформил, вспомнил по пути с работы, позвонил, оформил заказ по телефону. Или же пришел следующим утром, оформил новый заказ. Остатки по недооформленному заказу на три дня остались заморожены?
>>Дилер сможет резервировать товары в личном кабинете на сайте оптовой компании после того, как введет логин и пароль…
И что это дает? Как можно контролировать, что он не понарезервирует товара, а заказ так и не оформит? Ну вот будет бестолочь эдакая. Какие санкции ты можешь к нему применить? Отказаться от такого бестолкового покупателя?
Таки, мне кажется, куда разумнее резервировать остатки при утверждении(проведении) заказа, но никак не при его оформлении.
Резервировать остатки при оформлении можно лишь в случае, когда ты в состоянии контролировать пользователя, вводящего заказ, наказывать его за бестолковость. Например операционисту, недооформившего заказ продиктованный клиентом по телефону, можно длеать внушения, можно наказать рублем, уволить. А если делегировать функцию операциониста клиенту. Как ты его накажешь, чтоб себе не в наклад?
Именно что заказ. Ровно то, о чем я и говорил. Резервироваться товар должен именно что на основании заказа. Идея же предоставлять возможность резервировать запасы без оформления заказа, да еще и на публичном ресурсе… как то уж больно рискованно выглядит.
Давать возможность внешнему контрагенту резервировать товар на вашем складе надо очень, очень, очень осторожно. Ретивые клиенты заморозят ваш товар себе впрок и вы останетесь без продаж. Лучше — вообще не давать. Резервироваться товар должен при проведении заказа, который, по факту, отражает уже намерение клиента приобрести товар, а не просто его желание.
Здесь же сферический софт в вакууме, на сферических данных, по сферическим критериями, рисует сферические графики. Т.е. это выглядит скорее как описание внешней привлекательности волшенбной кнопки «сделать все зашибись». Тоска.
На иллюстрации автора, кстати, это не так. Page Y имеет большую глубину нежели Page 2. Но в контексте того, сколько я уже высказал собственных заблуждений в комментариях к этому топику, поостерегусь тут давать оценку еще и тут :D
Но мне все равно становится плохо при мысли, что данные физически упорядочиваются по ключу. Что если у нас ключ не монотонно растущий, а, например, — натуральный (номер паспорта, ИНН) или GUID, или составной, связанный с другими наборами данных, как, скажем, при реализации отношения многие-ко-многим… Добавление нового значения может повлечь за собой пересортировку чуть ли не всего набора данных. Если данные действительно физически упорядочены, пожалуй, используя этот движок, следует заведомо отказаться от использования естественных ключей в пользу суррогатных.
Имелось в виду в последнем предложении.
Тут подхрамывает мое знание английского. В последнем слове physically относится к orderd или к insertion order?
Я так понял эти издержки пытаются минимизировать оставляя страницы недозаполненными…
Судя по всему вы действительно правы, а я — нет. Спасибо.
Я это почерпнул из докуметнации по ораклу. Сейчас, погуглив по ключевому слову «B-tree», я что-то стал сомневаться, особенность ли это самой структуры или же это особенность ее реализации ораклом. Но, с другой стороны, если это не так — как организовывать поиск по диапазонам?
Я бы упомянул это во первых. Упомянутое же вами во-первых и во-вторых, мне кажется, куда менее
Однако ж и это в-четвертых совсем же не так. Все индексы InnoDB имеют структуру двоичного дерева. И кластерные и не кластерные. А вы эту особенность приписываете только кластерным индексам. Кластерные и обычные индексы отличаются лишь т.н. «полезной нагрузкой». Кластерный индекс в качестве полезной нагрузки несет все поля таблицы, в то время, как обычный лишь значения кластерного индекса. В этом контексте преимущество кластерного индекса лишь в том, что отсутствует дополнительное чтение на вычитку не включенного в некластерный индекс значения.
Упорядоченность же индекса заключается в том, что все листья его двоичного дерева имеют кросс-ссылки на соседние листья. На вашей схеме это важное свойство опущено. Благодаря этой связанности оказывается возможным поиск по диапазонам (range). Т.е. отбор по предикату id > 10 сводится к поиску по дереву значения 10 и дальше, по связям листьев, отбираются все значения, которые больше 10.
Соответственно двоичного поиска, о котором вы упоминаете — здесь не существует. Есть поиск по двоичному дереву, суть совсем другое, хотя, чем то похоже — не спорю.