Спасибо, так понятнее. Просто из статьи сложилось впечатление, будто shared storage - это главное лекарство от всех проблем, а распределённые join и агрегирования как будто за скобками остались.
В статье много раз упоминается "общий storage", но я не увидел ни слова про "общую RAM" - только (обоснованные) причитания про " трудные вопросы с распределенными JOIN«ами " . Простите, а как ваш горизонтальный кластер решает эти трудные вопросы? Oracle для этого придумал RDMA, а тут я вижу гораздо более простую схему с координатором а-ля ClickHouse. Чем это принципиально лучше аппаратного шардирования, которое вы почему-то называете тупиковым?
А кто пальцем будет тыкать? Бизнес сам будет следить? Увольте - у них своих бизнесовых дел хватает, надо деньги зарабатывать. Вы пишете, что все отделы внедрения должны строевым шагом отправиться в сад. А я вижу так, что у аналитиков и архитекторов наоборот работы прибавится, потому что итерации ускорятся. То, что хотелки будут реализовываться быстрее не отменяет работы по планированию и выстраиванию бизнес-процессов
Агент не тупит. Ему не надо объяснять, что такое «просрочен на три дня»
ха-ха-ха. А потом выясняется, что промпт-инженер считал просрочку от последнего шага, а заказчик - от начала процесса. А писателя ТЗ, который бы это заметил нет - всех выгнали и заменили Клодом
Ну или вот так: "Да, ты совершенно прав, на этапе "отправь финансовый отчёт всем ответственным" не надо отправлять его нашему кладовщику. Я исправлю это со следующим отчётом". Причём в этой ситуации не надо придумывать никакой физики - тут просто неверное понимание умолчаний.
В общем, согласен, ИИ всех победил, пойду искать простыню и искать направление к кладбищу.
Немного в сторону от статьи. Когда слова "такси" и "postgres" оказываются рядом, сразу вспоминается неудачная попытка Uber переехать на PG (https://habr.com/en/companies/slurm/articles/322624/) Навскидку, больнее всего стрельнул update amplification в связке с частыми обновлениями координат и репликацией. Наверняка в начале проекта вы знали про эту историю - почему в итоге выбрали PG, а не, например YDB?
Хороший проект, но не увидел в описании: есть ли возможность проверить снятый бэкап? Например, автоматом восстановить его на отдельной машине, затерев предыдущую версию.
две таблицы рядом не просто частое, а просто напросто нормальное являение.
а как вы тогда боретесь с тем, что фильтр по одной таблице скрывает строки целиком, затрагивая строки и в другой таблице, выведенной рядом (а также диаграммы и вообще всё любое, чему непосчастливилось оказаться на отфильтрованной строке) ?
Помнится, в каком-то чемпионате (чуть ли не в F1) в какой-то момент внедряли буквально "пылесосы" - практически такие же, как заявлены в патенте. Пару раз машину срывало, когда пылесос ломался в самый неподходящий момент. После этого систему запретили
Как всегда, на любой вопрос существует простое, всем очевидное, неправильное решение
Можно показать время последнего апдейта витрины. Но что если витрина собирается из нескольких потоков? Один обновляется раз в час, другой - раз в три часа? А если кому-то из аналитиков интересен только "быстрый" поток и ему не важно, что "медленный" сегодня упал - он всё равно в него не смотрит?
Тут архитектор обычно закатывает глаза и вспоминает про согласованный SLA. А кто-то действительно прокидывает даты обновления по потокам - всё от потребности зависит. И я не вижу тут никакого криминала
у нас no-code успешно работает: бизнес-аналитикам подготовили заранее спроектированные data source и они отлично теперь рисуют в BI нужные отчёты. Если бы их заставили вместо этого кодить в SQL и Python - я представляю какой бы стоял вой (без осуждения)
Да, это не панацея. Какие-то сложные штуки всё равно программируются на JS + SQL. Но, по ощущениям, процентов 80 отчётов ушли как раз в сторону no-code
Интересно. Но это всё-таки больше альтернатива Dash, чем замена Tableau.
Мне кажется, главная заслуга любого no-code - именно в том, что он скрывает "страшный-ужасный" код от глаз бизнес-аналитиков. Да, по сути, они набрасывают мышкой тот же SELECT, но визуально это более дружелюбно. Я не раз видел, как, например, люди впадают в ступор от упоминания оконных функций - но легко пользуются их аналогами из визуальных BI
в работе MERGE есть баги, некоторые из них не будут исправлены
для борьбы с race condition могут потребоваться избыточные блокировки (это указано в статье)
MERGE неочевидно работает с триггерами. Если на таблице есть триггеры, лучше дополнительно протестировать поведение MERGE
Статья интересная и такое применение лаконичнее, чем расписывать каждую команду по отдельности и для каждой ловить свой Output. Но надо помнить, что MERGE в MS SQL Server - не самая эффективная конструкция
Одно время у меня был её проводной аналог - Wired Keyboard 600.Очень нравилась, даже на работу себе такую же купил
В какой-то момент решил "проапгрейдитсья" до беспроводной (у них же даже габариты совпадают) Какое же это было разочарование! Из-за того, что какой-то злой гений решил убрать все отступы межу клавишами F-блока , основной клавиатурой, стрелками и нумпадом - я просто перестал попадать по нужным клавишам (особенно по F-кам). Для меня тогда это было критично, я помучился полгода и потом просто подарил её кому-то из друзей
VoWIFI может еще от телефона зависеть. У меня был Андроид-смартфон 21го года, там VoWIFI запускался на секунду и тут же пропадал. Я уже успел поддержку запросами завалить и готов был всерьёз расчехлять Wireshark чтобы смотреть, что с пакетами происходит. Но потом купил айфон и всё магически заработало (в итоге от этой истории ощущение - как от интернета 2000х, когда сайты делали не "как правильно", а "чтобы в IE работало")
я бы еще tmux добавил
Спасибо, так понятнее. Просто из статьи сложилось впечатление, будто shared storage - это главное лекарство от всех проблем, а распределённые join и агрегирования как будто за скобками остались.
В статье много раз упоминается "общий storage", но я не увидел ни слова про "общую RAM" - только (обоснованные) причитания про " трудные вопросы с распределенными JOIN«ами " . Простите, а как ваш горизонтальный кластер решает эти трудные вопросы? Oracle для этого придумал RDMA, а тут я вижу гораздо более простую схему с координатором а-ля ClickHouse. Чем это принципиально лучше аппаратного шардирования, которое вы почему-то называете тупиковым?
А кто пальцем будет тыкать? Бизнес сам будет следить? Увольте - у них своих бизнесовых дел хватает, надо деньги зарабатывать.
Вы пишете, что все отделы внедрения должны строевым шагом отправиться в сад. А я вижу так, что у аналитиков и архитекторов наоборот работы прибавится, потому что итерации ускорятся. То, что хотелки будут реализовываться быстрее не отменяет работы по планированию и выстраиванию бизнес-процессов
ха-ха-ха. А потом выясняется, что промпт-инженер считал просрочку от последнего шага, а заказчик - от начала процесса. А писателя ТЗ, который бы это заметил нет - всех выгнали и заменили Клодом
Ну или вот так: "Да, ты совершенно прав, на этапе "отправь финансовый отчёт всем ответственным" не надо отправлять его нашему кладовщику. Я исправлю это со следующим отчётом". Причём в этой ситуации не надо придумывать никакой физики - тут просто неверное понимание умолчаний.
В общем, согласен, ИИ всех победил, пойду искать простыню и искать направление к кладбищу.
Странно, что дяде Паше в Палермо не смогли объяснить, что Мальбек холодным не пьют
Немного в сторону от статьи. Когда слова "такси" и "postgres" оказываются рядом, сразу вспоминается неудачная попытка Uber переехать на PG (https://habr.com/en/companies/slurm/articles/322624/) Навскидку, больнее всего стрельнул update amplification в связке с частыми обновлениями координат и репликацией.
Наверняка в начале проекта вы знали про эту историю - почему в итоге выбрали PG, а не, например YDB?
vial это для QMK-прошивок (проводные клавиатуры). А у автора ZMK, с ней официальный vial не работает
Хороший проект, но не увидел в описании: есть ли возможность проверить снятый бэкап? Например, автоматом восстановить его на отдельной машине, затерев предыдущую версию.
а как вы тогда боретесь с тем, что фильтр по одной таблице скрывает строки целиком, затрагивая строки и в другой таблице, выведенной рядом (а также диаграммы и вообще всё любое, чему непосчастливилось оказаться на отфильтрованной строке) ?
Помнится, в каком-то чемпионате (чуть ли не в F1) в какой-то момент внедряли буквально "пылесосы" - практически такие же, как заявлены в патенте. Пару раз машину срывало, когда пылесос ломался в самый неподходящий момент. После этого систему запретили
Как всегда, на любой вопрос существует простое, всем очевидное, неправильное решение
Можно показать время последнего апдейта витрины. Но что если витрина собирается из нескольких потоков? Один обновляется раз в час, другой - раз в три часа? А если кому-то из аналитиков интересен только "быстрый" поток и ему не важно, что "медленный" сегодня упал - он всё равно в него не смотрит?
Тут архитектор обычно закатывает глаза и вспоминает про согласованный SLA. А кто-то действительно прокидывает даты обновления по потокам - всё от потребности зависит. И я не вижу тут никакого криминала
у нас no-code успешно работает: бизнес-аналитикам подготовили заранее спроектированные data source и они отлично теперь рисуют в BI нужные отчёты. Если бы их заставили вместо этого кодить в SQL и Python - я представляю какой бы стоял вой (без осуждения)
Да, это не панацея. Какие-то сложные штуки всё равно программируются на JS + SQL. Но, по ощущениям, процентов 80 отчётов ушли как раз в сторону no-code
Интересно. Но это всё-таки больше альтернатива Dash, чем замена Tableau.
Мне кажется, главная заслуга любого no-code - именно в том, что он скрывает "страшный-ужасный" код от глаз бизнес-аналитиков. Да, по сути, они набрасывают мышкой тот же SELECT, но визуально это более дружелюбно. Я не раз видел, как, например, люди впадают в ступор от упоминания оконных функций - но легко пользуются их аналогами из визуальных BI
Не могу не оставить тут статью с критикой MERGE в MS SQL Server https://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/
Вкратце:
в работе MERGE есть баги, некоторые из них не будут исправлены
для борьбы с race condition могут потребоваться избыточные блокировки (это указано в статье)
MERGE неочевидно работает с триггерами. Если на таблице есть триггеры, лучше дополнительно протестировать поведение MERGE
Статья интересная и такое применение лаконичнее, чем расписывать каждую команду по отдельности и для каждой ловить свой Output. Но надо помнить, что MERGE в MS SQL Server - не самая эффективная конструкция
" Малофеев подал два иска против Twitch в июне и октябре 2022 года, что компания назвала нарушением условий обслуживания. "
Я надеюсь, к этому пункту договора прикреплена фотография Стетхема с подписью "Я запрещаю вам подавать на нас в суд!"
Одно время у меня был её проводной аналог - Wired Keyboard 600.Очень нравилась, даже на работу себе такую же купил
В какой-то момент решил "проапгрейдитсья" до беспроводной (у них же даже габариты совпадают) Какое же это было разочарование! Из-за того, что какой-то злой гений решил убрать все отступы межу клавишами F-блока , основной клавиатурой, стрелками и нумпадом - я просто перестал попадать по нужным клавишам (особенно по F-кам). Для меня тогда это было критично, я помучился полгода и потом просто подарил её кому-то из друзей
VoWIFI может еще от телефона зависеть. У меня был Андроид-смартфон 21го года, там VoWIFI запускался на секунду и тут же пропадал. Я уже успел поддержку запросами завалить и готов был всерьёз расчехлять Wireshark чтобы смотреть, что с пакетами происходит. Но потом купил айфон и всё магически заработало (в итоге от этой истории ощущение - как от интернета 2000х, когда сайты делали не "как правильно", а "чтобы в IE работало")
да я потому и спрашиваю. Формулировки, как обычно, крайне расплывчатые - и непонятно, что отвалится, а что нет
Получается, VoWIFI запретили?