forced, у Саги и Микросервисов - полно недостатков. Но этот стек является следующим витком эволюции в направлении слабо-связных систем. Такими системами например будут являться элементы космической связи. Это там где законы физики диктуют нам архитектуры. Нельзя построить ACID систему где узлы БД будут стоять на земле и на Луне. Это не работает. Такова физика этих процессов. И в эпоху освоения космоса и развития IOT мы все больше будем строить системы которые слабо связаны. У них не будет глобальной блокировки или глобальной траназкции. Нам придется работать в условиях отсутствия синхронизации. В условиях остуствия единых часов. В условиях когда сетевой пакет может быть просто потерян. Или сетка будет недоступная. Таков реальный мир.
Если у тебя стек и железо позволяет - бери спокойно монолит. Бери и не парься. И плевать тебе на Сагу.
miketayson, что продумано? Даже сейчас общаясь в хабре ты не видишь где за учетками сидят люди в погонах. Неужели ты думаешь что сидя за 10 торами ты как-то решил этот вопрос?
Мы живем в мире людей. И в каких-бы торах ты не сидел, рано или поздно ты начнешь либо зарабатывать либо обналичивать. И в этот момент ты все равно выходишь на некий левел взаимодействия с людьми в обстановке нулевого доверия.
Без чего "всего"? Отправка СМС - это необратимая операция. Ей нельзя сделать Rollback.
Что с монолитом что с микросервисом.
Видимо ты слишком рано отправил ее. Или не с тем смыслом. Пересмотри
этот flow. Если СМС о том что товар оплачен и доставлен - то это слишком сложно.
Разбей на 2 статуса. Сначала СМС о том что оплачен. И потом что доставлен на склад.
Justa Gain, с другой стороны если делать это действие в контейнерах - то пофиг на безопасность. База - бабочка однодневка. Создается только для тестов на несколько минут. Потом убивается без следов.
Я думаю что он не утекал. Он был сгенерирован или ошибочно прилинкован.
Сильно беспокоиться я-бы по этому поводу не стал. В конце концов если ты раз в жизни заказывал такси
или пиццу по телефону то считай что тебя уже 100 раз слили и парни в черных капюшенах и белых масках
уже давно продали твой профайл.
Лучше наверное не смешивать нотификацию и отчет. Я так рассуждаю. Если в пятницу вечером осталось менее 10%
диска - то можно прислать просто alert в ящик и во все социальные сети. А потом уже пускай люди разбираются
в понедельник если нужно. Строят отчеты и всякую инфо-графику. Как говориться дорогА ложка к обеду.
У меня нет ссылок на онлайн конвертеры. Но если тебе надо до пикселов сохранить оригинальный дизайн
то можно распечатать документ в картинки (там есть специальный виртуальный принтер) и дальше уже
их конвертить в pdf чем угодно. Тогда контент будет сохранен.
1) 5 Мегабайт это ниочем. Это какой-то учебный размер на котором можно учить школьников.
По идее все данные ложаться в страничный кеш и мы могли-бы исключить влияние дисков.
2) Со своего опыта работы с реляционками. Мне никогда не удавалось добиться гарантий
времени отклика для запросов которые содержали orderby, group, distinct. Эти ключевые
слова - враги стабилизаци времени отклика. Хотя можно стабилизировать план но трудно
стабилизировать сами данные. Вы никогда Не знаете как пойдет бизнес. Сколько завтра
зайдет строк за день. Сегодя 1000. Завтра 100 000 а через месяц зайдут миллионы. И время
отклика не линейно от объема. (Это бизнес думает что оно линейно) а мы то знаем
что там не то что полином а там бывают всякие эффекты. График - ломаная линия выходит.
Как работает этот disctinct on. Напомните пожалуйста. Выбирается самый последний imei по дате
с атрибутами?
SELECT distinct on (imei) * FROM locations WHERE imei IN (…) order by imei, dt desc
Может индекс здесь и помогает чорт его знает. Но я-бы "двигал" этот запрос в сторону key-value.
Взял IMEI. Получил все его последний снапшот. И все. И никаких исторических сканов. История
пускай будет но нам нужно нечто быстрое как редис.
3) Игры с ребилдом индекса я вообще никак не могу комментировать. Это не supportable система.
Нужно делать так чтобы индекс был стационарный и все нормально работало.
4) Вы используете IN (867232054978003, 867232054980835...). Это динамический запрос? Может
сделать с bind-variables и может лучше дернуть 20 раз по 1 EMAI с готовым запросом чем каждый
раз вызывать оптимизатор для 1 запроса с 20 EMAI. Это я не знаю ответа. Надо просто
поставить эксперимент.
Карлиндоу Мэрлифи, твой метод похож на Атаку на основе подобранного открытого текста.
Ищи зависимости. Действительно ли 1 символ (или байт) шифро-текста соотвествует тому
что показывает Чарльз.
Мне кажется у всего гибкого есть одна большая проблема. Механические повреждения. Каждый раз когда ты сгибаешь что-то сильно - то синтетика гнется а кристаллическая решетка металлов ломается. В ней появляются микро-трещины. Для кабелеей например который идут к наушникам появляется шорох и треск. Это как раз такие микро-трещины рвут электический контакт. Тоже самое скорее всего будет относиться к дисплеям типа E-Ink и прочее. Они обязаны в себе содержать электрические проводники.
Anonymous, хорошо. Для человека лучше брать распределение Гаусса. С мат-ожиданием
в точке 00:30 (пол первого ночи) и со средним квадратическим отклонением 97%
(три сигмы) где-то в один час. Раз уж ты так решил. Типа один сеанс работы человека
не превышает час. Обычно.
Карлиндоу Мэрлифи, сохрани его в файл (безо всяких попыток рассматривать его текстом).
И потом открой этот файл в Hex редакторе. Обычно по первым 4-8 байтам можно определить
тип содержимого. Например если первые байты равны
CA FE BA BE ....
То это бинарник Java-class файла. Если первые байты в ASCII коде равны %PNG то это
картинка. И так далее.
Но в общем это вопрос не ко мне а к тебе. Если ты решил поиграть в юного криптоаналитика
то будь готов работать с неизвестной двоичной информацией где всякие декодеры Лебедева
тебе никогда не помогут.
Надеюсь ты понимешь что в pom-based проекте Idea вообще не главная. Она - вторичная. Главное чтоб maven сценарии отработали. И еще главное - выбрать правильный архетип. Тебе точно нужен archetype-web?
Если у тебя стек и железо позволяет - бери спокойно монолит. Бери и не парься. И плевать тебе на Сагу.