Comments 68
Статья показывает, что как не надо было делать и почему нельзя соглашаться исправлять косяки других)
Вся проблема в том что, изначально всё неправильно было создано и главный гемор это excel. Тут даже и web технологии мало помогут. Проще всё взять переделать и упростить. Но на это никто не пойдёт придётся делать рефакторинг бизнеса. Но при глобальной схеме бизнес процессов их можно и нужно упрощать, создовать свой универсальный стандарт, который позволит масштабировать систему и скорее всего менять БД sql на объектную. А так сплошные заплатки, эксперементы и прочая лабуда, показывающая ковыряние супер пупер синьора. А нужен был обычный кризис программер, который бы не ковырял старые развалины кое-как работающего кода и кое как работающего БД. Изначально надо было строить схему и это должен был сделать бизнес аналитик, а тот просто пошёл на поводу и собирал всё хотелки пользователей. Проблема в том что работа в команде, а команда как рак, лебедь и щука. Поэтому глобально с задаче никто не работал и думаю вся эта работа нацелена на то как сделать работу куче специалистов и не дай бог никого не уволить и сохранить бюджет. И это тупо для тех кто работает в больших конторах и это нравится никого не уволили и при этом денег потрачено желательно чем больше тем лучьше. На какой нибудь no-code вся эта система была бы переписана и запилена с встроенно no sql СУБД за пару месяцев типа VisualData или таже банальная delphi на проостом фреймворке даже с sql СУБД. Зная тот же dev express эта такая неоптимизированная grid система что и не удивительно. Проще ehlib хоть и не панацея.
Офигительнейше, очень приятный язык.
Хотел спросить, для тех, кто не знает C# и Linq, что такое Include() ? Выглядит как join.
И ещё: я правильно понял, что причина тормозов в том, что драйвер оракловского протокола работает синхронно: заказывает fetchSize строк, и пока все не отдаст приложению, новые не запросит? И канал у вас был с большой latency, в которую, при таком протоколе, оно и упиралось, при том что пропускная способность позволяла, и вы это обошли тем, что gRPC хорошо умеет в стриминг? А fetchSize нельзя подкрутить?
Я полагаю что в данном случае include подгружает записи за один запрос, что бы избежать потом n+1
Спасибо. Include это не совсем join. Да, он транслируется в left join, но может работать только по внешнему ключу (в случае с OrmFactory ещё и по виртуальному внешнему ключу). То есть его условие вшито в модель.
Про причину тормозов я так и не узнал. Тогда я крутил всё, что крутилось на клиенте, а сейчас мне уже не актуально.
То, что смена протокола (добавление gRPC на участке с задержкой) увеличила скорость - я этот эксперимент буквально вчера повторил. Да, похоже на то, что протокол оракла ждёт подтверждения (или запроса) со стороны клиента. Но как действительно это работает - я не знаю.
Полностью поддерживаю, что стоило провести эксперименты с fetch size. Это первое, что приходит в голову при чтении статьи.
Я тоже полностью поддерживаю! Стоило!
Именно поэтому я и эксперементировал с фетч сайзом. Я вообще крутил всё, до чего мог дотянуться. А дотянуться я не мог разве что до настроек самого инстанса оракла.
А сейчас мне это не интересно. Я не работаю в этой компании полтора года как. Ну узнаю я, как это можно было починить, а что дальше? Статья вообще не об этом.
В некоторых БД индексы просто отваливаются (не из-за фрагментации).
Всегда проверяйте Include (сколько их).
И сколько данных (в мегабайтах) возвращаете (с БД и с сервера через свой api).
include 10 элементов, связанных с 10 элементами это уже увеличение объёма данных в 100 раз. (вместо 100 кб за мс пришло 10 мегабайт за 2 секунды. Просто потому что у вас не RAID-6 на SSD, и еще 10 таких же запросов)
Поэтому обычно используют 2 маппинга - 1 облегченный на грид, второй - на полный обьект (в карточку обьекта)
Ха. В той системе инклюды 1:М упаковывались в объекты перед передачей. Если классический селект повторил бы левую таблицу N раз, то в протобуфе был типизированный объект, где левая сущность была в одном экземпляре, а правая (множество) в своём списке в поле левой сущности.
То есть от БД до сервера трафик был в сто раз больше, а при передаче в клиент как положено, без оверхеда.
Там была единственная проблема - нужен был OrderBy по полю для джойна для асинхронной передачи таких объектов. Просто потому что ORM нужно было понять, что вот этот левый объект уже заполнен и его можно отправлять на клиента.
Да, вы учтите, что у вас HDD читает дай бог 100 Мб\сек (если это не Raid-6 SSD).
Это - пиковая теоретическая скорость.
В реальности с БД может прилетать по 10-100 Мб.
Даже если эти 100 Мб и упаковываются в обьект - это уже секунда-другая только на работу EF.
Т.е. при 10 связанных объектах с еще 10 объектами вам просто придет в 100 раз больше строк (с полями основного и связанных объектов)
И есть подозрение что где-то что-то все-таки материализуется (при работе с IQueryable).
Не смотрели
https://github.com/esskar/Serialize.Linq
Делал то же самое, только в backend Web Api.
Сделал автогенерацию обьектов для поиска по сущностям (через И), и автогенерацию фильтров.
Для поиска обычно не нужны сложные условия (все через И).
Ну и конечные точки (без include) - CRUD, поиск.
Год - многовато.
А, ну и зачем аж целый протокол городить-то?
Лишняя безопасность?
Подключайтесь сразу к БД через VPN, выполняйте SQL запросы.
Так я же всю статью об этом говорил. Там даже отдельная глава есть "Тормоза", ещё есть "Почему ORM". В статье описано, почему трёхзвенка. Я описывал задачи. Ну прочитайте хотя бы заголовок, а дальше перейдём к более тонким материям.
Да, я вам уже написал что вам надо смотреть объём данных, планы запросов
https://habr.com/ru/articles/922672/#comment_28497376
Ниже пишут - еще и канал оказывает влияние. Да и в UI нигде нет больше 20-50 строк на странице, но мало ли.
https://habr.com/ru/articles/922672/#comment_28498602
За использование кодогенерации +.
Я специально выбирал табличку, чтобы получить объём данных. Зачем мне его смотреть?
Какой план запроса может быть у select * from table where rownum <= 8000?
Каналы пробовали все доступные.
Да и в UI нигде нет больше 20-50 строк на странице, но мало ли.
А вы там работали? Таблицу на сто тысяч строк и 50 колонок не хотите? А заполнение комбобокса на 6000 подсказок?
А пагинацию зачем придумали?
(Да ограничивать объем данных, чтобы по 1-100 мегабайт не гонять в том же веб-е)
А зачем делают различные маппинги (Лайт и фулл)?
(Да та же причина - основных полей дай бог половина, по которым идет работа и которые смотрят в гриде. Остальное идет в карточку обьекта)
Это - базовые принципы, на которых работает всё.
Даже поиск\автозаполнение - нашел 1000 элементов, вывел первые 10
А пагинацию зачем придумали?
Я не буду здесь приводить ответ манагеров на предложение сделать пагинацию. Иначе меня за сквернословие забанят.
Работа у них такая. Такие массивы данных. Им вот НАДО. Понимаете?
К слову, мой ORM вполне себе умел в пагинацию. В статье есть реализация трансляции Take/Skip.
Если менеджеры не понимают что такое пагинация и почему она необходима - значит это некомпетентные менеджеры.
Итог вы даже в статье описали - сокращения.
Обычно тривиальные вещи с неграмотным менеджментом лечатся вопросом "И где ты такое видел?"
Вы не High-end делаете (и вам не нужен оффлайн-кэш БД и подгрузка Diff-ов).
Вы сейчас примеряете общей гребёнкой весь бизнес. Не надо так. Есть действительно необходимость работать с большими данными из-за специфики. Когда у тебя десятки магазинов по всей стране, в 25 строчек ты не влезешь тупо списком магазинов. А есть категории, поставки, остатки и ещё много чего другого.
Не надо называть людей некомпетентными, когда вы просто не понимаете, в чём их работа состоит.
Вообще, это элементарные (базовые) вещи.
Т.е. определять, что не нужно показывать все 100 тысяч сообщений на форуме в веб-е научились очень давно.
Как раз по причине задержек из-за объема данных.
Пагинация - Это используют даже ребята из Google(!).
Веб, как и WPF/Winforms - только лишь UI, который по API что-то получает. Т.е. принцип тот же.
Хранить (кэшировать) объект и писать команды (и доставать недостающие их по RowVersion, и применять их к объекту) - тоже не сложно. (Гугл-таблицы и прочие карты).
Вот сидит манагер с большой таблицей. Ему нужно разобраться с аномалией, почему не складывается прибыль. Он группирует по товарной категории, сортирует по продажам и глазами пробегает, зажимая PgDown. Иногда меняет колонки местами, иногда подкручивает параметры вспомогательные. Он ищет места, где происходят аномальные скачки. Потом сверяет с датами, потом с другими категориями. Потом с остатками. Когда ему кажется, что он вроде нашёл - меняет группировку, сортировку и начинает выискивать, уже зная, где искать.
Манагер находит проблему и описывает её в бизнес терминах. Он хороший манагер, он за три часа делает то, на что отделу разработки понадобится два месяца. С написанием ТЗ, согласованиями, уточнениями, тестированием и приёмкой.
Идите и скажите ему, что он некомпетентный и не знает элементарные базовые вещи.
Хотите сказать что он глазами пробегает сразу по 100000 записей, тратя меньше 100мс на посмотреть/оценить запись?
Гораздо быстрее. Я сам видел, как они работают.
В подозрительных местах останавливаются, рассматривают детальнее. В каких-то местах идут медленнее, где-то проматывают.
Это натренированная годами на продажах нейросеть. Там используются такие параметры, о которых вы даже не подозревали, как погода на прошлой неделе в Воронеже. Только не спрашивайте, как это влияет на продажу плащей и зонтиков. Я не знаю.
Вот прямо Infinite Scroll в руку.
И 2 маппинга
https://habr.com/ru/articles/922672/comments/#comment_28497376
Дружище. Ну вот зачем ты это говно советуешь?
Зачем ты вообще пытаешься починить систему, которая почти два года не актуальна?
Ты хочешь сказать, что я плохие варианты выбирал и есть лучше? Но прости, ты не в курсе тысячи нюансов. Ты не в курсе, что я не пишу веб. Потому что не читал статью, где я про это говорил. Ты не в курсе, что бесконечный скролл хорош для просмотра постов на пикабу, но он категорически не подходит для работы аналитика. Ты не в курсе, что бэкенд под это дело тоже надо писать на сервере, хотя должен же быть, правда?
Ну вот зачем?
Проектируйте как хотите.
Если пагинации нет,
или какого-то кэша к которому применяются команды с сервера (или события).
Думаю, объяснять про декартовый взрыв смысла нет.
https://learn.microsoft.com/en-us/ef/core/querying/single-split-queries
Равно и то, что в некоторых БД AsSplitQuery не работает, и там проблема решается через .AsTracking и .Load.
Кстати, самое смешное что AsSplitQuery\Load реально может ускорить запросы в сотню раз (1 мб вместо 100 из БД).
Но 9 из 10 команд продолжают использовать Dapper и не знают почему 2 инклуда норм а 3 уже не работают.
Краткое содержание.
Кривая структура БД может причинять такие тормоза, что даже Oracle не не тащит, и даже ORM будет быстрее.
Мысли по поводу.
Улучшить быстродействие при увеличении пинга можно было увеличив FetchSize (умолчание в 10 строк годится только для БД в локалке). Понятно, почему не сделал автор - он не знает Oracle, но очень странно, что секта божественного Oracle этого не сделала.
При удаленной БД трехзвенка выглядит необходимой, дабы сервер таки рядом с БД был, странно, что руководство не осознало.
Если проблема только в свидетелях секты Oracle, можно было не брать MySQL, а организовать в новой БД рядышком - и народ бы меньше сопротивлялся, и часть аргументов типа нет возможности саппортить разные типы БД выбило бы.
Oracle не хуже и не лучше MySQL. Просто у них немного разное применение. Условно, Oracle и MySQL , как MAN сорокатонник рядом с грузовой газелью. Если для задач бизнеса хватает газельки, то пользовать MAN выглядит избыточным, если не сказать более.
Кривая структура БД может причинять такие тормоза, что даже Oracle не не тащит
В статье показаны тормоза на практически пустой базе после свежей установки. Исходники есть в гитхабе, репозиторий тоже, методику я расписал, можете сами проверить. Речь не идёт о кривой структуре.
Улучшить быстродействие при увеличении пинга можно было увеличив FetchSize
Крутили. Насколько я помню, там максимум в 36кб. Могу ошибаться. Но я точно помню, что не помогло.
не брать MySQL, а организовать в новой БД рядышком
А зачем? Я немного не понял смысл. MySql я расписал, чем был лучше. Он тупо быстрее работает во всех инструментах со своим стандартным протоколом из коробки. А зачем новый инстанс оракла ставить рядом? Чисто для тестов? Так прод всё равно будет в облаке, потому что начальство наотрез против переноса данных в офис.
Каюсь, читал статью несколько по диагонали, т.к. пишу на Java. Но, если дело не в БД, если правильно понимаю, то проблема тормозов на пустой базе = проблема пингозависимости фетча (медленный по сравнению с MySQL протокол при большом пинге).
Т.е. если разместить потребителя рядом с БД - тормозов не будет. Т.е. надо сразу пилить трехзвенку, разместить сервер рядом с БД и отдавать потребителю ровно столько, сколько надо, хоть через protobuf, хоть http.
Не новый инстанс оракла рядом, а новую схему данных в том же инстансе.
Вообще сложилось впечатление, что Oracle для вас был избыточен. На наших задачах и с сервером рядом с БД (пинг меньше 1мс) он вполне неплохо работает, в таблицах на сотни миллионов - миллиарды строк выборка по индексам единицы - десятки тысяч строк в запросах до десятка джойнов (но в основном к справочникам конечно) за время единицы - сотни миллисекунд.
Есть отдельные долго выполняющиеся запросы, там как правило в силу некоторых причин приходится перечитывать несколько сот гигабайтную таблицу полностью, тут приходится ждать, да.
Автор, я все понимаю. Но вот вы сдали машину в сервис, потому что мотор плохо тянет. Через шесть месяцев вам ремонтник, светясь от счастья, говорит, что с самим двигателем ничего не получилось, зато в свободном месте в багажнике он поставил дополнительно двухтактный мотор от инвалидки (MySQL) и переделанный двигатель на основе мопеда, правда подавать бензин и искру надо вручную (contains и джойн пока нет).
Ваша аналогия похожа на котёнка с дверцей. MySql появился уже потом, когда уволили людей, бравших меня на работу и принимавших решение про трёхзвенку. Я оставался один и проект мой хотели закрыть.
В этом проекте всё уже было. И джоины (1:M и M:1) и трекинг и всё, что перечислено в последнем списке. Это просто проект для этой статьи такой урезанный.
Да и чем MySql плох? За что его так сравнивать с мотором от инвалидки? Разве не умеет хранить данные? Умеет. А в чём дело?
Мне кажется основная проблема была в том, что (даже считая что вы все сделали полностью и идеально) вы добавили новую сущность, которая написана в одно рыло, сложная, соответственно без community support, с полным bus factor, и все это надо развивать и поддерживать в дополнение к существующей, при этом менеджеры уже знали, что из тех айтишников останется два ...
Согласен. Сложности добавилось. Это если говорить про трёхзвенку.
Но у нас была задача сделать одновременное редактирование большого документа целым отделом. Это без серверной части не делается ну никак. Можно, конечно, обмазать всё триггерами и ходить каждым клиентом проверять, что там изменилось, но вы же понимаете, что это так себе решение.
Трёхзвенка сложнее в разработке, но при сложной логике она проще. Вот такой парадокс. Мы знали, на что шли, это всё было учтено при принятии решения.
А ORM на этой трёхзвенке уже практически не привносил сложностей. Зато вот сильно упрощал написание, а главное чтение бизнес-логики. Он нужен был на начальном этапе, когда я один пилю. Если бы набрали команду, то потихоньку перенесли бы логику на сервер.
Сюжетные повороты и накал напряжения прям как в книге. Для меня статья скорее "какие проблемы решают большие дяди", нежели что-то действительно познавательное.
Ключевая ошибка - искренне вовлечься в работу в этой конторе.
Что-то задается мне нас тут за лохов держат…
БД Оракл- в головном офисе , который может быть за Х000 км это нормальная практика.
Таблица на 40 млн. Записей выгляди. Большой но тоже не про Лема, не думаю что народ в Excel 40 млн. Записей за раз тащит.
Логика в БД - радуйтесь у вас есть view, stored procedures + в оракуле persistent view. Берем нормальную книжку по оракл и вперед.
Сравнивать оракл и MYSQL - это вообще за гранью.
Автору можно было выкинуть формы и использовать Excel как фронт-енд. Я в свое время так делал. Генерал оезультыта на сервере в виде csv и выдавал на клиента а там просто парсил и отображал на колонки/строчки. Все нормально работало- пользователи были счастливы.
В общем курите маны они рулез:)
Что-то задается мне нас тут за лохов держат…
БД Оракл- в головном офисе , который может быть за Х000 км это нормальная практика.
Я выложил исходники, описал методику. Почему бы вам самим не проверить?
Логика в БД - радуйтесь у вас есть view, stored procedures
У меня в языке программирования общего назначения есть классы, наследование, полиморфизм, интерфейсы, свойства, события, отладка, тесты, рефлекшен, куча библиотек, ORM, гит и ещё много чего другого.
Что-то меня не радует наличие хранимых процедур в БД. Что там ещё есть для управления сложностью больших проектов?
Сравнивать оракл и MYSQL - это вообще за гранью.
Почему?
Автору можно было выкинуть формы и использовать Excel как фронт-енд
Спасибо, не хочу.
Если вы сам себе злобный Буратино то это ваши проблемы. Как вам ООП, события, ORM помогут не тащить 40 млн записей с сервера на клиента? Могу поспорить на 100500 мильонов что вы не круче людей которые писали движок Оракла и оптимизировали его. Поэтому подготовить данные на сервере и передать на клиента только нужный результат это единственно правильная стратегия. Делать это на клиенте имеет смысл если у вас клиентов миллионы и сервер просто физически столько соединений не потянет. Но с вашими двумя калеками и 10-ю запросами в минуту - сервер это не проблема.
Почему-то Мерседес может все свои производственные данные за кучу лет держать в оракловской БД, а вы не можете. Вы круче Мерседеса?
Как вам ООП, события, ORM помогут не тащить 40 млн записей с сервера на клиента?
Я спрашивал про управление сложностью. Не надо подменять тезисы. Пожалуйста.
вы не круче людей которые писали движок Оракла
Почему не круче? Там какие-то особенные супер-люди, до которых нам не дотянуться? Так какие-то волшебные знания, отличающиеся от привычной компьютер саенс?
Почему-то Мерседес может все свои производственные данные за кучу лет держать в оракловской БД, а вы не можете.
И пусть держат. В чём вообще проблема? Или в том, что я усомнился в Божественности Его Величия Оракла?
Вы серьезно? Хранимые процедуры (логика в БД) были анахронизмом еще 20 лет назад.
Этакий кто вам такое сказал? Ссылку можно? „а мужики-то из Оракла и Постргреса» и не знают…. Если вы пилите прилож уху которой будут два человека пользоваться то возможное вам и не надо. А когда у вас предприятие Котору лет до фига и данных тоже, то ту другие разговоры. Куча страховых компаний в той же Европе ещё на мейнфреймах и Коболе сидит а вам тут хранимые процедуры устарели. Ну-ну, предложите страховщикам переписать все на вашем новомодном фреймворке … Потом поделитесь ответом
“4,4 секунды! О как! Похоже, я перестарался с замедлением канала. Что стало видно сейчас - так это то, что данные поступают рывками. Это не тормоза OrmFactory, она в норме показывает плавный скролл на 60fps. А тут видно, что прямо слайд-шоу, как крайзис на встройке. Что любопытно, даже на глаз видно, что интервал "подёргиваний" примерно равен четверти секунды, то есть те самые 230мс пинга за небольшим плюсом на передачу очередного пакета.”
Есть мнение что автор немножко балабол и не в тебе БД и оптимизации вообще.
Так получилось что я сейчас под Шанхаем, и есть корпоративный сервак с Oracle. Причём сервак не сильно шустрый.
Считаем:
Пинг от Шанхая до Германии 600-800 мсек. сижу на немецкой сим карте через корпоративный ВПН.
Берем старый добрый SQL Tools 2 -GUI для работы с Ораклом, build 19, которому сто лет в обед - копирайт указан до 2021 гота
Запускаем select all, из таблицы в которой 3000 записей.
Время выполнения 2.96 sec.
Если запустить count (*) то результат будет около 500-800 мсек - т.е фактически время пинга.
Так что все у Оракла с работой по сути хорошо.
Если имеетс Нормальный канал, а не черт знает что, то время ответа будет равно времени пинга.
Тут по прямой под 9000 километров, а по проводам гораздо больше будет.
Не думаю что у автора сервер за 10000 км находится чтобы расстояние стало критическим фактором.
Не думаю что у автора сервер за 10000 км
Сервер у меня находится на локальной машине в виртуалке
автор немножко балабол
Ещё раз перейдёте на личности - получите минус в карму. Я предупредил.
Я вам только что сказал - есть исходники, есть методика. Проверяйте. Если есть сомнения - оформите мысль так, чтобы это можно было протестировать.
Запускаем select all, из таблицы в которой 3000 записей. Время выполнения 2.96 sec. Если запустить count (*) то результат будет около 500-800 мсек - т.е фактически время пинга.
Три секунды для 3к записей - это прямо много. Очень много.
У вас разница между пингом и фетчем всего получается больше двух секунд. Неужели сами не видите?
Давайте я сделаю тот же фетч через впн.
То есть у меня время меньше, чем у вас, но записей на порядок больше. Вопросы?
Я вам написал что я в Китае за китайский фаерволлом, по мобильному телефону. А вы поди по широченному каналу. Читайте что вам пишут. Далее - на вашем скриншоте не видно 3000 записей, так что вы там реально выбрали -вопрос большой.
Не-не, дорогой мой. Так в серьёзных дисскусиях не делается. Я никого не в чём не обвинял. Это Вы меня обвинили в балабольстве. Теперь обозначайте, что в моей статье неправда, а потом ставьте эксперимент, который я описал, публикуйте результат и потом уже говорите, что я балабол.
Я понимаю, что сложно поверить в то, что мускуль может 51к строк за секунду выбрать. Но что вам мешает самостоятельно проверить?
А мне обидно стало за автора :(
Ни черта не понял толком из статьи - не моя область, но ощутил и понял что ТС фактически сделал из говна конфетку
С согласованиями, убеждениями и палками в колесах в процессе
Затем пришли менее компетентные чуваки, которых уволили, ущемились и слили более скиллового разраба
Чтож, автор, проблема не в вас а в не адекватном менеджменте. Очень жалко что работа не реализована осталась, но если менеджмент идиоты - то тут ничего не попишешь
P.s. даже не вкуривая в смысл технички - было очень интересно читать) прям кайфанул :) респект ТСу!
Автор взялся за дело о котором ничего не знал в начале работы (оракл и его протокол) и попытался построить трехзвенный велосипед (космолет), так и не разобравшись в сути проблемы. Менеджмент почуял что все идет не по резьбе и в отчаянии пытался решить проблему начиная с верхов и последовательно увольняя руководителей автора от старшего к младшему. Пока не дошел до самого автора. Выглядит на самом деле так. Если прочитать статью внимательно, мы увидим, что менеджмент вообще никак не мешал автору. Но вот признаки сомнения присутствовали после первой же презентации самописной трехзвенной системы ORM с блекджеком и женщинами низкой социальной ответственности, которая вот-вот будет написана в одно лицо в кратчайшие сроки.
Менеджмент сам хотел вменяемую и быструю систему. Он сам подписался под графиком работ, о чём я в статье писал. Более того, менеджмент сам пообещал премию, если успеем к НГ. Никто их за язык не тянул. Но проект закрыли в октябре, хотя я шёл по графику, несмотря на три дополнительные задачи. Это стоило мне отпуска.
Кстати, Вадим первый понял что что-то идет не так и начал пытаться микроменеджментить автора (чтобы увидеть хоть зерно рационального в его деятельности). Но автор тут нашел способ прогнуть руководителя и тот похоже сдался и смирился. А потом пришел Александр и стал говорить прямо как есть что происходит и вся эта деятельность закончилась с отрицательным результатом (минус год и минус 6-8 лямов это отрицательный результат).
Я прочитал статью именно так.
Если рассматривать описанные события с этой стороны, то возникает вопрос почему команда Александра ушла не оставив описания архитектуры системы с обоснованием принятых решений. И если правильным направлением развития системы (в том числе повышение производительности в критичных сценариях) предполагалась доработка запросов и хранимок, почему наняли спеца без компетенций Oracle.
А так получилось что получилось: новый разраб стал решать проблему используя знакомые ему подходы и технологии. И сделал это с неплохим результатом, хотя, возможно, не так как это видел менеджмент, особенно учитывая его решение вернуть старую команду, которая возможно согласилась допиливать свою старую систему, но ожидаемо не имеет желания вникать в кардинально новую (значительно обновленную).
почему команда Александра ушла не оставив описания архитектуры системы с обоснованием принятых решений
Я сам стартовал новые проекты и не один раз, я знаю, как это бывает. Когда система только появляется, у автора полный карт-бланш. Он может воротить, что хочет. И потом тоже, когда бизнес видит от него реальную отдачу.
Саша, как я когда-то, начал писать новую систему и бизнесу это понравилось. А дальше происходило то, что происходит всегда. Саша окрылённый пилит, команда окрылённая пилит, бизнес торопит и всем насрать на техдолг.
Это называется "эффект низкой базы".
А потом оказывается, что система выросла. И чтобы получить такую же дозу дофамина, надо делать в десять раз больше. А делать стало в десять раз сложнее. Пичалька.
С них ничего не требовали, потому что не надо было. А потом им не надо было. Это мне уже пришлось свои решения обосновывать, причём письменно и с подписью начотдела.
Конечно косяков там хватает и первая команда наворотила дел. Но ушла она явно не со скандалом с проекта, если их позвали обратно. И они хотя бы сделали систему, которая криво-косо но работала. А вот автор, судя по статье, результата на этом проекте не добился вообще никакого. А времени у него было год, насколько я понял. Год! И в итоге кликбейтный заголовок статьи на Хабре, а по сути пшик. И надо заметить все там были какие-то странные с точки зрения автора. И начальник, и начальник начальника и безликий менеджмент и лид предыдущей команды. Это не наводит ни на какие мысли?
Но вообще вариант логики на сервере - это как раз идеальный вариант для линий с большим latency. Вызываем exec GetClientInfo 13455 и получаем датасеты про клиента за один roundtrip. Надо там привязать платёжку к счету - exec AttachPayment номерсчета, номерплатежки. Никакого ORM, один roundtrip.
В системах где все на stored procedures есть плюсы - все делается за один запрос!
Раундтрип и ORM - это вещи взаимно перпендикулярные. Особенно на системах со смешанной парадигмой, вроде той, что тут описана. А там как раз ORM работал и для сервера, и для клиента. В одном синтаксисе. Работать с логикой в клиенте удобнее, когда не хватает разрабов. Потому что на каждое действие создавать апи - дело, конечно, нехитрое, но очень уж утомительное. А у клиента интерфейс вот тут вот. Рядом. Если что, можно и юзера переспросить, не кидаясь джсончиками в сервер.
Тот кейс, который вы описываете, не требует передачи информации между клиентом и сервером. Но у нас тут была своя атмосфера. Номер платёжки передать? Хех. А давайте лучше впихнём юзеру результат анализа по позициям. Строк так сто тысяч. А он там разберётся как-нибудь, сгруппирует, отсортирует, отфильтрует что ему надо. И колонок ему ещё добавим штук десять, а то 50 - мало. И половина будет ссылками на другие сущности, суть, джоинами. А другая - результатами расчёта по какой-нибудь хитрой статистике. И чтобы там куча параметров была, желательно через интерфейс.
И чтобы всё это гуано менялось каждую неделю, потому что "а мы вот подумали".
Ну что, это путь самурая, бывает =)
Почему нельзя было взять готовую orm систему с нормальной субд типа postgresql и не придумывать все это? MySQL явно не та база для большой бизнес системы. Есть, например, odoo с хорошим orm движком, который "отлаживают" уже лет 20 1000 индусов. Работает быстро, пишутся модели "одним кликом", поиски работают мгновенно. И ошибка автора была в том, что он пытался "ремонтировать" хлам старой системы, на которую были ранее потрачены большие ресурсы и деньги. Это "известная история" не только в данной компании. В данном случае нужно было , скорее всего, брать другую, современную orm систему и быстро запускать на ней новый проект.
Мускуль никто не брал. Я его подключил в качестве развлечения к ORM просто потому что могу. Когда всё пошло по бороде.
Базу данных я не выбирал. Когда я пришёл, там уже был оракл. А в оракле было 5тб данных. Про орм я писал, почему свой. Потому что на три звена нет ни одного орм. Odoo - это не ORM. Это готовая ERP/CRM. Нам такое не надо было, потому что мы посчитали, что для нашей специфики дешевле делать своё, чем костылить чужое универсальное.
Оду как раз и есть orm с надстройкой на postgresql. Работает с данными через свой кэш, т.е. все пользователи работают с кэшем данных. Никто не заставляет использовать оду как ерп систему. Главное там есть orm и готовая система безопасности доступа пользователей к данным и формам их представления, а также система распределения данных одной базы между разными организациями. За 20 лет там много чего сделано разработчиками и в двух словах всего не опишешь. Здесь минимальным количеством трудозатрат можно в короткий срок запустить проект на любой "вкус и цвет". А "костылить" свое - это как раз путь в никуда, так как предполагает большие трудозатраты с непредсказуемым финалом. Сейчас на рынке вполне много готовых различных продуктов с готовым решением, на которые потрачены годы на разработку и десятки миллионов долларов. Главное взять его на "вооружение" и быстро показать заказчику готовое решение.
А если , все же, есть желание выпустить свой "уникальный" продукт, то придется найти богатого спонсора для наема 1000 индусов и потратить ни один год на разработку для создания хотя бы примерно конкуретного на рынке продукта.
Зачем Вы это всё сейчас рассказываете? Выбор был актуален 3 года назад. Всё, что не работает с ораклом мы отмели сразу. Ода работает с ораклом? Ну а зачем её советовать? Кто будет многоэкранные pl/sql переписывать под него? Зачем вообще этот геморрой?
Писал выше, не латать старую систему, а потратить время на ее замену новой, современной с минимальным количеством времени на ее разработку и внедрение используя готовые, современные решения. Есть опыт , когда наем и 30 разработчиков, не помогает в "латании" таких устаревших или "неправильно написанных изначально" системах.
Весь минус "самописанных" по своим "стандартам" систем заключается в том, что кроме самого "писателя" часто никто не может разобраться в написаном и надежность работы таких "самописанных" систем крайне низкая. Поэтому бизнес сейчас и покупает 1С, где нет проблем с сопровождением и поддержкой их работы.
Браво
Прокидывать fetch на дальние расстояния это в принципе тупиковый путь поскольку на уровне сети идет обмен - пакет запроса пара пакетов ответа. И задержка плюсуется на каждый пакет. У меня есть статья с тестами на эту тему + в книге Лори Анализ и диагностика сетей это описано.
Если первые разработчики пытались свою двухзвенную архитектуру использовать через сеть с большой задержкой в чистом виде это свидетельствует о их непонимании зачем вообще нужна трехзвенка. А если не понимают почему не могли поставить citrix или rdp тем кому нужна скорость побольше? Приложение было бы рядом с базой .
И когда Вы начали проектировать orm почему не рассмотрели вариант с citrix или rdp? В конце концов речь шла о затыкании архитектурной дыры.
P. S. Еще раз убеждаюсь что организациям нужно покупать платформы для разработки а не команды разработчиков с нуля. Хорошую архитектуру мало кто делать умеет , а в платформах многие вопросы решены
ORM на три звена. В 120 раз быстрее SQL?