Да работает. Именно этого не хватает в presto от которого форкнули trino его фактические разработчики после ухода из фб
Но функции работы с ним нет. У trino есть для этого свои методы работы с json. То есть фактически работает но после перекачки на сторону trino. Если select с фильтром по полю jsonb то будет медленно так как будут извлекаться все данные из postgres.
Но другие кроме trino движки jsonb даже прочитать не могут
Я в одном из проектов использую Prest/Trino. Мотивация была такая что нужно было делать запросы к двум базам PostgreSQL. Уже после начала проекта узнал что есть еще Apache Drill и Impala. Но не подошли. Одна потому что не поддерживает нестандартные возможности PostgreSQL (json, enum) другая потому что клиент был только java. Оказалось что Trino для моего кейса удобнее. Trino умеет взаимодействовать и с nosql и длеать практичепски немыслимые кросс-платформенные join. Про calcite ввобще ничего не нахолдил в посиковой выдаче хотя целенапровленно не так давно искал информацию по этой теме.
Ну это такое сильно заидеализщированное представление. В реальной жизни при автоматизации ставили вопрос сколько можно убрать бухгалтеров, технологов и т.п. если купить один компьютер и спрограммой (ответ нисколько) При цифровизации такой вопрос даже не ставится а сразу говорится что нужно прикупить на 7-8 значных цифр программного обеспечения и железа и создать новое управление с не слабым штатом.
Скепсис бизнеса по отношению к цифровизации не случаен. Как не случно и то что господствовашее в прошлом веке слово автоматизация заенила слово цифровизация. Очень показательно это. Никто уже не обещает что будет автоматищировано, а более обтекаемо — будет цифровизовано, а то что это может потребовать не меньше, а больше персонала — это уже подрбоности. Например любой разраотчик ERP может рассказать как будет всем хорошо, если в будет автоматизирован учетдвижения всегда модно будет узнать что и где находится и на какой операции. Но я был свидетелем того что такой проблемы вообще у произволства не существует они и так это знают. (Если кто-то хочет поспорить пусть ответ ит а как это сейчас работет если никто не знает что и где нахзодится). А вот сколько нужно затрат чтобы организовать этот учет никто (с хронометражом и расчетами) на моей памяти не делал. Вспоминается торлиинг автоматизаии в фильме "КОролева бензоколоники"
А это бензоколонка образца 1965 года — автоматическая (ну и дальше ускоренная съемка)
Не даром в отчетах старховых компаний отдача средств клиента на уровне 10% и это не от суммы брутто а от той суммы которая остается после вычета затрат. Интересно кстати возник мало освещаемый вопрос. В дговорах на стразование здровья прописывается что на случай эпидемий возмещение затрат на лечение не произвоится. С точки зрения математики это вроде бы правильно. Ну а вот с точки зрения сохранения жизни? И как тут с короной? Судя по палаткам Нью-Йорке как раз основное тут что ни одна больница имея свободные площади не принимала клентов. Так как стразовка не действует. А денег у клиента на лечение нет.
Решение Google выглядит наиболее странным. Начнем с того что скоринг это уже практически норма для многих банков которые могут давать кредит онлайн.или регистрировать клиентов онлайн. С учётом того что goovle и так все знает о своих кл просп им даже от не нужен в смысле обучения по фото или видео.
Google' и этика. После сбора и использования на продажу всех возможных личных данных.
Сервис по подделке голосов в наше время это примерно как сервис по подделке подписей. Тут уже не этика а уголовщина. Кстати, подобный стартап он реально был и даже возможно был на Хабре как ста ья.
А ков деле распознавание кстати тоже. И это кажется российский стартап и даже запущен где то. Правда распознавание не по лицу а по поведению.
Я работаю со стеком js у на с б блиотеками с популярными все нормально. Реализации адекватные наверное на python тоже есть такие если не попасть случайно на экзотику. Тут скорее речь идёт о том что непонимание того что может и что не может токен приводит к решениям которые выглядят просто неубедительно. Например хранение товаров в базе данных. Или хранение в товаре тол ко идентификатора пользователя. Или вообще идентификатора сессии. Одноразовое использование токена принадлежит к той же серии. Несмотря на повсеместное распрос ранение этой традиции я так и не услышал ни одного убедительного объяснения зачем это нужно. Говорят что так безопасно. Но в чем эта безопасность заключается я так и не понял. Если злоумышленник получил токен точное ему мешает тут же им и воспользоваться?
Вцелом jwt можно рекомендовать к испол доверию во все проектах без исключения. Только сначала нужно просто подумать
>При этом старый refresh заносится в черный список и больше не может быть использован. Обращаться к внешнему хранилищу все-таки надо, но уже не так часто.
Надо четко представлять, что все что связано с refresh token и методы ротации токенов не оределены в стандарте и относятся к категории городского фольклора. Единствекнный смысл ао времени жизни токенов следующий
1) время жизни access токена является периодом для которого в данном конкретном приложении допустимо не перзарашивать данные о пользователе в системе. При этом возникает иногда необзодимостьнемедленного отзыва access токено для чего формируют черный список
2) время жизни refresh токена это собственно время после которого произойдет разлогин клиента если не было активности клиента
Что касается одноразовости refresh токена - в реальном приложении это может привести к багам так как два и более одновременно выполняющихся хароса могут потребовать смены токена при этом только один из них будет успешным. Профит от одноразовости токена весьма сомнительный.
>Как выглядит JWT и как он зашивает с себе всю информацию? Это три закодированные последовательности символов, записанные через точку: в первых двух частях в base64 кодируются два JSON-объекта — заголовок и пользовательские данные; третья генерируется на основе первых двух и секретного ключа — это цифровая подпись. Теперь сам токен в открытом виде содержит всю необходимую информацию для авторизации, а цифровая подпись не позволяет что-то в токене поменять. Когда система принимает запрос, она знает секретный ключ и может сама сгенерировать подпись и проверить, совпадает ли она с тем, что нам передали.
Кодировка на самом деле base64url. Данные могут быть и зашированы, и это реально делают сервисы например google auth2. Для подписи чаще испрользуют криптографию с закрытым и открытым ключом. И как раз для проверки подписи достатоно открытого ключа.
Тут явная неточность перевода. БГ, если отбросить мифологию и теорию заговоров, имел в виду что туалет спасет от последствий перенаселения, выражающуюся в загрязнении природы. Конечно любой школьник скажет что такая радикальная технология очистки будет слишком дорогой. Зачем тогда весь этот пиар? Наверное для пиару.
Ещё раз повторю. Uber когда перешёл на MySql не использовал ее как sql базу данных. Просто как абстрактное хранилище. Просто когда упоминают uber и mysql дальше заголовка их статью никто не читает https://m.habr.com/ru/post/354050/ здесь мой перевод. Они называют это schemaless.
Проблема не в задержке ирндексации а в том что рано или поздно из-за проблем в работе реального сетевого приложения данные рассогласовываются в основной базе и в поисковом индексе. И его приходится принудительно обновлять перечитыванием от начала и до конца. Действительно для магазина среднего это такое малое количество данных что можно этим перенбречь. Но не всегда задачи имеют малый объем. Например один из индексов у меня проходит проверку раз в сутки потому что перебор всех значений занимает 4 часа. И это к сожалению реальная проблема синхронизации. И несколько раз в год бывает негативная обратная связь от клиента что в индексе устаревшие данные.
История с uber и guardian это как раз не частный случай а довольно распространенный. Первпая история о том что sql базы ввиду своей не масштабируемость приводят к необходимости перехода на другие средства. Mysql в uber не используется как sql а фактически как mysql база данных. С guardian поучительная история о том что mongo не самый подходящий стек для 99% случаев где ее сейчас используют.
Все хорошо до первого инцидента.
Могу подтвердить так как испольшовнаие ктнтейнера на проде привело один раз к разрушению базы данных, после этого больше нет желания повторить опыт.
Да работает. Именно этого не хватает в presto от которого форкнули trino его фактические разработчики после ухода из фб
Но функции работы с ним нет. У trino есть для этого свои методы работы с json. То есть фактически работает но после перекачки на сторону trino. Если select с фильтром по полю jsonb то будет медленно так как будут извлекаться все данные из postgres.
Но другие кроме trino движки jsonb даже прочитать не могут
Я в одном из проектов использую Prest/Trino. Мотивация была такая что нужно было делать запросы к двум базам PostgreSQL. Уже после начала проекта узнал что есть еще Apache Drill и Impala. Но не подошли. Одна потому что не поддерживает нестандартные возможности PostgreSQL (json, enum) другая потому что клиент был только java. Оказалось что Trino для моего кейса удобнее. Trino умеет взаимодействовать и с nosql и длеать практичепски немыслимые кросс-платформенные join.
Про calcite ввобще ничего не нахолдил в посиковой выдаче хотя целенапровленно не так давно искал информацию по этой теме.
Ну это такое сильно заидеализщированное представление. В реальной жизни при автоматизации ставили вопрос сколько можно убрать бухгалтеров, технологов и т.п. если купить один компьютер и спрограммой (ответ нисколько) При цифровизации такой вопрос даже не ставится а сразу говорится что нужно прикупить на 7-8 значных цифр программного обеспечения и железа и создать новое управление с не слабым штатом.
С точки зрения молотка все проблемы это гвозди. С точки цифровой компании все решения цифровые.
Скепсис бизнеса по отношению к цифровизации не случаен. Как не случно и то что господствовашее в прошлом веке слово автоматизация заенила слово цифровизация. Очень показательно это. Никто уже не обещает что будет автоматищировано, а более обтекаемо — будет цифровизовано, а то что это может потребовать не меньше, а больше персонала — это уже подрбоности. Например любой разраотчик ERP может рассказать как будет всем хорошо, если в будет автоматизирован учетдвижения всегда модно будет узнать что и где находится и на какой операции. Но я был свидетелем того что такой проблемы вообще у произволства не существует они и так это знают. (Если кто-то хочет поспорить пусть ответ ит а как это сейчас работет если никто не знает что и где нахзодится). А вот сколько нужно затрат чтобы организовать этот учет никто (с хронометражом и расчетами) на моей памяти не делал. Вспоминается торлиинг автоматизаии в фильме "КОролева бензоколоники"
Не даром в отчетах старховых компаний отдача средств клиента на уровне 10% и это не от суммы брутто а от той суммы которая остается после вычета затрат. Интересно кстати возник мало освещаемый вопрос. В дговорах на стразование здровья прописывается что на случай эпидемий возмещение затрат на лечение не произвоится. С точки зрения математики это вроде бы правильно. Ну а вот с точки зрения сохранения жизни? И как тут с короной? Судя по палаткам Нью-Йорке как раз основное тут что ни одна больница имея свободные площади не принимала клентов. Так как стразовка не действует. А денег у клиента на лечение нет.
Решение Google выглядит наиболее странным. Начнем с того что скоринг это уже практически норма для многих банков которые могут давать кредит онлайн.или регистрировать клиентов онлайн. С учётом того что goovle и так все знает о своих кл просп им даже от не нужен в смысле обучения по фото или видео.
Google' и этика. После сбора и использования на продажу всех возможных личных данных.
Сервис по подделке голосов в наше время это примерно как сервис по подделке подписей. Тут уже не этика а уголовщина. Кстати, подобный стартап он реально был и даже возможно был на Хабре как ста ья.
А ков деле распознавание кстати тоже. И это кажется российский стартап и даже запущен где то. Правда распознавание не по лицу а по поведению.
Этично ли помогать остановить пандемию?
Я работаю со стеком js у на с б блиотеками с популярными все нормально. Реализации адекватные наверное на python тоже есть такие если не попасть случайно на экзотику. Тут скорее речь идёт о том что непонимание того что может и что не может токен приводит к решениям которые выглядят просто неубедительно. Например хранение товаров в базе данных. Или хранение в товаре тол ко идентификатора пользователя. Или вообще идентификатора сессии. Одноразовое использование токена принадлежит к той же серии. Несмотря на повсеместное распрос ранение этой традиции я так и не услышал ни одного убедительного объяснения зачем это нужно. Говорят что так безопасно. Но в чем эта безопасность заключается я так и не понял. Если злоумышленник получил токен точное ему мешает тут же им и воспользоваться?
Вцелом jwt можно рекомендовать к испол доверию во все проектах без исключения. Только сначала нужно просто подумать
>При этом старый refresh заносится в черный список и больше не может быть использован. Обращаться к внешнему хранилищу все-таки надо, но уже не так часто.
Надо четко представлять, что все что связано с refresh token и методы ротации токенов не оределены в стандарте и относятся к категории городского фольклора. Единствекнный смысл ао времени жизни токенов следующий
1) время жизни access токена является периодом для которого в данном конкретном приложении допустимо не перзарашивать данные о пользователе в системе. При этом возникает иногда необзодимостьнемедленного отзыва access токено для чего формируют черный список
2) время жизни refresh токена это собственно время после которого произойдет разлогин клиента если не было активности клиента
Что касается одноразовости refresh токена - в реальном приложении это может привести к багам так как два и более одновременно выполняющихся хароса могут потребовать смены токена при этом только один из них будет успешным. Профит от одноразовости токена весьма сомнительный.
>Как выглядит JWT и как он зашивает с себе всю информацию? Это три закодированные последовательности символов, записанные через точку: в первых двух частях в base64 кодируются два JSON-объекта — заголовок и пользовательские данные; третья генерируется на основе первых двух и секретного ключа — это цифровая подпись. Теперь сам токен в открытом виде содержит всю необходимую информацию для авторизации, а цифровая подпись не позволяет что-то в токене поменять. Когда система принимает запрос, она знает секретный ключ и может сама сгенерировать подпись и проверить, совпадает ли она с тем, что нам передали.
Кодировка на самом деле base64url. Данные могут быть и зашированы, и это реально делают сервисы например google auth2. Для подписи чаще испрользуют криптографию с закрытым и открытым ключом. И как раз для проверки подписи достатоно открытого ключа.
Тут явная неточность перевода. БГ, если отбросить мифологию и теорию заговоров, имел в виду что туалет спасет от последствий перенаселения, выражающуюся в загрязнении природы. Конечно любой школьник скажет что такая радикальная технология очистки будет слишком дорогой. Зачем тогда весь этот пиар? Наверное для пиару.
>>презентовал туалет, призванный помочь Индии и другим странам с проблемой перенаселения
Звучит зловеще.
Вы упомянули о сложностях деплоя. Все жто ничего по стравнению со сложностью тестированрия и отладки новой библиотеки.
Все это хорошо. Но например я всегда воспринимал Next.js как фреймворк для фронтенда. Это точно хорошая идея разрабатывать не нем API?
Ещё раз повторю. Uber когда перешёл на MySql не использовал ее как sql базу данных. Просто как абстрактное хранилище. Просто когда упоминают uber и mysql дальше заголовка их статью никто не читает https://m.habr.com/ru/post/354050/ здесь мой перевод. Они называют это schemaless.
Проблема не в задержке ирндексации а в том что рано или поздно из-за проблем в работе реального сетевого приложения данные рассогласовываются в основной базе и в поисковом индексе. И его приходится принудительно обновлять перечитыванием от начала и до конца. Действительно для магазина среднего это такое малое количество данных что можно этим перенбречь. Но не всегда задачи имеют малый объем. Например один из индексов у меня проходит проверку раз в сутки потому что перебор всех значений занимает 4 часа. И это к сожалению реальная проблема синхронизации. И несколько раз в год бывает негативная обратная связь от клиента что в индексе устаревшие данные.
История с uber и guardian это как раз не частный случай а довольно распространенный. Первпая история о том что sql базы ввиду своей не масштабируемость приводят к необходимости перехода на другие средства. Mysql в uber не используется как sql а фактически как mysql база данных. С guardian поучительная история о том что mongo не самый подходящий стек для 99% случаев где ее сейчас используют.