Я бы не сказал что все так очевидно - есть набор железа на котором эта система работает "стабильно" (в кавычках т.к. полноценных тестов стабильности не видел, и железо очевидно не особо свежее), поэтому в случаях когда речь идет о каком-то конкретном приложении под windows, и работа вне этого приложения фактически не важна, то можно рассматривать вариант построения системы на конкретном железе. Это может быть актуально для ситуаций когда невозможно использовать что-то более опробированное вроде wine.
Крутая идея, у меня была проблема с драйвером wifi к ноуту, который шел без ОС. Пока разбираться увидел что актуально не только для меня - свежий модуль, производитель только под win сделал драйвера, я бы с огромным удовольствием присоединился к сбору средств на оплату спеца кто бы решил проблему (решения уже были, но требовали ручной сборки/установки, т.е. кажется что-то требовалось аккуратно собрать и допилить то что уже было исследовано и как минимум работоспособно), но подходящей площадки для такого сбора средств я не знаю :(
Для пользователя все выглядит штатно. Но на промежуточном узле весь трафик может быть прочитан: логины, пароли, переписки, финансовая информация.
Кажется вы сами скрываете одну важную деталь: я точно сам видел сообщения от браузера в духе "раньше вы ходили на этот сайт и он имел другой сертификат" - т.е. если вам по вашему обычному запросу, например, к gmail, вернут адрес какого-то "промежуточного" сервера то современные браузеры обратят на это внимание. Это конечно не значит что не может сложиться так что вы вот только что переустановили браузер, пошли в первый раз на почту, а все вот только и ждали когда же вы переустановите браузер и давай вам "промежуточный" сервер вместо целевого подсовывать, но вот почему вы заявили о том что хотите "собрать полное техническое досье и разобраться", и умолчали об этой вот детали, заставляет задуматься о ваших истинных целях.
Видимо ваше предположение строиться на том, что вы предполагаете что высоконагруженные системы строяться только на MS SQL (т.к. дедлоки в контексте работы с партициями обсуждались только для этой СУБД). Кажется не самое обоснованное предположение. Или у вас есть данные по другим СУБД? (Postgresql? Oracle?)
Кажется что при архивировании данных в архив должен отправляться консистентный срез из всех зависимых таблиц (кроме справочников, но для них идея удаления обычно крайне спорная), а не просто кусок какой-то таблицы (иначе непонятно что с таким архивом делать). В чем проблема перенести сразу все зависимые данные в архив? В том что при пректировании забыли (или не знали) про настройки отложенной до коммита проверки консистентности? Кажется это не проблема FK.
Незнаю насчет MS SQL, но рискну предположить (коль скоро это всетаки production-ready система), дедлоки появляются не от FK, а от того как эти FK конкретный разработчик спроектировал, иначе у вас классическое "ложки делают людей толстыми".
А можете развернуть мысль про проблемы с FK при партиционировании? Если дело в необходимости уникального индекса, то кажется в ряде СУБД (например Oracle, Postgresql Pro) присуствует возможность строить индексы уникальные внутри таблицы даже в случае если таблица партиционированная
Это было бы логичнее, и куда как более ожидаемо, чем, например:
И по моему скромному мнению именно окружение Горбачева, и он сам - сильнее прочих выбили опору развития страны и, опять же по моему мнению, уже после него вопрос краха страны и утраты информационного доминирования был лишь вопросом времени.
На то что такие вот перлы выглядят несоответствующими теме статьи я и указал
Кажется тут вообще весь текст для того чтобы какие-то свои мутные рассуждения на отвлеченные от темы статьи материи подсовывать под соусом объяснений что-как работает
Или вы спрашиваете про физическое хранилище данных? там до вакуума - три.
Именно, их там 3(не обязательно до ваккуума - зависит от горизонта транзакций и возможности внутристраничной очистки), и они выглядят там так:
неизменявшаяся строчка, xmin=1, xmax=0
старая версия строчки, xmin=1, xmax=2
новая версия строчки, xmin=2, xmax=0
Теперь смотрим на колонку в returning: xmax=0 as inserted. Какие из трех строчек дадут true в эту колонку? Кажется только старая версия строчки. Если так то это значит что остальные значения в колонках у записи имеющей inserted=true будут старые, до обновления (новые лежат в новой версии). Я где-то не прав?
1) я запустил ваш код из примера (поменял название колонки с name на first_name) и получил:
у меня пустая таблица, но мне сказали что я не вставляю а обновляю - кажется что-то уже идёт не так.
2) Если вы понимаете как работает MVCC подскажите пожалуйста, если у меня в таблице в Postgresql было 2 строки, я обновил одну из них (поменял значение в одной из колонок на другое допустимое), сколько после этого строчек в таблице?
Postgres работает как MVCC, у него внутри при редактировании всегда происходит закрытие старой строки простановкой xmax=номер_текущей_транзакции, и добавление новой строки с актуальными значениями и xmin=номер_текущей_транзакции, xmax=0.
Отсюда вывод, если вы ожидаете в ответе по своему запросу строку у которой xmin !=0, то это должна быть старая версия строки, до редактирования.
xmax — особый системный столбец PostgreSQL. Если строка вставлена без предшествующего удаления, то xmax равен 0. При обновлении старый вариант строки удаляется (с новым xmin) и xmax старой версии получает непустое значение.
Если у вас была строка, у нее было xmin=100, xmax=0, вы ее обновили, у этой строки стало xmin=100, xmax=101, добавилась строка с xmin=101, xmax=0
Если вы просто выставили строку, то у вас в таблице появилась строка xmin=101, xmax=0
Ваша чудо-магия работает (если работает - я не проверял) на том что в случае обновления вам возвращают старую строку, только в ней xmax может быть !=0, а в таком случае и значения колонок в возвращаемой строке будут до обновления, вы уверены что все к этому готовы? В вашем объяснении я не нашел указания на это.
Если те эльбрусы были с тем же подходом к системе команд реализованы, что и нынешние, то скорее всего ситуация говорит о том, что у вашего знакомого просто не было хорошего компилятора (или хороших разработчиков) - в VLIW оптимизации на стороне компилятора (или разработчиков), если их до этапа исполнения не было - увы, работать будет так себе
Но как тогда интерпретировать все эти циферки в сравнительной таблице? Вот, допустим, если я сделал процессор, который 2+2 вычсиляет 1_000_000_000_000_000 раз за 1 секунду, но другие операции вообще не выполняет - его можно будет добавить к перечисленным в таблице и указать в колонке "Производительность на процессор" производительность по операции 2+2 ?
А я не ошибусь, если скажу что выдающиеся характеристики отчасти так выглядят из-за того, что процесс оптимизации исполнения кода был переложен с процессора на компилятор? т.е. что сравнение для честности должно учитывать систему команд сравниваемых экземпляров?
Знаю этот нюанс про современные Эльбрусы, но не знаю, относится ли это к тем которые в статье
Я бы не сказал что все так очевидно - есть набор железа на котором эта система работает "стабильно" (в кавычках т.к. полноценных тестов стабильности не видел, и железо очевидно не особо свежее), поэтому в случаях когда речь идет о каком-то конкретном приложении под windows, и работа вне этого приложения фактически не важна, то можно рассматривать вариант построения системы на конкретном железе. Это может быть актуально для ситуаций когда невозможно использовать что-то более опробированное вроде wine.
Вы наверное имеете ввиду релизов с номером >= 1, с таким уточнением да, без него утверждение не верно.
В любом случае года 4 назад видел ее на чем-то вроде кассового терминала в несетевом магазине (на одной закрытой кассе был рабочий стол запущен)
Вы верно мыслите, но в неверном направлении - нужно развивать парусный флот :)
Вы так уверенно говорите о причинах, как будто сам бумагу подписывали, "Улицы не чистить, дабы..."
Крутая идея, у меня была проблема с драйвером wifi к ноуту, который шел без ОС. Пока разбираться увидел что актуально не только для меня - свежий модуль, производитель только под win сделал драйвера, я бы с огромным удовольствием присоединился к сбору средств на оплату спеца кто бы решил проблему (решения уже были, но требовали ручной сборки/установки, т.е. кажется что-то требовалось аккуратно собрать и допилить то что уже было исследовано и как минимум работоспособно), но подходящей площадки для такого сбора средств я не знаю :(
Кажется вы сами скрываете одну важную деталь: я точно сам видел сообщения от браузера в духе "раньше вы ходили на этот сайт и он имел другой сертификат" - т.е. если вам по вашему обычному запросу, например, к gmail, вернут адрес какого-то "промежуточного" сервера то современные браузеры обратят на это внимание. Это конечно не значит что не может сложиться так что вы вот только что переустановили браузер, пошли в первый раз на почту, а все вот только и ждали когда же вы переустановите браузер и давай вам "промежуточный" сервер вместо целевого подсовывать, но вот почему вы заявили о том что хотите "собрать полное техническое досье и разобраться", и умолчали об этой вот детали, заставляет задуматься о ваших истинных целях.
Видимо ваше предположение строиться на том, что вы предполагаете что высоконагруженные системы строяться только на MS SQL (т.к. дедлоки в контексте работы с партициями обсуждались только для этой СУБД). Кажется не самое обоснованное предположение. Или у вас есть данные по другим СУБД? (Postgresql? Oracle?)
Кажется что при архивировании данных в архив должен отправляться консистентный срез из всех зависимых таблиц (кроме справочников, но для них идея удаления обычно крайне спорная), а не просто кусок какой-то таблицы (иначе непонятно что с таким архивом делать). В чем проблема перенести сразу все зависимые данные в архив? В том что при пректировании забыли (или не знали) про настройки отложенной до коммита проверки консистентности? Кажется это не проблема FK.
Незнаю насчет MS SQL, но рискну предположить (коль скоро это всетаки production-ready система), дедлоки появляются не от FK, а от того как эти FK конкретный разработчик спроектировал, иначе у вас классическое "ложки делают людей толстыми".
А можете развернуть мысль про проблемы с FK при партиционировании? Если дело в необходимости уникального индекса, то кажется в ряде СУБД (например Oracle, Postgresql Pro) присуствует возможность строить индексы уникальные внутри таблицы даже в случае если таблица партиционированная
Это было бы логичнее, и куда как более ожидаемо, чем, например:
На то что такие вот перлы выглядят несоответствующими теме статьи я и указал
Кажется тут вообще весь текст для того чтобы какие-то свои мутные рассуждения на отвлеченные от темы статьи материи подсовывать под соусом объяснений что-как работает
Именно, их там 3(не обязательно до ваккуума - зависит от горизонта транзакций и возможности внутристраничной очистки), и они выглядят там так:
неизменявшаяся строчка, xmin=1, xmax=0
старая версия строчки, xmin=1, xmax=2
новая версия строчки, xmin=2, xmax=0
Теперь смотрим на колонку в returning: xmax=0 as inserted. Какие из трех строчек дадут true в эту колонку? Кажется только старая версия строчки. Если так то это значит что остальные значения в колонках у записи имеющей inserted=true будут старые, до обновления (новые лежат в новой версии). Я где-то не прав?
Ок, давайте по порядку:
1) я запустил ваш код из примера (поменял название колонки с name на first_name) и получил:
у меня пустая таблица, но мне сказали что я не вставляю а обновляю - кажется что-то уже идёт не так.
2) Если вы понимаете как работает MVCC подскажите пожалуйста, если у меня в таблице в Postgresql было 2 строки, я обновил одну из них (поменял значение в одной из колонок на другое допустимое), сколько после этого строчек в таблице?
Что вы имеете ввиду под "обработать дважды"?
Postgres работает как MVCC, у него внутри при редактировании всегда происходит закрытие старой строки простановкой xmax=номер_текущей_транзакции, и добавление новой строки с актуальными значениями и xmin=номер_текущей_транзакции, xmax=0.
Отсюда вывод, если вы ожидаете в ответе по своему запросу строку у которой xmin !=0, то это должна быть старая версия строки, до редактирования.
Где-то в моих рассуждениях ошибка?
А это точно будет один раз посчитано? Или штук 100 таких объявлений на странице будет давать рандомные микрофризы при попытках пересчитать?
Если у вас была строка, у нее было xmin=100, xmax=0, вы ее обновили, у этой строки стало xmin=100, xmax=101, добавилась строка с xmin=101, xmax=0
Если вы просто выставили строку, то у вас в таблице появилась строка xmin=101, xmax=0
Ваша чудо-магия работает (если работает - я не проверял) на том что в случае обновления вам возвращают старую строку, только в ней xmax может быть !=0, а в таком случае и значения колонок в возвращаемой строке будут до обновления, вы уверены что все к этому готовы? В вашем объяснении я не нашел указания на это.
Если те эльбрусы были с тем же подходом к системе команд реализованы, что и нынешние, то скорее всего ситуация говорит о том, что у вашего знакомого просто не было хорошего компилятора (или хороших разработчиков) - в VLIW оптимизации на стороне компилятора (или разработчиков), если их до этапа исполнения не было - увы, работать будет так себе
Но как тогда интерпретировать все эти циферки в сравнительной таблице? Вот, допустим, если я сделал процессор, который 2+2 вычсиляет 1_000_000_000_000_000 раз за 1 секунду, но другие операции вообще не выполняет - его можно будет добавить к перечисленным в таблице и указать в колонке "Производительность на процессор" производительность по операции 2+2 ?
А я не ошибусь, если скажу что выдающиеся характеристики отчасти так выглядят из-за того, что процесс оптимизации исполнения кода был переложен с процессора на компилятор? т.е. что сравнение для честности должно учитывать систему команд сравниваемых экземпляров?
Знаю этот нюанс про современные Эльбрусы, но не знаю, относится ли это к тем которые в статье