У вас 48 ядер. Количество активных запросов - ~1000 (я на MySQL видел 24 ядра и 4,5+ тыс активных запросов, обнулили кэши nginx на нагруженном проекте, как же давно это было!). У вас в подобной ситуации запросы за процессорные такты будут драться, а не за блокировки.
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.
Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.
DWH не имеет смысл без целевой аудитории. Да, есть подход: "Давайте все подряд хранить (с непонятным качеством), а потом разберемся". Но это помойка, а не хранилище данных.
Недавно был наглядный пример с битой по кошельку. При заливке данных в дата сервис из Oracle в MSSQL терялась точность. Т.к. контора была крупная и количество нулей в цифрах было внушительным набегало ощутимо. В отчетности этого сразу и не увидеть, т.к. все думали, что таких "косяков" в 21 веке не должно быть. Но выявили именно на интеграционных тестах разработчики. Скандал знатный был!
Редко встретишь отдельный Data Quality слой. За это, прям, низкий поклон. В одной очень толстой конторе на меня смотрели как на умалишенного только за предложение, хотя бы проверить качество данных и соответствие их требованиям, не говоря уже за полный контроль и автоматизацию проверки.
Честно говоря, странно, что вплоть до 2022 года были архитектура и решения из 90х. Прям жалко, что столько тратилось средств и ресурсов впустую. Хорошо, что вы пришли к взвешенному решению. Удачи и успехов!
Я в году 2003 решил поменять материнку. Начитался и выбрал одну от Gigabyte в ту пору хороший середнячок. После работы решил все собрать. Благо ночь впереди, если что. Как раз входил новый сокет на проц и дополнительное питание. Собрал, включаю..., а тишина! Аж в пот пробило. Давай разбираться. Тогда ещё шла схема в комплекте. Смотрю на схеме доп питание полярность одна, а на плате зеркальная! Перепроверил несколько раз. Уж думал разучился читать схемы. И доп питание распаяно ж тоже наоборот! Короче, в штекере перебрасываю плюс-минус, включаю - все работает!
Почти через год случается КЗ в квартире, что снимал, проводка дрянь была. Ну, и мамка вылетела, благо на гарантии. Понёс в контору на удачу. Они даже не удивились: вон в углу их по гарантии целая пачка - не заводятся! Показываю в чем причина. Не верят. Пробуем тут же, перебрасывает плюс-минус. Все работает! Мужики мне и мамку северную вместо этой поменяли и видяху прошную в полцены продали. Они всю партию потом нормально реализовали. Получается была ошибка на плате.
Исправьте в тексте. Это достаточно критично в некоторых случаях. Например, Kafka, не меняет порядок сообщений, тогда как JMS поддерживает приоритезацию, которая меняет порядок сообщений.
В Линуксе, а потом и в Винде пользуюсь виртуальными экранами для организации отдельных окружения. Например, 1й - почта и подобное., 2й - разработка, 3й- мониторинг и т.д.
В KDE есть отдельные комнаты там помимо разделения задач можно сохранять и настраивать весь сеанс и иконки и все остальное. На самом деле, инструменты есть, но редко кто "заморачивается", хочется чтоб в е само как-то
Как начинаешь новый frontend проект, так начинается все сначала: какие папки, как назвать, что такое компонент, слой, фича и т.д. и т.п. В одном проекте это согласование заняло около месяца! Уже бэк успели сделать, а все шли дебаты.
Общие компоненты, по-хорошему, должны быть внесены в отдельный репозитой и подтягиваться отдельным артефактом. Если вы положили что-то в определённую папку, это не значит, что это стало тем, что предполагалось помещать в эту папку.
Мы же предлагаем строить приложения более прямолинейно, как мы все привыкли, вокруг Интерфейсов.
Самое смешное, такого же принципа, часто придерживаются UX-дизайнеры. И получается, если нужно сделать принципиально новый дизайн и разработать новый поход, компоненты и прочее, то все в ступоре, т.к. такого никто не делал и интерфейса ещё в природе нет. А плясать нужно от бизнеса, от природы вещей - сущностей. А сущности могу не иметь UI отображения и тогда совсем беда...
Лет 20 назад друг настроил Emacs по образу и подобию Borland'a, но на Linux. Было реально круто, но нужно заморочиться и потратить время знатно. Как-то вспомнил, захотелось попробовать, но не осилил - не было мотивации столько сил тратить. Как вариант, если подготовить шаблоны, чтоб переиспользовать, то можно получить реальную IDE
Больше всего бесило во встроенных в Идею плагинов для БД - зависание. Сидишь, дебажишь, нужно что-то посмотреть в базе, а все зависло. И ни базу не посмотришь ни код. Носишь все и по новой запускаешь. Нет уж увольте. Почему-то ни у кого не возникает желания держать и молоток и пассатижи в одной руке и мультитул считается как непрофессиональный компромисс.
Да, Идея в свое время сделала ставку на рефакторинг и выиграла. Но и у неё есть слабые стороны. Я и сам сижу на Идеи, но если бы была другая ушёл бы, т.к. пару "фич" редактора не исправляются с самого рождения. Отладчик так и не умеет показывать возвращаемого значения из функции. А с внедрением лямд в Java количество нераспозноваемого кода для отладчика только растёт. Мультимодульные проекты не всегда подтягивается корректно... В свое время, когда вынужденно переходил с jBuilder'а, буквально плакал. Жаль Borland не выжил. А в последнее время основная фича - рефакторинг - тоже сбоит. Поменяли интерфейс на спорный...
Не боги горшки обжигают. Если будут почивать на лаврах, то точно так же как и предыдущих "богов" сметут.
Довольно неожиданный взвешанный взгляд. Важно, чтоб аналитик был частью команды, а не надзирателем.
Единственное, с чем не могу согласиться, так это, что аналитик может быть ответственен за архитектуру. Да, такие примеры есть, но, честно говоря, в основном неудачные либо в рамках тренда (от слова трындеть :), тобишь то, что на слуху: "микроскрвисы нынче в моде". Либо отсутствует понимание роли архитектора решения. Именно архитектор может взвесить все за и против с технической точки зрения и проработать нюансы. Нормальный архитектор не зря ест свой хлеб.
Например, недавно был пример. Аналитик хоть и был со стороны компании команды, но противопоставлял себя команде и его решение должно было быть окончательным.
Вы что, мне знаете как сделать "снежинку"?
Ну, если ты тоже архитектор, то будь добр расскажи почему "снежинка","вдруг", не даёт требуемой скорости в нужных запросах? Это ж просто! Все так делают и в книжках написано...
Только книжку, видимо, не дочитал, хотя, скорее, не читал, т.к. там описаны плюсы и минусы снежинки и звезды.
Каждый в команде должен заниматься своим делом в команде, тогда и команда будет эффективной.
Вообще, тёмный фон в любом дизайне, будь то интерьер, фото, интерфейс - это всегда вызов. А почему? Человек - дневное животное. Оттенки черного многим не под силу, ввиду естественного ограничения зрения. Плюс, если говорить о фоне, то любая мелкая, но светлая деталь становится видимой, чёткой, назойливой. Там, где подразумевалась тень, она либо исчезает, либо становиться наоборот засветкой. Поэтому тёмная тема полностью должна быть создана с нуля, т.к. меняется концепция. И именно поэтому многим дорого создавать полностью новую тему. А в некоторых случаях, где скорость реакции имеет критическое значение, приходится отказываться от тёмного интерфейса, как от неестественно го для человека.
Когда тех лид с умным видом на конференции рассказывал, как он проверяет форматирование кода на код ревью, а не использует PM, Checkstyle, Sonar для таких проверок, уровень Сбера стал понятен
Ой, и правда, аж вспомнился 2001 год! У меня друг работал на MySQL, писал ядро и тестировали вместе. Пробовали тогда и на винде и линуксе и фре и полуоси... Упиралось всё в ОС. Самое интересно было на Win NT4: операционка честно открывала сокеты "сколько хотел", но после 1000 открытых только этим и занималась, а на остальное не реагировала. На FreeBSD вообще никаких проблем, только сразу настройки подтюнить и нормально и 5К на 4 ядрах держала. С линухом ядро пересобирали, но тоже такого же результата добились.
Сижу на openSuse с 10 версии. Не хотелось бы, чтоб проект закрылся!
Во многих базах количество строк хранится в метаинформации таблицы и действительно такие запросы оптимизируются до возврата значения переменной
Вот именно. Кто платит - тот и заказывает музыку. А все промежуточные звенья вторичны. Но как раз тот же СЕО может не до конца или вообще не видеть ценность этих данных. И не потому, что он тупой, а потому, что эти данные реально не имеют ценности для бизнеса, а являются чьей-то хотелкой для распила денег на среднем уровне.
Живой пример. Одна контора ежегодно платит крупной аудиторской фирме за формирование гос. отчетности круглую сумму. Отчеты с технической точки зрения абсолютно несложные. Менеджер среднего звена выступает с предложением сделать собственное решение и формировать отчеты самостоятельно. Мы реализуем проект. Проходит демонстрация на ура. Компания ежегодно может сэкономить солидную сумму. Менеджер осваивает бюджет в рамках дозволенного и идет на повышение. Все довольны. Продакшн. Следующая версия и т.д.
Через 3 месяца все сворачивается: возвращаем все назад! С точки зрения бизнеса и компании никакого выигрыша нет, т.к. свое решение требует поддержки, а отказ от части услуг аудиторской фирмы грозит имиджевыми издержками.
Конечный владелец есть всегда бизнес, а не средние прослойки. Многие отчеты среднего звена делаются "для галочки" или красивых графиков для презентаций, но не влияющих ни на что.
DWH не имеет смысл без целевой аудитории. Да, есть подход: "Давайте все подряд хранить (с непонятным качеством), а потом разберемся". Но это помойка, а не хранилище данных.
Недавно был наглядный пример с битой по кошельку. При заливке данных в дата сервис из Oracle в MSSQL терялась точность. Т.к. контора была крупная и количество нулей в цифрах было внушительным набегало ощутимо. В отчетности этого сразу и не увидеть, т.к. все думали, что таких "косяков" в 21 веке не должно быть. Но выявили именно на интеграционных тестах разработчики. Скандал знатный был!
Редко встретишь отдельный Data Quality слой. За это, прям, низкий поклон. В одной очень толстой конторе на меня смотрели как на умалишенного только за предложение, хотя бы проверить качество данных и соответствие их требованиям, не говоря уже за полный контроль и автоматизацию проверки.
Честно говоря, странно, что вплоть до 2022 года были архитектура и решения из 90х. Прям жалко, что столько тратилось средств и ресурсов впустую. Хорошо, что вы пришли к взвешенному решению. Удачи и успехов!
Ой, за логи в бинарниках прям отдельный котёл в аду!
Так, systemd уже тоже, типа, не модно и появилось куча своего чуть ли не в каждом дистрибутиве.
А если дальше по размышлять, то все лямбды - это хорошо забытое старое, например, программы на меинфреймах.
Ой, вы так изящно ругаетесь! Инлайн, макросы!..
Тут недавно за инлайн отмотивировали, т.к. читабельность падает.
А макросы, блоки кода и т.п. это ж скакать по коду нужно, а то и в другой файл!
К сожалению, уже и схему выбросил недавно, бумажки разбирал. Так хоть что-то было бы.
Я в году 2003 решил поменять материнку. Начитался и выбрал одну от Gigabyte в ту пору хороший середнячок. После работы решил все собрать. Благо ночь впереди, если что. Как раз входил новый сокет на проц и дополнительное питание. Собрал, включаю..., а тишина! Аж в пот пробило. Давай разбираться. Тогда ещё шла схема в комплекте. Смотрю на схеме доп питание полярность одна, а на плате зеркальная! Перепроверил несколько раз. Уж думал разучился читать схемы. И доп питание распаяно ж тоже наоборот! Короче, в штекере перебрасываю плюс-минус, включаю - все работает!
Почти через год случается КЗ в квартире, что снимал, проводка дрянь была. Ну, и мамка вылетела, благо на гарантии. Понёс в контору на удачу. Они даже не удивились: вон в углу их по гарантии целая пачка - не заводятся! Показываю в чем причина. Не верят. Пробуем тут же, перебрасывает плюс-минус. Все работает! Мужики мне и мамку северную вместо этой поменяли и видяху прошную в полцены продали. Они всю партию потом нормально реализовали. Получается была ошибка на плате.
Исправьте в тексте. Это достаточно критично в некоторых случаях. Например, Kafka, не меняет порядок сообщений, тогда как JMS поддерживает приоритезацию, которая меняет порядок сообщений.
В Линуксе, а потом и в Винде пользуюсь виртуальными экранами для организации отдельных окружения. Например, 1й - почта и подобное., 2й - разработка, 3й- мониторинг и т.д.
В KDE есть отдельные комнаты там помимо разделения задач можно сохранять и настраивать весь сеанс и иконки и все остальное. На самом деле, инструменты есть, но редко кто "заморачивается", хочется чтоб в е само как-то
Как начинаешь новый frontend проект, так начинается все сначала: какие папки, как назвать, что такое компонент, слой, фича и т.д. и т.п. В одном проекте это согласование заняло около месяца! Уже бэк успели сделать, а все шли дебаты.
Общие компоненты, по-хорошему, должны быть внесены в отдельный репозитой и подтягиваться отдельным артефактом. Если вы положили что-то в определённую папку, это не значит, что это стало тем, что предполагалось помещать в эту папку.
Самое смешное, такого же принципа, часто придерживаются UX-дизайнеры. И получается, если нужно сделать принципиально новый дизайн и разработать новый поход, компоненты и прочее, то все в ступоре, т.к. такого никто не делал и интерфейса ещё в природе нет. А плясать нужно от бизнеса, от природы вещей - сущностей. А сущности могу не иметь UI отображения и тогда совсем беда...
Лет 20 назад друг настроил Emacs по образу и подобию Borland'a, но на Linux. Было реально круто, но нужно заморочиться и потратить время знатно. Как-то вспомнил, захотелось попробовать, но не осилил - не было мотивации столько сил тратить. Как вариант, если подготовить шаблоны, чтоб переиспользовать, то можно получить реальную IDE
Больше всего бесило во встроенных в Идею плагинов для БД - зависание. Сидишь, дебажишь, нужно что-то посмотреть в базе, а все зависло. И ни базу не посмотришь ни код. Носишь все и по новой запускаешь. Нет уж увольте. Почему-то ни у кого не возникает желания держать и молоток и пассатижи в одной руке и мультитул считается как непрофессиональный компромисс.
И как же люди жили без нее до Идеи?
Да, Идея в свое время сделала ставку на рефакторинг и выиграла. Но и у неё есть слабые стороны. Я и сам сижу на Идеи, но если бы была другая ушёл бы, т.к. пару "фич" редактора не исправляются с самого рождения. Отладчик так и не умеет показывать возвращаемого значения из функции. А с внедрением лямд в Java количество нераспозноваемого кода для отладчика только растёт. Мультимодульные проекты не всегда подтягивается корректно... В свое время, когда вынужденно переходил с jBuilder'а, буквально плакал. Жаль Borland не выжил. А в последнее время основная фича - рефакторинг - тоже сбоит. Поменяли интерфейс на спорный...
Не боги горшки обжигают. Если будут почивать на лаврах, то точно так же как и предыдущих "богов" сметут.
Довольно неожиданный взвешанный взгляд. Важно, чтоб аналитик был частью команды, а не надзирателем.
Единственное, с чем не могу согласиться, так это, что аналитик может быть ответственен за архитектуру. Да, такие примеры есть, но, честно говоря, в основном неудачные либо в рамках тренда (от слова трындеть :), тобишь то, что на слуху: "микроскрвисы нынче в моде". Либо отсутствует понимание роли архитектора решения. Именно архитектор может взвесить все за и против с технической точки зрения и проработать нюансы. Нормальный архитектор не зря ест свой хлеб.
Например, недавно был пример. Аналитик хоть и был со стороны компании команды, но противопоставлял себя команде и его решение должно было быть окончательным.
Ну, если ты тоже архитектор, то будь добр расскажи почему "снежинка","вдруг", не даёт требуемой скорости в нужных запросах? Это ж просто! Все так делают и в книжках написано...
Только книжку, видимо, не дочитал, хотя, скорее, не читал, т.к. там описаны плюсы и минусы снежинки и звезды.
Каждый в команде должен заниматься своим делом в команде, тогда и команда будет эффективной.
Спасибо огромное за комплексный подход.
Вообще, тёмный фон в любом дизайне, будь то интерьер, фото, интерфейс - это всегда вызов. А почему? Человек - дневное животное. Оттенки черного многим не под силу, ввиду естественного ограничения зрения. Плюс, если говорить о фоне, то любая мелкая, но светлая деталь становится видимой, чёткой, назойливой. Там, где подразумевалась тень, она либо исчезает, либо становиться наоборот засветкой. Поэтому тёмная тема полностью должна быть создана с нуля, т.к. меняется концепция. И именно поэтому многим дорого создавать полностью новую тему. А в некоторых случаях, где скорость реакции имеет критическое значение, приходится отказываться от тёмного интерфейса, как от неестественно го для человека.
Когда тех лид с умным видом на конференции рассказывал, как он проверяет форматирование кода на код ревью, а не использует PM, Checkstyle, Sonar для таких проверок, уровень Сбера стал понятен