Добавлю 5 копеек. Вот тут над головами взлетают/садятся самолёты. На практике, если жить неделю в году в отеле, всё не так плохо. Но квартиру я бы там покупать не стал
Потому что целью всего этого упахивания были, соответственно, пятёрки, золотая медаль и красный диплом.
Ну в её защиту можно сказать, что условно до 21 года со всех сторон тебе буквально все - и родители, и вуз - говорят, что пятёрки = счастливое будущее. Про то, что неплохо было бы заниматься нетворкингом вместо пятёрок до меня лично начало доходить только к пятому курсу. А до кого-то так и не дошло.
да, тут "идеальное" надо было взять в кавычки - по сути, даже с такими ограничениями положительный остаток не гарантировался. А с развитием платформы параллельность работы выросла, проявились классические артефакты многопользовательской работы - и появились классические же способы борьбы с ними (блокировки, проверки остатков в конце транзакции), которыми можно пользоваться, а можно и не пользоваться, если в конкретной ситуации не надо
Это спасёт от отрицательного остатка "в конце баланса", но не поможет от минусов "в моменте": если будет 3 транзакции
+100
+400
+500
,а потом задним числом вторая транзакция поменяется на -400
мы получим отрицательный остаток после 2 действия, но положительный - на финальном итоге
Это лечится запретом изменения документов - все исправления делаются новым корректирующим документом (такое есть в ЗУП). Всё это реализуемо языком платформы - и тут совершенно не нужен предлагаемый автором "неотрицательный остаток"
Идеальное решение отрицательных остатков предлагала преснопамятная 1С 7.7 - там просто все транзакции работали в SERIALIZABLE и параллельно два раза что-то зарезервировать было невозможно. К счастью, 1С 8.х действительно стала многопользовательской, а это значит, что теоретически возможны и списания "в минус". А дальше уже в зависимости от ситуации программист должен что-то с этим делать - либо проверять остатки до и после транзакции, либо добавлять регламентную постобработку, либо просто ничего не делать (посмотрите, как работает ритейл или WMS - если товар лежит перед кассиром/кладовщиком, значит он должен его отдать, даже если программа считает, что на остатке его нет). max(остаток, 0) - частное и вредное решение, плодящее плохие паттерны проектирования
Встроенный метод распределения... а по каким критериям он будет распределять? Надо ли учитывать гипотетическое измерение "серия номенклатуры"? А если учёт по сериям не ведётся? А если списывать нужно по FIFO в привязке к партиеобразующему документу, ссылка на который лежит внутри "серии"? Эти все условия тоже нужно передавать в некий магический метод распределения? И потом гадать, как этот черный ящик, встроенный в платформу, получил нужные цифры? Нет, увольте, пусть лучше это будет написано кодом, доступным для отладки
При использовании такого метода надо учитывать, что 1С (по крайней мере при работе с MS SQL Server, в PG не изучал) переиспользует временные таблицы - со всей накопившейся структурой метаданных
С SQL Server у меня как-то был интересный случай. При помощи черной магии добавили создание колоночного (columnstore) индекса по временной таблице, участвовавшей в расчёте себестоимости. Первая итерация отрабатывала успешно, но потом начинались проблемы - построчное заполнение таблицы с columnstore-индексом начинает чудовищно тормозить, съедается весь эффект от оптимизации. Более того, из-за того, что таблица была очень простая (одна колонка со ссылками), она переиспользовалась и в других похожих запросах из той же сессии (например, при передаче массива в качестве параметра). Очень быстро все такие таблицы оказывались с columnstore-индексами, что практически парализовывало работу сессии. Вылечилось явным удалением columnstore-индекса после выполнения нужного запроса.
Я это рассказываю не для того, чтобы отвадить читателей от механики из статьи. Просто надо учитывать, что индексы могут "расползтись" и по другим запросам из сессии - не удивляйтесь, если увидите их при отладке там, где их не должно было быть.
Другими словами: "для меня RPO в 2 минуты - это допустимый сценарий" (и ещё раз: а что по этому поводу думает бизнес?)
В PG, судя по описанию, механизм работает аналогично (оно и понятно, идея-то простая). Поэтому первоначальный вопрос должен стоять так же: могу ли я (и бизнес!) позволить себе безвозвратную потерю нескольких последних минут работы пользователей? А дальше уже - детали реализации.
DD в SQL Server увеличивает риски в сценарии "выдернули вилку из розетки". И только. В классическом варианте закоммиченные транзакции сразу попадают на диск (в лог транзакций) и если серсис СУБД резко остановится, их можно будет восстановить по логу. В случае DD есть риск, что транзакции не попадут в лог и будут утеряны навсегда
По сути, тут идёт размен RPO на скорость параллельной работы пользователей. По моему опыту, в OLTP чаще выбирали RPO, но кто-то может позволить себе повысить риски за счёт общего ускорения. В любом случае, это нужно обсуждать с бизнесом
В доке от МС написано, что при DD транзакции помещаются в буфер в оперативке, а на диск попадают при заполнении буфера, либо, как было указано, при ручном sp_flush_log.
В вашем сценарии обе транзакции попадут в этот буфер - и я сомневаюсь, что если закоммитится транзакция 2, то транзакция 1 пропадёт. Всё-таки содержимое буфера (с обеими транзакциями) будет записываться на диск целиком.
Мне понравилось, что Юпитер - это такой гибрид редактора кода и консоли. После каждой ячейки есть свой вывод, он не теряется. Если делаешь какое-то исследование и нужно перед глазами иметь вывод сразу нескольких шагов - очень удобно.
Я за это же купил DataGrip, он умеет с SQL работать по такому же принципу
Ну вообще-то у нас такое есть - я в рамках своих обязанностей косвенно вижу заказы, которые комплектуются товаром из других магазинов. Если есть пример, когда что-то не хотят везти - напишите в личку, я передам куда следует)
я не настоящий сатанист, я больше аналитик) Но вообще тут вместо "DS" можно было любые слова подставить - преимущество в том, мне сейчас интересно конкретно это
да, тут правда больше "в сторону". Но на каждом таком шаге я не мог формально подтвердить существующий грейд, так что и на полшага вниз тоже получалось
Но многие боятся даже так "в сторону" шагать, боясь потерять текущий уровень дохода и комфорта. Так что статья про то, что это не страшно - так тоже можно делать)
Я отвечу, чтобы не удавалось заболтать кого-нибудь другого
"Данное НКО" работает, чтобы людей не пытали в отделах полиции и соблюдали банальные законные права при задержании. И мне странно слышать, что страна может развалиться от того, что полиция просто начнёт выполнять законы.
А вы, простите, видели результаты работы НКО, которую критикуете?
ОВД-Инфо существует не для того, чтобы "завалить путина". А для того, чтобы не было полицейского беспредела. Они одинаково помогают и навальнистам, и лимоновцам, и недовольным незаконной свалкой - вообще всем, кого задерживают за высказывание своего мнения, независимо от взглядов.
У ребят очень простые и понятные инструкции, которые успокаивают и помогают понять, что делать дальше и как себя вести. Если у вас есть пример, где ОВД-Инфо "не разбирается" в проблеме - буду рад его увидеть, потому что мой опыт показывает ровно обратное.
То есть, 1С с одной стороны давно всех убеждает, что создаёт настоящие Enterprise-решения. И потом эта же 1С допускает остановку платформы из-за false positive проверки на пиратство.
Вот как они вообще это обсуждали? "А давайте сделаем такую систему, что если нам что-то покажется, то остановится 1С на целом заводе! Круто же будет!" Как после этого им доверять автоматизацию бизнеса крупнее киоска?
простите, а сейчас вы часто "думаете о разделителе", когда пишете запросы в 1С?
Проблема ведь ровно в обратном: программист часто вообще не задумывается, что разделитель есть. Потому что в дереве конкретного объекта метаданных (документа, справочника) его не видно. В условие запроса он добавляется платформой автоматически.
Если сделать как вы предлагаете и при этом не выполнять реструктуризацию, уверен, вас ждёт неприятный сюрприз: платформа добавит разделитель в текст запроса, а т.к. вы предлагаете убрать его и из ключа кластерного индекса, СУБД придётся делать key lookup, чтобы достать нужное значение
Что-то мне кажется, разница во времени объясняется банальным кэшированием - после первого запроса создания нового индекса его данные остались в оперативке. Число строк, выбираемых из обоих индексов одинаковое, а сами индексы по объёму почти не отличаются - чудес быть не должно. Можно дополнительно проверить, включив set statistics io on - число чтений скорее всего в обоих прогонах будет одинаковым.
Но вопрос, конечно, был в другом. И выбор второго индекса для меня, если честно, неожиданный - по всем формальным признакам он должен постоять "в стороне".
Подробнее про оптимизатор можно почитать у Дмитрия Пилюгина http://www.queryprocessor.ru/optimizer_unleashed_1/ . Он очень глубоко разбирается в механике работы QP. Какие-то знания, наверняка устарели, но в статье по ссылке - подробный разбор этапов формирования плана. Если включить специальные флаги трассировки (у него всё указано), можно посмотреть, какие варианты оцениваются и понять, почему "побеждает" итоговый план.
Добавлю 5 копеек. Вот тут над головами взлетают/садятся самолёты. На практике, если жить неделю в году в отеле, всё не так плохо. Но квартиру я бы там покупать не стал
У Sony есть Wena. Но, к сожалению, только в японии. https://www.ixbt.com/news/2020/10/02/sony-sony-wena-3.html
Ну в её защиту можно сказать, что условно до 21 года со всех сторон тебе буквально все - и родители, и вуз - говорят, что пятёрки = счастливое будущее. Про то, что неплохо было бы заниматься нетворкингом вместо пятёрок до меня лично начало доходить только к пятому курсу. А до кого-то так и не дошло.
да, тут "идеальное" надо было взять в кавычки - по сути, даже с такими ограничениями положительный остаток не гарантировался. А с развитием платформы параллельность работы выросла, проявились классические артефакты многопользовательской работы - и появились классические же способы борьбы с ними (блокировки, проверки остатков в конце транзакции), которыми можно пользоваться, а можно и не пользоваться, если в конкретной ситуации не надо
Это спасёт от отрицательного остатка "в конце баланса", но не поможет от минусов "в моменте": если будет 3 транзакции
+100
+400
+500
,а потом задним числом вторая транзакция поменяется на -400
мы получим отрицательный остаток после 2 действия, но положительный - на финальном итоге
Это лечится запретом изменения документов - все исправления делаются новым корректирующим документом (такое есть в ЗУП). Всё это реализуемо языком платформы - и тут совершенно не нужен предлагаемый автором "неотрицательный остаток"
Какие-то странные решения выдуманных проблем.
Идеальное решение отрицательных остатков предлагала преснопамятная 1С 7.7 - там просто все транзакции работали в SERIALIZABLE и параллельно два раза что-то зарезервировать было невозможно. К счастью, 1С 8.х действительно стала многопользовательской, а это значит, что теоретически возможны и списания "в минус". А дальше уже в зависимости от ситуации программист должен что-то с этим делать - либо проверять остатки до и после транзакции, либо добавлять регламентную постобработку, либо просто ничего не делать (посмотрите, как работает ритейл или WMS - если товар лежит перед кассиром/кладовщиком, значит он должен его отдать, даже если программа считает, что на остатке его нет). max(остаток, 0) - частное и вредное решение, плодящее плохие паттерны проектирования
Встроенный метод распределения... а по каким критериям он будет распределять? Надо ли учитывать гипотетическое измерение "серия номенклатуры"? А если учёт по сериям не ведётся? А если списывать нужно по FIFO в привязке к партиеобразующему документу, ссылка на который лежит внутри "серии"? Эти все условия тоже нужно передавать в некий магический метод распределения? И потом гадать, как этот черный ящик, встроенный в платформу, получил нужные цифры? Нет, увольте, пусть лучше это будет написано кодом, доступным для отладки
При использовании такого метода надо учитывать, что 1С (по крайней мере при работе с MS SQL Server, в PG не изучал) переиспользует временные таблицы - со всей накопившейся структурой метаданных
С SQL Server у меня как-то был интересный случай. При помощи черной магии добавили создание колоночного (columnstore) индекса по временной таблице, участвовавшей в расчёте себестоимости. Первая итерация отрабатывала успешно, но потом начинались проблемы - построчное заполнение таблицы с columnstore-индексом начинает чудовищно тормозить, съедается весь эффект от оптимизации. Более того, из-за того, что таблица была очень простая (одна колонка со ссылками), она переиспользовалась и в других похожих запросах из той же сессии (например, при передаче массива в качестве параметра). Очень быстро все такие таблицы оказывались с columnstore-индексами, что практически парализовывало работу сессии. Вылечилось явным удалением columnstore-индекса после выполнения нужного запроса.
Я это рассказываю не для того, чтобы отвадить читателей от механики из статьи. Просто надо учитывать, что индексы могут "расползтись" и по другим запросам из сессии - не удивляйтесь, если увидите их при отладке там, где их не должно было быть.
Конкурс: думаю, это 2 абзаца с описанием аукциона (" Такой формат аукциона... " и далее)
Другими словами: "для меня RPO в 2 минуты - это допустимый сценарий" (и ещё раз: а что по этому поводу думает бизнес?)
В PG, судя по описанию, механизм работает аналогично (оно и понятно, идея-то простая). Поэтому первоначальный вопрос должен стоять так же: могу ли я (и бизнес!) позволить себе безвозвратную потерю нескольких последних минут работы пользователей? А дальше уже - детали реализации.
DD в SQL Server увеличивает риски в сценарии "выдернули вилку из розетки". И только. В классическом варианте закоммиченные транзакции сразу попадают на диск (в лог транзакций) и если серсис СУБД резко остановится, их можно будет восстановить по логу. В случае DD есть риск, что транзакции не попадут в лог и будут утеряны навсегда
По сути, тут идёт размен RPO на скорость параллельной работы пользователей. По моему опыту, в OLTP чаще выбирали RPO, но кто-то может позволить себе повысить риски за счёт общего ускорения. В любом случае, это нужно обсуждать с бизнесом
В доке от МС написано, что при DD транзакции помещаются в буфер в оперативке, а на диск попадают при заполнении буфера, либо, как было указано, при ручном sp_flush_log.
В вашем сценарии обе транзакции попадут в этот буфер - и я сомневаюсь, что если закоммитится транзакция 2, то транзакция 1 пропадёт. Всё-таки содержимое буфера (с обеими транзакциями) будет записываться на диск целиком.
Мне понравилось, что Юпитер - это такой гибрид редактора кода и консоли. После каждой ячейки есть свой вывод, он не теряется. Если делаешь какое-то исследование и нужно перед глазами иметь вывод сразу нескольких шагов - очень удобно.
Я за это же купил DataGrip, он умеет с SQL работать по такому же принципу
Ну вообще-то у нас такое есть - я в рамках своих обязанностей косвенно вижу заказы, которые комплектуются товаром из других магазинов. Если есть пример, когда что-то не хотят везти - напишите в личку, я передам куда следует)
я не настоящий сатанист, я больше аналитик) Но вообще тут вместо "DS" можно было любые слова подставить - преимущество в том, мне сейчас интересно конкретно это
да, тут правда больше "в сторону". Но на каждом таком шаге я не мог формально подтвердить существующий грейд, так что и на полшага вниз тоже получалось
Но многие боятся даже так "в сторону" шагать, боясь потерять текущий уровень дохода и комфорта. Так что статья про то, что это не страшно - так тоже можно делать)
Я отвечу, чтобы не удавалось заболтать кого-нибудь другого
"Данное НКО" работает, чтобы людей не пытали в отделах полиции и соблюдали банальные законные права при задержании. И мне странно слышать, что страна может развалиться от того, что полиция просто начнёт выполнять законы.
А вы, простите, видели результаты работы НКО, которую критикуете?
ОВД-Инфо существует не для того, чтобы "завалить путина". А для того, чтобы не было полицейского беспредела. Они одинаково помогают и навальнистам, и лимоновцам, и недовольным незаконной свалкой - вообще всем, кого задерживают за высказывание своего мнения, независимо от взглядов.
У ребят очень простые и понятные инструкции, которые успокаивают и помогают понять, что делать дальше и как себя вести. Если у вас есть пример, где ОВД-Инфо "не разбирается" в проблеме - буду рад его увидеть, потому что мой опыт показывает ровно обратное.
То есть, 1С с одной стороны давно всех убеждает, что создаёт настоящие Enterprise-решения. И потом эта же 1С допускает остановку платформы из-за false positive проверки на пиратство.
Вот как они вообще это обсуждали? "А давайте сделаем такую систему, что если нам что-то покажется, то остановится 1С на целом заводе! Круто же будет!" Как после этого им доверять автоматизацию бизнеса крупнее киоска?
простите, а сейчас вы часто "думаете о разделителе", когда пишете запросы в 1С?
Проблема ведь ровно в обратном: программист часто вообще не задумывается, что разделитель есть. Потому что в дереве конкретного объекта метаданных (документа, справочника) его не видно. В условие запроса он добавляется платформой автоматически.
Если сделать как вы предлагаете и при этом не выполнять реструктуризацию, уверен, вас ждёт неприятный сюрприз: платформа добавит разделитель в текст запроса, а т.к. вы предлагаете убрать его и из ключа кластерного индекса, СУБД придётся делать key lookup, чтобы достать нужное значение
Что-то мне кажется, разница во времени объясняется банальным кэшированием - после
первого запросасоздания нового индекса его данные остались в оперативке. Число строк, выбираемых из обоих индексов одинаковое, а сами индексы по объёму почти не отличаются - чудес быть не должно. Можно дополнительно проверить, включивset statistics io on- число чтений скорее всего в обоих прогонах будет одинаковым.Но вопрос, конечно, был в другом. И выбор второго индекса для меня, если честно, неожиданный - по всем формальным признакам он должен постоять "в стороне".
Подробнее про оптимизатор можно почитать у Дмитрия Пилюгина http://www.queryprocessor.ru/optimizer_unleashed_1/ . Он очень глубоко разбирается в механике работы QP. Какие-то знания, наверняка устарели, но в статье по ссылке - подробный разбор этапов формирования плана. Если включить специальные флаги трассировки (у него всё указано), можно посмотреть, какие варианты оцениваются и понять, почему "побеждает" итоговый план.