Аж итересно было узнать чем же этот новый Spec Driven Development отличается от лампового дизайна по требованиям, которого все гнобили в угоду аджайлу. Но так ничего и не показали.
Я такое наблюдал в одной толстой мировой компании. Они реально 18 месяцев не могли прийти к единому мнению, т.к. всем было удобно ничего не делать, а главное не брать на себя ответственность. Слили нам и давай расказывать как нужно делать (при том без дизайна, на пальцах), ревью с пристрастием и покрытием тестами 100%. И все нужно за месяц. На вопрос "почему тогда сами не сделали" обиделись. В результате вылелось в месяцев 9.
Сам переводил базы в одном крупном международном банке и большой ретэйл корпорации. Не скажу, что с пол пинка, т.к. Postres всегда шел заменой Oracle, а не MSSQL. T-SQL приходится адаптировать, точность данных в MSSQL ниже, казалось бы не страшно, но находятся умельцы, которые и к этому привязываются. С нагрузками никаких проблем нет, но нужно тюнить начиная с операционки или использовать готовый облачный БД сервис.
Windows NT - это содранная почти полностью IBM OS/2. И учитывая, что мама Гейтса была в совете директоров IBM это не удивительно.
В OS/2 реальное микро ядро, которое могло полностью загружать все, что нужно по сетке. Тогда как NT до такого уровня так и доросла и нужна была полная инсталляция.
Неужели никого не смущает выбор S3 (бинарного хранилища общего назначения) в качестве аналитического хранилища? Оно ж само по себе не предназначено для этого. Конечно, потом наворачивается вся эта лабуда, изобретаются велосипеды с квадратными колесами и потаемся выжать из железа максимум. Да, беда. Опыт предыдущих поколений фф топку!
Просто диву даешься как можно было собрать все грабли построения базы данных в одном флаконе! Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании. А то потом героически преодолеваем трудности, хотя их могло и не быть изначально выбери другой подход.
весь наш ETL изначально жил внутри SQL-движка
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый. Значительно удобней вынести в отдельные сервисы и не грузить саму базу.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
В следующей статье серии мы подробнее поговорим о сторидже и о том, как объектное хранилище из фонового компонента архитектуры превратилось в один из ключевых факторов, определяющих ограничения, проблемы и инженерные решения Lakehouse-платформы.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Как-то не дает покое ощущение, по описанию, что DWH и весь процесс ETL построен неоптимально или Vertica используется некорректно, поэтому и присутствуют все проблемы. Например, говорится о таблицах с сотнями колонок, но у column-based баз, как Vertica, нет таких таблиц физически. Там хранилище организовано по-другому. Или например, низкая скорость вставки. Да, если вставлять по одной записи скорость будет относительно низкая, причем, и в реляционной базе тоже, т.к. перестройка индексов занимает львиную долю времени и чем больше индексов (колонок, измерений), тем больше времени.
Еще смущает такое количество витрин. Какие критерии используются: по отраслям, направлениям и т.д.? Похоже как агрегация производится "в лоб". Если такое количество нужно постоянно переиндексировать, то рано или поздно любая база не справится.
Вот реально, только расслабился и опять по новой! Только отвык руками иксы конфигурить с кучей настроек и держать отдельные профайлы, а тут с другого бока засада :(
Спасибо, что поправили. Неудачно попытался избежать узкого термина. Конечно, в рамках партиции, т.к. в рамках группы (в терминах Кафки) не может быть очередности в силу природы топика
К сожалению, считается, что ИТ - это молодая и уникальная область. И этот миф культивируется уже который десяток лет, что позволяет иметь постоянный заработок. 99% автоматизируемых задач просто копирует человеческое поведение и решение, чаще всего не инженерное и не оптимальное, а в лоб. Даже ребят с инженерных специальностей и прикладным опытом это быстро расхолаживает.
Наверное, единственная вменяемая статья за все годы существования Аджаил. Обычно все сводится к "Вы неправильно его готовите, мы сейчас вам все расскажем и Фсё будет Аджаил!" И он наступает, полный Аджаил! Чаще всего сталкиваешься с тем, что нет ни готовности ни желания ни понимания, да и необходимости, т.к. проблема в другом, но обещали это поможет.
У вас 48 ядер. Количество активных запросов - ~1000 (я на MySQL видел 24 ядра и 4,5+ тыс активных запросов, обнулили кэши nginx на нагруженном проекте, как же давно это было!). У вас в подобной ситуации запросы за процессорные такты будут драться, а не за блокировки.
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.
Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.
Аж итересно было узнать чем же этот новый Spec Driven Development отличается от лампового дизайна по требованиям, которого все гнобили в угоду аджайлу. Но так ничего и не показали.
Я такое наблюдал в одной толстой мировой компании. Они реально 18 месяцев не могли прийти к единому мнению, т.к. всем было удобно ничего не делать, а главное не брать на себя ответственность. Слили нам и давай расказывать как нужно делать (при том без дизайна, на пальцах), ревью с пристрастием и покрытием тестами 100%. И все нужно за месяц. На вопрос "почему тогда сами не сделали" обиделись. В результате вылелось в месяцев 9.
А можно по-подробней? У меня, наоборот, уменьшение ресурсов. Какая версия Оракла и Слона, операционка и т.п.?
Сам переводил базы в одном крупном международном банке и большой ретэйл корпорации. Не скажу, что с пол пинка, т.к. Postres всегда шел заменой Oracle, а не MSSQL. T-SQL приходится адаптировать, точность данных в MSSQL ниже, казалось бы не страшно, но находятся умельцы, которые и к этому привязываются. С нагрузками никаких проблем нет, но нужно тюнить начиная с операционки или использовать готовый облачный БД сервис.
Сейчас линуховый драйвер отличный для старых Canon сканеров, только Wifi, вроде, не поддерживает.
Windows NT - это содранная почти полностью IBM OS/2. И учитывая, что мама Гейтса была в совете директоров IBM это не удивительно.
В OS/2 реальное микро ядро, которое могло полностью загружать все, что нужно по сетке. Тогда как NT до такого уровня так и доросла и нужна была полная инсталляция.
К сожалению, как никто не мог в одной строчке поток обработать корректно с регулярками кроме перла, так и не может.
Да, появились новые и расширились старые утилиты, но все равно какие-то свои особенности в синтаксисе регулярок
Неужели никого не смущает выбор S3 (бинарного хранилища общего назначения) в качестве аналитического хранилища? Оно ж само по себе не предназначено для этого. Конечно, потом наворачивается вся эта лабуда, изобретаются велосипеды с квадратными колесами и потаемся выжать из железа максимум. Да, беда. Опыт предыдущих поколений фф топку!
Просто диву даешься как можно было собрать все грабли построения базы данных в одном флаконе! Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании. А то потом героически преодолеваем трудности, хотя их могло и не быть изначально выбери другой подход.
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый. Значительно удобней вынести в отдельные сервисы и не грузить саму базу.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Как-то не дает покое ощущение, по описанию, что DWH и весь процесс ETL построен неоптимально или Vertica используется некорректно, поэтому и присутствуют все проблемы. Например, говорится о таблицах с сотнями колонок, но у column-based баз, как Vertica, нет таких таблиц физически. Там хранилище организовано по-другому. Или например, низкая скорость вставки. Да, если вставлять по одной записи скорость будет относительно низкая, причем, и в реляционной базе тоже, т.к. перестройка индексов занимает львиную долю времени и чем больше индексов (колонок, измерений), тем больше времени.
Еще смущает такое количество витрин. Какие критерии используются: по отраслям, направлениям и т.д.? Похоже как агрегация производится "в лоб". Если такое количество нужно постоянно переиндексировать, то рано или поздно любая база не справится.
Может в другой части раскроите больше деталей?
Вот реально, только расслабился и опять по новой! Только отвык руками иксы конфигурить с кучей настроек и держать отдельные профайлы, а тут с другого бока засада :(
Спасибо за статью и готовое решение для стресс-тестирования. Очень важно, что база работает, но очень медленно. Хорошая эмуляция!
Спасибо, что поправили. Неудачно попытался избежать узкого термина. Конечно, в рамках партиции, т.к. в рамках группы (в терминах Кафки) не может быть очередности в силу природы топика
В рамках группы она была всегда.
К сожалению, считается, что ИТ - это молодая и уникальная область. И этот миф культивируется уже который десяток лет, что позволяет иметь постоянный заработок. 99% автоматизируемых задач просто копирует человеческое поведение и решение, чаще всего не инженерное и не оптимальное, а в лоб. Даже ребят с инженерных специальностей и прикладным опытом это быстро расхолаживает.
Наверное, единственная вменяемая статья за все годы существования Аджаил. Обычно все сводится к "Вы неправильно его готовите, мы сейчас вам все расскажем и Фсё будет Аджаил!" И он наступает, полный Аджаил! Чаще всего сталкиваешься с тем, что нет ни готовности ни желания ни понимания, да и необходимости, т.к. проблема в другом, но обещали это поможет.
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.
Сижу на openSuse с 10 версии. Не хотелось бы, чтоб проект закрылся!
Во многих базах количество строк хранится в метаинформации таблицы и действительно такие запросы оптимизируются до возврата значения переменной
Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.