1. «NULL ≠ 0 - если это поле числового типа, то он вполне себе число» Вы смешиваете тип данных и значение. Да, поле имеет числовой тип, но само значение NULL не является числом в математическом смысле. Это маркер отсутствия числа в данном поле. 2. «FALSE AND UNKNOWN = FALSE - вполне себе интуитивно» Тут сложно спорить, все индивидуально) Интуитивно для тех, кто знает теорию множеств и булеву алгебру. А новичок часто видит UNKNOWN и думает: «Ну, раз неизвестно, то и результат должен быть неизвестен». А тут вдруг FALSE. 3. «WHERE требует TRUE, CHECK требует что угодно, лишь бы не FALSE». Вопрос формулировок. Надеюсь, это замечание окончательно закрепит понимание этого важного нюанса) 4. «SUM, AVG игнорируют NULL - надо оговорить, что возвращают NULL, если все NULL» Да, это следует из определения агрегации. Если нет значений - нечего суммировать. 5. «В MySQL есть <=> они не единственные» IS NOT DISTINCT FROM (как и его "обратная" версия IS DISTINCT FROM) – включен в стандарт ANSI SQL. В то же время MySQL и MariaDB реализуют ту же логику через свой собственный оператор <=>, который не является стандартным, и при миграции кода может вызвать проблемы. 6. «NOT EXISTS - неуниверсально, может убить план» Этот пункт конкретно про рекомендацию против логической ошибки с NULL и NOT IN, а не как догма для всех случаев. План выполнения не имеет значения, если результат неверный. Про эту тему можно добавить: · Современные оптимизаторы (PostgreSQL, Oracle, SQL Server) умеют преобразовывать NOT EXISTS в анти-соединения и хеш-соединения, если это выгодно (не всегда и не все). В любом случае необходимо смотреть план выполнения в каждом запросе, а не следовать бездумно общим рекомендациям. · Если подзапрос некоррелированный, его можно вынести в CTE или материализовать, или решить другим способом. Это вопрос не навыка работы с NULL.
В любом случае, мы рады что эта тема вызвала Ваш интерес. Ваши замечания, надеемся, катализирует читателя глубже разбирать формулировки и крайние случаи.
Отдельные люди под NEOMSA обычно не нужны. Достаточно команды, которая уже эксплуатирует любую инфраструктурную или интеграционную платформу.
Базовое: Kubernetes, Linux, сети, сертификаты, мониторинг, логи, обновления, бэкапы. Специфика API management: политики, авторизация, квоты, версии API, интеграции с внутренними системами. Как правило у тех, кто вообще дошёл до вопроса про APIM, всё это уже есть.
Разбираться в устройстве самой платформы при этом не нужно. Настраивать API, политики и доступы, следить за работой, обновлять по инструкции это делает команда заказчика. А если что-то ломается внутри самого продукта или выходит уязвимость, это уже к нам.
Спасибо за замечание. Мы как раз не пытаемся скрывать корни нашей кодовой базы или делать вид, что этого фактора не существует. Напротив, для enterprise-продукта критически важно честно понимать, откуда он вырос, какие риски это за собой несёт и как именно эти риски минимизируются.
В случае с NEOMSA мы точно не ограничились подходом «взяли WSO2 и просто переупаковали». Наша команда провела глубокий аудит и устранение уязвимостей, доработала продуктовую часть и успешно прошла проверку РБПО. Безопасность, сопровождение и контроль кода для нас — не теоретический пункт в сравнительной таблице, а реальная практическая зона ответственности.
Итог простой: происхождение платформы, безусловно, важно. Но не менее важно то, выстроил ли вендор понятный процесс работы с этим наследием, закрывает ли уязвимости и способен ли развивать продукт в долгосрочной перспективе.
Если вам интересно подробнее узнать, как всё это устроено внутри NEOMSA, напишите нам на почту neomsa@neoflex.ru — детально расскажем, что именно мы изменили и как сопровождаем продукт сейчас.
На практике, защита персональных данных строится вокруг известных систем хранения и формально описанных потоков данных. Однако по мере роста и развития бизнеса, появляются дополнительные копии данных — в аналитических хранилищах, тестовых средах, логах и интеграционных пайплайнах. Поэтому деперсонализация становится важным механизмом снижения риска, она позволяет использовать данные в разработке и аналитике без распространения персональной информации.
Наша система позволяет отслеживать изменения в структуре данных - появление новых таблиц/полей и маскирует их по умолчанию, оповещая об изменения ответственных лиц.
Исходя из нашего проектного опыта, полностью синтетические данные хорошо подходят для изолированных тестов, но редко воспроизводят сложную структуру и взаимосвязи реальных данных. Например у пользователя может быть связь между валютой, страной, типом аккаунта. Синтетический генератор легко создаст статистически похожие данные, но не сохранит реальные взаимосвязи. На наш взгляд, деперсонализация позволяет сохранить структуру данных и при тестировании можно найти редкие кейсы, о которых ранее не упомянул заказчик при обсуждении ТЗ.
С учетом того, что бизнес-процесс был изначально устроен так, что по одному клиенту мог проводиться только один платеж в день выбор ключа PRIMARY KEY (client_name, payment_date) очевиден. И при возврате вернется именно тот платеж, который был совершен в эту дату этим клиентом.
Упоминаемые недостатки (размер, сложность, предсказуемость) действительно не являются приговором. В статье подсвечиваются риски того, что может быть. Спорить можно только о вероятности появления этого риска. Укажите, пожалуйста, на конкретное утверждение, которое, по вашему мнению, неверно в принципе и такого "не может быть никогда" - мы с благодарностью изучим этот вопрос, возможно и нам это принесет новые знания.
Хотелось бы передать многообразие ключей и причины их появления, поэтому про интеграцию систем и эффективность потоков данных, как раз следующий DWH уровень.
Этот пример это и показывает. Помимо того, что любой SEQUENCE не гарантирует непрерывность числового ряда. Например, при откате транзакции полученное значение теряется безвозвратно. Но даже в "идеальном мире" — без единого отката — использование CASHE - основная причина разрывов.
Большое спасибо за ваш отклик! Вы абсолютно правы. Мы использовали абстрактные примеры для наглядности, но вы точно подметили ключевое различие: например в ритейле с микросервисной архитектурой, а не 1-2 источниками, как в нашем примере, Data Vault оказывается гораздо более жизнеспособным и гибким выбором на долгосрочную перспективу благодаря своей масштабируемости и адаптивности к частым изменениям.
Безусловно, мы высоко ценим современные инструменты управления данными, такие как возможности различных БД, Data Quality решения, Data Catalog и др. Мы активно применяем их в своей работе. Однако в реальных проектах не всегда есть идеальные условия.
Добрый день! Хотели бы отметить, что запросов, касающихся того, чтобы сделать OLAP с той же функциональностью, как был в MS, к нам поступает достаточно много. На ClickHouse зачастую переходить не хотят, и в Exel модели на MDX не покрутишь, поэтому и возникают идеи насчет Kylin / eMondrian
Добрый день! На наш взгляд, NN гораздо быстрее решают эту задачу, поэтому выбрали решить ее именно таким путем. Будет здорово, если вы сможете показать алгоритм поиска похожих пикселей в многомерном массиве с учетом ранжирования и процентов распределения оттенков, который доказывает обратное.
Добрый день! Это равнозначные термины. На практике в части PostgreSQL чаще используют понятие секционирование, а в части Apache Hive – партиционирование. В статье указано, что партиционирование еще может называться секционированием.
Добрый день! Верно, задача аппроксимации может быть решена с использованием сторонних библиотек. R или Python как раз те языки, где есть библиотеки, предоставляющие такие решения. Если вас больше устраивает такой вариант, конечно, им можно пользоваться, тем более, что вам ближе R или Python, чем SQL. Но стоит остановиться на ряде недостатков такого подхода:
1) SQL-решение может быть (возможно, с небольшими доработками) перенесено практически на любой тип базы (Oracle, MS SQL, SAP и т.д.). Возможно ли его так же легко перенести со сторонними библиотеками? Скорее – нет;
2) Производительность – не самая сильная сторона R или Python. Сможет ли ваше решение работать с такой же производительностью, как SQL-запрос? Здесь могут быть сомнения;
3) Установка дополнительных библиотек – не всегда простая задача. Если вам доводилось работать в крупных организациях, то на согласование и установку библиотек уйдут месяцы;
4) По поводу того, что нельзя/сложно апроксимировать периодическую функцию: ряд Фурье считается SQL-ем практически так же, как и другим языком;
5) Какой код легче читать – здесь, как нам кажется, дело вкуса и привычки.
Добрый день! Рассмотренная в статье зависимость (количество Интернет-пользователей от времени) – это всего лишь один из возможных примеров. Предложенный вариант решения носит универсальный характер, то есть подходит под любой пример. По этой причине рассматриваются все варианты аппроксимации, даже если они заведомо плохо описывают конкретный пример (есть вероятность, что другой пример опишет как раз та аппроксимация, которая не дала хорошего согласия в нашем случае). Вариант степенной регрессии записан в виде y=ax^b. Надо понимать, что мало записать функцию произвольного вида, следующим шагом необходимо решить уравнения методом МНК, а это накладывает существенные ограничения. Не каждая система уравнений может быть решена аналитически. Как раз это и мешало добавить дополнительное слагаемое - с в уравнение (добавить можно, но решить нельзя). Для улучшения аппроксимации можно переопределить систему координат, и об этом говорится в статье. График функции 21 - y=b/x – это гипербола.
Если смотреть глубже - да, инструменты заточены под решение разных задач. Но в данном случае рассматривается конкретная задача, которая может быть решена обоими способами. Суть задачи максимально упрощена. Необходимо было показать - что могут предложить эти инструменты.
Уже в дальнейшем, исходя из бизнес-задач, которые могут возникать, мы можем здраво оценить, что будет предпочтительнее выбрать.
Ну и опять же - обработка ошибок, алертинг... не-еет
Тема данной статьи не связана с обработкой ошибок, настройкой алертинга и т. д. Эти вещи, безусловно, необходимы, но в текущей статье не требуют разработки и упоминания.
1. «NULL ≠ 0 - если это поле числового типа, то он вполне себе число»
Вы смешиваете тип данных и значение. Да, поле имеет числовой тип, но само значение NULL не является числом в математическом смысле. Это маркер отсутствия числа в данном поле.
2. «FALSE AND UNKNOWN = FALSE - вполне себе интуитивно»
Тут сложно спорить, все индивидуально) Интуитивно для тех, кто знает теорию множеств и булеву алгебру. А новичок часто видит UNKNOWN и думает: «Ну, раз неизвестно, то и результат должен быть неизвестен». А тут вдруг FALSE.
3. «WHERE требует TRUE, CHECK требует что угодно, лишь бы не FALSE».
Вопрос формулировок. Надеюсь, это замечание окончательно закрепит понимание этого важного нюанса)
4. «SUM, AVG игнорируют NULL - надо оговорить, что возвращают NULL, если все NULL»
Да, это следует из определения агрегации. Если нет значений - нечего суммировать.
5. «В MySQL есть <=> они не единственные»
IS NOT DISTINCT FROM(как и его "обратная" версияIS DISTINCT FROM) – включен в стандарт ANSI SQL. В то же время MySQL и MariaDB реализуют ту же логику через свой собственный оператор<=>, который не является стандартным, и при миграции кода может вызвать проблемы.6. «NOT EXISTS - неуниверсально, может убить план»
Этот пункт конкретно про рекомендацию против логической ошибки с NULL и NOT IN, а не как догма для всех случаев. План выполнения не имеет значения, если результат неверный. Про эту тему можно добавить:
· Современные оптимизаторы (PostgreSQL, Oracle, SQL Server) умеют преобразовывать NOT EXISTS в анти-соединения и хеш-соединения, если это выгодно (не всегда и не все). В любом случае необходимо смотреть план выполнения в каждом запросе, а не следовать бездумно общим рекомендациям.
· Если подзапрос некоррелированный, его можно вынести в CTE или материализовать, или решить другим способом. Это вопрос не навыка работы с NULL.
В любом случае, мы рады что эта тема вызвала Ваш интерес. Ваши замечания, надеемся, катализирует читателя глубже разбирать формулировки и крайние случаи.
Отдельные люди под NEOMSA обычно не нужны. Достаточно команды, которая уже эксплуатирует любую инфраструктурную или интеграционную платформу.
Базовое: Kubernetes, Linux, сети, сертификаты, мониторинг, логи, обновления, бэкапы. Специфика API management: политики, авторизация, квоты, версии API, интеграции с внутренними системами. Как правило у тех, кто вообще дошёл до вопроса про APIM, всё это уже есть.
Разбираться в устройстве самой платформы при этом не нужно. Настраивать API, политики и доступы, следить за работой, обновлять по инструкции это делает команда заказчика. А если что-то ломается внутри самого продукта или выходит уязвимость, это уже к нам.
Спасибо за замечание. Мы как раз не пытаемся скрывать корни нашей кодовой базы или делать вид, что этого фактора не существует. Напротив, для enterprise-продукта критически важно честно понимать, откуда он вырос, какие риски это за собой несёт и как именно эти риски минимизируются.
В случае с NEOMSA мы точно не ограничились подходом «взяли WSO2 и просто переупаковали». Наша команда провела глубокий аудит и устранение уязвимостей, доработала продуктовую часть и успешно прошла проверку РБПО. Безопасность, сопровождение и контроль кода для нас — не теоретический пункт в сравнительной таблице, а реальная практическая зона ответственности.
Итог простой: происхождение платформы, безусловно, важно. Но не менее важно то, выстроил ли вендор понятный процесс работы с этим наследием, закрывает ли уязвимости и способен ли развивать продукт в долгосрочной перспективе.
Если вам интересно подробнее узнать, как всё это устроено внутри NEOMSA, напишите нам на почту neomsa@neoflex.ru — детально расскажем, что именно мы изменили и как сопровождаем продукт сейчас.
На практике, защита персональных данных строится вокруг известных систем хранения и формально описанных потоков данных. Однако по мере роста и развития бизнеса, появляются дополнительные копии данных — в аналитических хранилищах, тестовых средах, логах и интеграционных пайплайнах. Поэтому деперсонализация становится важным механизмом снижения риска, она позволяет использовать данные в разработке и аналитике без распространения персональной информации.
Наша система позволяет отслеживать изменения в структуре данных - появление новых таблиц/полей и маскирует их по умолчанию, оповещая об изменения ответственных лиц.
Исходя из нашего проектного опыта, полностью синтетические данные хорошо подходят для изолированных тестов, но редко воспроизводят сложную структуру и взаимосвязи реальных данных. Например у пользователя может быть связь между валютой, страной, типом аккаунта. Синтетический генератор легко создаст статистически похожие данные, но не сохранит реальные взаимосвязи. На наш взгляд, деперсонализация позволяет сохранить структуру данных и при тестировании можно найти редкие кейсы, о которых ранее не упомянул заказчик при обсуждении ТЗ.
С учетом того, что бизнес-процесс был изначально устроен так, что по одному клиенту мог проводиться только один платеж в день выбор ключа PRIMARY KEY (client_name, payment_date) очевиден. И при возврате вернется именно тот платеж, который был совершен в эту дату этим клиентом.
Упоминаемые недостатки (размер, сложность, предсказуемость) действительно не являются приговором. В статье подсвечиваются риски того, что может быть. Спорить можно только о вероятности появления этого риска. Укажите, пожалуйста, на конкретное утверждение, которое, по вашему мнению, неверно в принципе и такого "не может быть никогда" - мы с благодарностью изучим этот вопрос, возможно и нам это принесет новые знания.
Хотелось бы передать многообразие ключей и причины их появления, поэтому про интеграцию систем и эффективность потоков данных, как раз следующий DWH уровень.
Этот пример это и показывает. Помимо того, что любой SEQUENCE не гарантирует непрерывность числового ряда. Например, при откате транзакции полученное значение теряется безвозвратно. Но даже в "идеальном мире" — без единого отката — использование CASHE - основная причина разрывов.
Большое спасибо за ваш отклик! Вы абсолютно правы. Мы использовали абстрактные примеры для наглядности, но вы точно подметили ключевое различие: например в ритейле с микросервисной архитектурой, а не 1-2 источниками, как в нашем примере, Data Vault оказывается гораздо более жизнеспособным и гибким выбором на долгосрочную перспективу благодаря своей масштабируемости и адаптивности к частым изменениям.
Безусловно, мы высоко ценим современные инструменты управления данными, такие как возможности различных БД, Data Quality решения, Data Catalog и др. Мы активно применяем их в своей работе. Однако в реальных проектах не всегда есть идеальные условия.
Добрый день! Хотели бы отметить, что запросов, касающихся того, чтобы сделать OLAP с той же функциональностью, как был в MS, к нам поступает достаточно много. На ClickHouse зачастую переходить не хотят, и в Exel модели на MDX не покрутишь, поэтому и возникают идеи насчет Kylin / eMondrian
Ну, собственно, о Visiology в статье упомянуто.
Добрый день! На наш взгляд, NN гораздо быстрее решают эту задачу, поэтому выбрали решить ее именно таким путем. Будет здорово, если вы сможете показать алгоритм поиска похожих пикселей в многомерном массиве с учетом ранжирования и процентов распределения оттенков, который доказывает обратное.
Добрый день! Это равнозначные термины. На практике в части PostgreSQL чаще используют понятие секционирование, а в части Apache Hive – партиционирование. В статье указано, что партиционирование еще может называться секционированием.
Добрый день! Для просмотра структуры определенной таблицы, можно сделать выборку из системного представления pg_catalog.pg_partitions
SELECT partitiontablename, partitionname, partitiontype, partitionlevel, partitionrankFROM pg_catalog.pg_partitionsWHERE schemaname = '<schema_name>'AND tablename = '<table_name>';Добрый день! Верно, задача аппроксимации может быть решена с использованием сторонних библиотек. R или Python как раз те языки, где есть библиотеки, предоставляющие такие решения. Если вас больше устраивает такой вариант, конечно, им можно пользоваться, тем более, что вам ближе R или Python, чем SQL. Но стоит остановиться на ряде недостатков такого подхода:
1) SQL-решение может быть (возможно, с небольшими доработками) перенесено практически на любой тип базы (Oracle, MS SQL, SAP и т.д.). Возможно ли его так же легко перенести со сторонними библиотеками? Скорее – нет;
2) Производительность – не самая сильная сторона R или Python. Сможет ли ваше решение работать с такой же производительностью, как SQL-запрос? Здесь могут быть сомнения;
3) Установка дополнительных библиотек – не всегда простая задача. Если вам доводилось работать в крупных организациях, то на согласование и установку библиотек уйдут месяцы;
4) По поводу того, что нельзя/сложно апроксимировать периодическую функцию: ряд Фурье считается SQL-ем практически так же, как и другим языком;
5) Какой код легче читать – здесь, как нам кажется, дело вкуса и привычки.
Добрый день! Рассмотренная в статье зависимость (количество Интернет-пользователей от времени) – это всего лишь один из возможных примеров. Предложенный вариант решения носит универсальный характер, то есть подходит под любой пример. По этой причине рассматриваются все варианты аппроксимации, даже если они заведомо плохо описывают конкретный пример (есть вероятность, что другой пример опишет как раз та аппроксимация, которая не дала хорошего согласия в нашем случае). Вариант степенной регрессии записан в виде y=ax^b. Надо понимать, что мало записать функцию произвольного вида, следующим шагом необходимо решить уравнения методом МНК, а это накладывает существенные ограничения. Не каждая система уравнений может быть решена аналитически. Как раз это и мешало добавить дополнительное слагаемое - с в уравнение (добавить можно, но решить нельзя). Для улучшения аппроксимации можно переопределить систему координат, и об этом говорится в статье. График функции 21 - y=b/x – это гипербола.
Здравствуйте, да, можно запустить CMAK из контейнера Docker, однако, такой задачи не стояло.
Если смотреть глубже - да, инструменты заточены под решение разных задач. Но в данном случае рассматривается конкретная задача, которая может быть решена обоими способами. Суть задачи максимально упрощена. Необходимо было показать - что могут предложить эти инструменты.
Уже в дальнейшем, исходя из бизнес-задач, которые могут возникать, мы можем здраво оценить, что будет предпочтительнее выбрать.
Тема данной статьи не связана с обработкой ошибок, настройкой алертинга и т. д. Эти вещи, безусловно, необходимы, но в текущей статье не требуют разработки и упоминания.