System Design

[Фавн2]

Народ, кто что знает по System Design?
Делитесь

[BOBA]

Это что ли про архитекторов?

Тогда, (можно попробовать) затащить в винный бар живого архитектора и там его спросить.

[Фавн2]

Это чего-то типа такого, как я понимаю

vBulletin [media]

[BOBA]

Ну.... Или так.

[BOBA]

Нужен опыт работы на большом проекте, чтобы получить опыт. Без опыта? Ну такое. Микросервисы, деление бизнес - задач на домены репликация.... Там много много всего. Учебные книжки не замена большого реального опыта.

[Фавн2]

Не замена. Но если в пет-проджект встроен редис-кафка-nginx то он конкурентоспособнее crud прилажухи. Ну и опять же вопрос "как бы вы сделали твитер" вместо "сколько шариков пинг-понга влезет в самолёт" возможен на любом собесе. И лучше ответить более правильно чем менее или вовсе не ответить.

[Фавн2]

С опытом кстати систем дизайн тоже вряд ли приходит, т.е. ботать все равно надо. Если на текущей работе чел с этим не сталкивается, это не значит что на следующем собесе не попросят смоделировать Убер и это может быть перевешивающим при прочих равных.

[BOBA]

Либо ты постепенно от работы к работе переползаешь в область задач, где надо архитектурить, либо нет. И туда идут нередко либо экс кодеры, которые научились писать, либо экс аналитики которые немного умеют в код, второе имхо чаще.

То есть если чел из кода перешёл в аналитику, и подписал требования, и посмотрел как делают ионфигурируют системы, то он может придти и к этому вот (пример одного из моих друзей) но там, по факту ещё горы софтскиллов.

[BOBA]

Все начинается с того, что, выдумываешь себе работу мечты и туда настойчиво пробиваешься

[BOBA]

Это уровень, когда доверяют соотношение цена-качество дорогих решений. Которые влияют нередко на репутацию топов.

[Фавн2]

Вопрос "как бы ты спроектировал Убер" можно на любом собесе словить имхо. Байки войти в айти и плавно расти, по-моему идеализация. Реальность: надо быть мидлом чтобы устроиться на джуна, сениором чтобы устроиться на мидла. Петпрожект nginx-redis-cafka бьёт crud-прилажуху. Docker бьет бездокерный вариант. Ответ на спроектируй Твиттер бьёт "что ты будешь делать на дне миксера". Смержить К сортированых связанных списка бьёт напишите Фибоначчи без рекурсии. И т.д.

[BOBA]

Это неадекватусы. Ты им приходишь кран починить а тебе - как бы ты спроектировал империю Илона Маска?

Не знаю что это значит.

В банке у одной дамы принимали интервью на английском. А потом она ковыряла эксельки эксельки и все на нашем спикала. Ни одного ..ля слова не по нашему. А пальцы то гнули...

...сы. (имхо). А один чувак ишшо с гороскопом сверял... ...ля.

Ну надо учить будем учить чо.

[Фавн2]

Не знаю что это значит.

Конкуренцию. Искусственные параметры для отбора и проверка на "может ли учиться".

P.S.
Ну не только... Конечно. Если фирма использует nginx-кафку-редис-докер-чтоугоднодругое они бы не хотели вновь прибывшему объяснять это с нуля. Джуны в чем-либо не нужны, учить некогда.

[Afa]

использование толстого стека заради показухи тебе ничем не поможет. взгроможденье кафки там где достаточно синхронно дернуть по апишке - это минус. а оправдание использования кафки необходимостью хранить мелкие события и толстым батчем скидывать в кликхаус - архитектурное решение. собрать юникернел серверлесс окамловую прикладуху вместо толстого стека и за милисекунду отдавать страницу - архитектурное решение
начни изучение с докера и миникубов/докеркомпоза. и играйся.с тарантулами, кафками кликхаузами риаками зайцами редисами монгами. изучай что для чего подходит. определяй где олап где олтп и какие решения куда правильно втыкать. изучай бестпрактисы не только языков а и инфраструктур - всякие фпконф, райлсконф питонконф в помощники

[BOBA]

только вот, на каком пет проекте это актуально и можно реально увидеть? это уже mba для айти какое то.

Фавн, а что сейчас по датасаенсу? если бы я был умным свободным англоговорящим то наверное туда бы а не везде бы


===найти потом поддержанца кода на окамле? угу, их же толпы.

[BOBA]

сначала куча пальцегнутия а потом то одно в яндекс дзене отваливается то другое (((((( наахитектурили, не срослось, отпилили. сцуко. понабирали которых убер делать умеют ((((((((

[Afa]

Сообщение от BOBA

только вот, на каком пет проекте это актуально и можно реально увидеть? это уже mba для айти какое то.

я для агрегации десятков лямов записей эластик поднимал на локальном проекте - пг слишком задумчиво переваривал

===найти потом поддержанца кода на окамле? угу, их же толпы.

mirage.io - сделана окамлистами для окамлистов
и - окамл язык с пологой кривой изучения. джуна надрессировать совсем не проблема, особенно если на монадах потренировать до того

[Фавн2]

ВОВА

Фавн, а что сейчас по датасаенсу?

vBulletin [media]

Этот написал книжку Machine learning system design. Ещё не читал.

если бы я был умным свободным англоговорящим то наверное туда бы а не везде бы

Во-первых, джуны не нужны, их хантят в универах. Во-вторых, если ты делаешь петпрожекты для демонстрации "я почти мидл, возьмите меня на оклад джуна" то опять же для конкурентного преимущества надо чуды завёрнутые в несколько докеров стучащихся друг к другу с реализацией на сайте на много пользователей и пошло поехало к вопросам балансировки через nginx, кардабалет с видами хранилищ данных, масштабирование и прочее "надо знать примерно всё". Т.е. не "везде бы" это сегодня приговор "ну он слабоват в том-то, возьмём этого, он хотя бы криво это запили в пет-прожекте". Добором конкурентного преимущества идет mlops: ci/cd, контейнеризация, облака, dvc, mlflow, clearml, пользовательский интерфейс и его бэкенд(которые могут перерастать в то самое злосчастное "везде бы" которое хотелось миновать) и прочий специализированный зоопарк.
К алгоритмическим интервью базовых алгоритмов добавляются машин ленинговые алгоритмы ↓↓ from scratch

В мэйлру от эйчарящего прогера пару лет назад слышал такой пассаж: "а если ты не можешь дерево решений from scratch написать, что мне с тобой градиентный спуск что ли обсуждать?". При том что в градиентом спуске особо нечего обсуждать, а вот дерево решений я пишу 20-40 минут в зависимости от тренированности.

, теория стоящая за ними и знание зоопарка сеток с пониманием что почему, как и зачем. Вишенкой на торте а/б-тестировпние, и прочий теорвер и матстат.
Т.е. знать надо примерно всё, жупитеровые ноутбуки и "fit-predict"-уровень уже не прокатывает лет эдак 5, наполучать медалек на kaggle тоже не вариант, т.к. там оттесняют люди давно в профессии. Остаётся времязатратное и бесперспективное с точки зрения развития миксование лучших чужих решений с рандомным исходом. SQL надо ещё не забыть! Блин забываю все время, опять подтянуть надо оконные функции и классические sql-ex извращения.

Ну и важно не класть все яички в одну корзину. Вариант "курьер не такая уж плохая гурджиевсеая работа" тоже держу в уме.


Afa
Тебя как китайскую грамоту разбирать. Я почти ничего не понял, но какие-то новые слова выделил. Спасибо

[Afa]

ты вопросы задавай, я разверну.
и эт. пофыркаю немного. не надо знать всё. про сиквел - например надо знать как использовать окошко и для чего. нормальный тим/техлид смотрит не на знание справочниковых страничек а на понимание что применить. к списку скулятины добавь with-ы, включая рекурсивные, с юнион ол и агрегации и тебе хватит. но порешай типичные задачки. особо обрати внимание на миграции - например тонкость такая есть, что не надо задавать в добавляемомом индексированном поле дефолт отличный от нулл а надо сделать вторую дата миграцию - или добавление индекса на это поле делать второй миграцией с конкурентной индексацией - бо блокировки на проде не любит никто.

про докеры в докерах. тебе не надо странного. достаточно докер + композ или миникуб уверенно гоняемый и умение высунуть порт и постучаться в чужой порт. остальное - для сисадминов, к8с их епархия со всей оркестрацией лоадбалансом и прочей тряхомудией, от тебя спросят докерфайл. ци/цд - ну поиграйся с гитхабовскими экшнами, линтерами проект обмажь и собери для пр и пуша аудит, для релиза - деплой. всё, больше этого никому не надо
про разные базы - надо знать для чего применять. обзорно. знать минусы - ну например что кликхаус не любит частые вставки, потому вставка рекомендована толстым бандлом

[BOBA]

Нафиг скуэльщику докер? Умеет человек в запросы ну бери на запросы. Но если в какой то компании нужен разраб со знанием винной карты бордо, ну нужен. Но ладно может и правда на докер посмотреть. Не знаю….

[BOBA]

важно не класть все яички в одну корзину. Вариант "курьер не такая уж плохая гурджиевсеая работа" тоже держу в уме.

Дак вопрос в цели. От свалить любой ценой из России (не осуждаю) до зарабатывать штуку баксов в день не тратя больше двух часов (тоже норм)

Я вообще не уверен что на собесах у нас те же вопросы что у них.

[BOBA]

Пора писать книгу в трех частях часть один как пройти собес часть два как не завалить работу и часть три как на работе не сдохнуть от оверработы безденежья и тоски в разных сочетаниях((((

[Afa]

вов, чистый скульщик зверь редкий. а наличии апп между базой и вебсервером требует уметь собрать прикладуху в один пельмень. то бишь нарисовать докерфайл. особые познания потрохов не нужны но отдеплоить с нуля уметь надо.

[Фавн2]

Я вообще не уверен что на собесах у нас те же вопросы что у них.

Буквосочетание nginx я впервые на отечественных ml хакотонах увидел. Как и вояние полноценного сайта для демонстрации машинленинговой загогулины.

Вопрос сколько шариков влезет в самолёт и оцените количество курящих на планете - это мтс-банк 15летней кажется давности на обычного скуля. Меня отшили.

Ну опять же напиши без библиотек дерево решений для классификации и регрессии - это мэйлру. Я считаю за это надо плевать в рожу.


Докер в мл must have уже, тожа.

[Afa]

наваять сайт - это строчек примерно 10. и немного конфига. а, оформить данные - ну разметки строк под полста, если не джсон отдавать охота. легковесных фреймворков ща полно

[BOBA]

у нас отдел фронтенда - джаваскриптеры, бакенд - джависты, бизнеслогика - хранимки базы. мы, бизнеслогики почти никогда не пересекаемся с системщиками фронта и бэка, мы живем своей жизнью хранимок и иногда груви скриптов.

[Afa]

ну вот бэки и умеют и в докер и в интеграции

[Фавн2]

Чат гпт-4о сказал читать этих:

Here are three highly recommended books on system design:

• "Designing Data-Intensive Applications" by Martin Kleppmann
  • This book covers the fundamental principles of designing scalable, reliable, and maintainable data systems. It explores topics such as data modeling, storage systems, stream processing, and distributed systems.
• "System Design Interview – An Insider's Guide" by Alex Xu
  • This book is a practical guide specifically tailored for preparing for system design interviews. It provides detailed explanations, case studies, and design principles for building scalable systems.
• "Building Microservices" by Sam Newman
  • This book delves into the microservices architecture, discussing how to design, build, and maintain microservices-based systems. It covers topics like service decomposition, communication patterns, deployment, and scaling.

These books offer a comprehensive understanding of system design, from theory to practical applications.

Кабанчик и Сюй на месте, Ньюмана не знал.

[Afa]

с микросервисами всё просто. идея дальнейшего уменьшения связности кода, доведенная до предела. нормальный путь выделения кодоблока в сервис - сбор набора классов в отдельный модуль; выделение интерфейса для обращения к модулю; выделение хелперов умеющих в интерфейс обращения к модулю; вынос за пределы монолита модуля и переписывание хелперов для обращения к сервису; добавление конфигурирования для сервиса и хелперов; оформление хелперов в именованный модуль и возможно оформление хелперов в абстракцию репозитория с кешированием. на этом пути каждое действие может выполняться пошагово и обмазываться тестами чуть больше чем полностью и - шо главное - полностью подконтрольно и не вносит новых ошибок. ну и в процессе и монолит и сервис подчиняются стандартным правилам о связности, солидам да драям.

[BOBA]

друг архитечит в банке - и там истории про сервисы и данные тесно вплетены в вопросы о областях ответственности, полномочиях, и очень быстро упираются в деньги и амбиции. Большие деньги, да и амбиции немаленькие.
(это не отменяет ценности книжек.... наверное)

[Afa]

вов, это домен. внешние условия, данность. от них пляшем не когда нарезаем с монолита сервис а когда делаем интеграцию с внешним сервисом. чуть другая история

[Фавн2]

друг архитечит в банке

Что используют?

[BOBA]

Ну ты Фавн спросил. По моему он дорос до того, что пишет все в Ворде, а вот до уровня когда к компу не подходят ещё нет.

Я же говорю - согласует амбиции, зоны ответственности, проблемы доступа.

Для этого используются совещания, и пишет, пишет.

А технические подробности менее важны.

Ну насколько я помню, когда уходил из ВТБ терадата как хранилище истории ещё была, уже нет, про хадуп могу уточнить, много вопросов как разложить данные бизнес сегментов раскидав на базы, и как потом сводить, базы понятно что пг. Если осенью тебе будет интересно увидеть и спросить лично? Тогда свисти. Летом не до этого. А осенью дело другое.

Ну и я не поручусь, что, работа которую работают два моих друга - архитектора будет тебе по душе.

Хотя о твоей душе я ничего не знаю.

Но, всякие технические подробности - они на втором плане, ближе к первому - понимание бизнес - процессов, и чтобы айти решения не мешали большим дядям. Как то так.

[Фавн2]

Afa, а с GraphQL не пересекался?

[Afa]

я его не люблю. это вынос на фронт/клиента решения чего хочешь получить - увеличение связности и нарушение изолированности. апи должен прописываться в доках а не в запроосе
щупал так т. сразу минус - переложить часть работы на дб становится сложнее, простые запросы но сложные сериализаторы что приводит у большей работе на апп и большей задержке ответа. не, применять наверн можно но я пока границ применимости не нащупал. предпочёл б сам проектировать апи а не сваливать на фронтов

[Фавн2]

сложные сериализаторы что приводит у большей работе на апп и большей задержке ответа

апп - это что?
Разве не должен GraphQL работать быстрее из-за уменьшения запрашиваемых данных и минимизации количества запросов к серверу?

границ применимости не нащупал

При проектировании соц.сетей GraphQL не предпочтительнее?

[Afa]

апп - приложение, сервер приложения.

когда у тебя апи вида "дай мне эту таблицу и включи в нее эти связи" - да. тогда тебе в принципе и приложение не надо, couchdb и запрашивай с неё json'ы напрямую. когда нет прямого отображения таблиц в запрос и генеришь для набегающей суммы окошечными функиям запрос с мультиджойна - ну нихрена не уменьшишь число запросов. увеличишь. к серверу бд и будешь обрабатывать их у себя в бэке. а с фронта да, ты одним запросом хапнул всё не меняя бэка. только ты того ж результата достигнешь самым обычным апи запросом, без задания на фронте что и как ты хочешь получить - у тебя в апи прописано что сервер отдаст, зачем это знание выносить в запрос? в общем, подозреваю изобрели от лени проектировать апи

подозреваю - графкуэль предпочтительней при прототипировании сайтов пляша от макета у фронта. бэк дал энтри поинт, сказал кидать туда и впихнул туда универсальный сериализатор а фронт пускай там корячится придумывает

[BOBA]

Если хочется больше свободы дать фронтовикам, и перенести на них ответственность за то, как и какие данные они потянут - им можно дать graphql как я понял...

Но это же полумера. Можно открыть им sql и дать полную свободу? В управлении желаемыми наборами данных.

[BOBA]

Была же раньше двухзвенка - толстый клиент и база. Графкьюэл кмк отчасти возвращает к этим истокам, давая на клиентскую часть больше прав и свобод?

[Afa]

вов, couchdb. принимает с фронта запрос отдаёт ответ. не взлетело. и толстые клиенты взлетают если обновления раз в год и минорны. ну попробуй для начала валидацию входных данных на бд построить. потом по правам подели возвращаемые наборы. будет весело. и пообрабатывай на фронте интеграцию с госуслугами например. от толстых клиентов и двузвенок не зря ушли. а ща даже не трех а четырехзвенка, бизнеслогику отделяют от хранилищ и показа и выделяют в отдельный слой

[BOBA]

Разве не должен GraphQL работать быстрее из-за уменьшения запрашиваемых данных и минимизации количества запросов к серверу?

Ну в подполе у тебя все равно бд .

Как она сумеет у тебя отдать то что с фронта придет так и сумеет.

Под рест ты каждый по отдельности запрос сможешь отладить исполнитель, потому что знаешь что у тебя спросят. А под граф то не знаешь что спросят (меньше знаешь) поэтому вот хз.

Рест могут спроектировать удобный фронтовикам и покрывающий бизнес потребности с запасом? Если нормальный вдумчивый архитектор подумает - какие апи нужны.

А граф.... Это ещё один не особо прозрачный слой. Имхо.

По архитектуре данных опять же вопрос - какие данные в какой детализации нужны под бизнес задачи тех или иных агентов.

Ну и вопрос цен - во что обойдутся сервера которые исполняют кешируют и ТД запросы граф кьюэль. Они в бюджет проекта уместится? Что лучше купить лишний сервер или привлечь разрабов фронта и Бэка, стадо?

[BOBA]

Разве не должен GraphQL работать быстрее из-за уменьшения запрашиваемых данных и минимизации количества запросов к серверу?

Ну в подполе у тебя все равно бд .

Как она сумеет у тебя отдать то что с фронта придет так и сумеет.

Под рест ты каждый по отдельности запрос сможешь отладить исполнитель, потому что знаешь что у тебя спросят. А под граф то не знаешь что спросят (меньше знаешь) поэтому вот хз.

Рест могут спроектировать удобный фронтовикам и покрывающий бизнес потребности с запасом? Если нормальный вдумчивый архитектор подумает - какие апи нужны.

А граф.... Это ещё один не особо прозрачный слой. Имхо.

По архитектуре данных опять же вопрос - какие данные в какой детализации нужны под бизнес задачи тех или иных агентов.

Ну и вопрос цен - во что обойдутся сервера которые исполняют кешируют и ТД запросы граф кьюэль. Они в бюджет проекта уместится? Что лучше купить лишний сервер или привлечь разрабов фронта и Бэка, стадо?

[BOBA]

Вот у нас. Разработчик бизнес функционала сам пишет себе оконечные точки на базе, и сам вставляет их в конструктор форм.

Это я. Есть фронтер, который отвечает за то что бы формы которые мы нашлепали крутились в браузере и бэкер с сервером приложений который примет запрос и дернет за при которое я написал на базе.

А если с сущностью что то происходит, то при этом триггерятся триггера из тех же оконечных точек.

Ну это в одном слове. Нифига не классическая архитектура. Ещё в 19 годе это был толстый клиент на Делфи, но уже он дёргал за оконечные точки, потом сделали плеер форм, который дёргает за них же (немного перепиливали конечно, болезненно иногда).


Нам графкьюэль нафиг не нужен. Нам без него отлично.

[BOBA]

Но вот перенос кода оконечных точек, когда оракл поменяли на пг...их было много, перетестировать приходится тяжело

[Afa]

есть много способов изоляции, я вон рассказывал пошаговый рабочий. то что невовремя у себя наплодили бутылочных горлышек - ну то такое, разруливать надо вовремя, на это есть архитектор и выделение доли рабочего времени на обработку техдолга

[BOBA]

А вот всегда есть то что придется переделывать, если земля налетит на небесную ось. В 20 м году же ещё не было что оракл уйдет. Он казался надёжным фундаментом. И был им долгие годы. То есть да огромная часть нашего кода, по бизнес логике это хранимки в базе.

Долгом это стало по политическим причинам. А до этого не было.

Ну пережили. Есть надежда, что слезем с оракла. Вот такое вот.

А кто то считал великим и вечным сап. И строил решения на нем и все были довольны.

И вся архитектура внедрения была на согласовании хотелок заказчика с возможностями базовой системы.

И так жили. Где сап? Нет сапа. Санкции пожрали с oebs вкупе.

У нас вот коммуникации на фирме были на аське. Где она? Гусары, излагайте. Придется забыть. Я думал, что аську немного РЖД поддерживает... Не а. Пох.

[BOBA]

А вот всегда есть то что придется переделывать, если земля налетит на небесную ось. В 20 м году же ещё не было что оракл уйдет. Он казался надёжным фундаментом. И был им долгие годы. То есть да огромная часть нашего кода, по бизнес логике это хранимки в базе.

Долгом это стало по политическим причинам. А до этого не было.

Ну пережили. Есть надежда, что слезем с оракла. Вот такое вот.

А кто то считал великим и вечным сап. И строил решения на нем и все были довольны.

И вся архитектура внедрения была на согласовании хотелок заказчика с возможностями базовой системы.

И так жили. Где сап? Нет сапа. Санкции пожрали с oebs вкупе.

У нас вот коммуникации на фирме были на аське. Где она? Гусары, излагайте. Придется забыть. Я думал, что аську немного РЖД поддерживает... Не а. Пох.

[Afa]

вов, те кто в 14-м не понял что отключать будут всё и это только вопрос времени - ну как т ой. банки - озаботились. хы25 в своей версии внедрили, отмасштабировали по миру. кто мешал подготовиться с ораклом? с виндой? с сапом?

и с аськой - та ж засада. ты не владеешь корпоративным месенджером? ну готовься что придется пересесть. для понимания - есть полно серверов мессенжеров ставящихся на твои сервера. маттермост например, джаббер. не, в пропиетарщину лезете с радостным визгом

[Фавн2]

Это ещё один не особо прозрачный слой. Имхо.

Я пытаюсь понять зачем фэйсбукеры изобрели и внедрили у себя GraphQL.
Там тоже не дураки сидят.


P.S.
И лишний сервер им купить точно не проблема и стадо фронта и Бэка нанять тоже. Руководствовались чем-то другим.

[BOBA]

Имхо это некий стандарт внедрения гибкости в rest, если у них эту гибкость один добавлял так, другой эдак.

Но мы же не знаем, как широко оно все там используется,? Они большие, могут себе позволить, и что то придумать, и внедрить и выкинуть потом, и переписать по новой моде.

Ну внедрили. Если будет случай спрошу что наши практики думают про эту прослойку.

[BOBA]

Им то не проблема, и нанять и купить, но архитечить там где денех не считово будут не все.

В ит есть мода, есть эксперименты.

помню, хотел когда то на шиномонтаж

https://docs.oracle.com/cd/E17984_01...on_systems.htm

Пойти работать. Модно было. Много его сейчас? Мало.... Кто знает.

https://habr.com/ru/articles/815241/

Сказ про то как Сулейман кубернетес учил

[BOBA]

Кстати, а кто работал на проектах, где все базы были не реляционными?

Ну чистое моего или ещё что.

[Afa]

Сообщение от Фавн2

Я пытаюсь понять зачем фэйсбукеры изобрели и внедрили у себя GraphQL.
Там тоже не дураки сидят.


P.S.
И лишний сервер им купить точно не проблема и стадо фронта и Бэка нанять тоже. Руководствовались чем-то другим.

мало ль. влетели в проблему синхронизации фронта с бэком, синхронизацию мобилки с бэком - что особенно интересно при зоопарке поддерживаемых версий клиентов.

ну и не забывай что запросы однотипны и легковесны, олаповщины в них не будет и на клиента отдать надо несколько вьюх бд. а графкуэль собирает несколько запросов в один бай дизайн.

псы. самое дорогое - время программиста. сервера по сравнению - дёшево.

[BOBA]

Последние несколько лет GraphQL активно используется в Facebook и служит основой для абстрагирования потоков данных в мобильных приложениях для Android и iOS. GraphQL позволил уйти от практики разработки мобильных приложений в виде надстройки над вариантом сайта Facebook для мобильных устройств в сторону самодостаточных программ с логикой выполнения на стороне клиента. При реализации парадигмы Model-View для получения данных отлично подходит формат JSON, но существующие методы для отправки запросов, такие, как REST и ad hoc, не отвечали требованиям Facebook и требовали выноса части логики на сторону сервера, не обладая должной универсальностью. Facebook попытался решить эту проблему в GraphQL и за последние три года перевёл все свои мобильные приложение на данную технологию.

(C) Opennet

[Afa]

Сообщение от BOBA

Кстати, а кто работал на проектах, где все базы были не реляционными?

Ну чистое моего или ещё что.

я делал. бд была редиска. проект - софтреалтайм

[квит]

Сообщение от BOBA

Кстати, а кто работал на проектах, где все базы были не реляционными?

Ну чистое моего или ещё что.

я немножко возился с кашэ

Caché (произносится: «кашэ́») — иерархическая СУБД, позиционирующаяся производителем как объектно-ориентированная, «постреляционная» и мультимодельная.

[BOBA]

каше это прям к истокам, прям мампс емнип....

[Afa]

cachedb которая? эта падла после нулевых научилась рушась не утаскивать с собой данные? а ведь по краю прошли, чуть в прод не вышла

[Afa]

монго кста тоже не люблю. у соседей 30 гиглв данных улетело в валгаллу. неделю потом регенерили

[квит]

да, был проект по интеграции, был дичайший паноптикум из разных бд, от оракла и информикса до фокспро и аксеса...

1ска, куда же без неё...

и еще какие то смежники вели базу данных аж, бля, в экселе...

среди всего этого великолепия каше не смотрелась особенно чужеродно)))

[Afa]

про 1эску кста. битрикс трогал? мне интересно, какой там алгоритм округления до копеек при множественных скидках? мы подобрать не смогли. вечно копейка не билась, сумели только частоту небиения понизить до примерно раз в сутки

[квит]

Сообщение от Afa

про 1эску кста. битрикс трогал? мне интересно, какой там алгоритм округления до копеек при множественных скидках? мы подобрать не смогли. вечно копейка не билась, сумели только частоту небиения понизить до примерно раз в сутки

битрикс юзал, но с таким не сталкивался...

хотя это ж вроде не коммутирующие операции - в смысле округление суммы не равно сумме округленных... независимо от движка... )))

[Afa]

понимаешь, были испробованы варианты с разной точность с разными алгоритмами. так и не сумели вычислить. только детектор поставили

[BOBA]

Надо нейросеть обучать...

[Afa]

делать хрензнает как работающий чёрный ящик на каждый чих херовая идея. отсылка в саппорт в почту сообщения о небиении на копейку и страничка в админке с разбором где копейка не срослась и кнопкой "поставить правильную сумму" более верна
цирк кста был в том что это от 1эски приходили чеки для отправки в банк на оплату а банк эти чеки не принимал по причине несовпадения посчитанной 1эской суммы с суммой элементов.

[BOBA]

https://habr.com/ru/articles/818765/

Критика graphQl

[квит]

Сообщение от Afa

делать хрензнает как работающий чёрный ящик на каждый чих херовая идея. отсылка в саппорт в почту сообщения о небиении на копейку и страничка в админке с разбором где копейка не срослась и кнопкой "поставить правильную сумму" более верна
цирк кста был в том что это от 1эски приходили чеки для отправки в банк на оплату а банк эти чеки не принимал по причине несовпадения посчитанной 1эской суммы с суммой элементов.

смешно

битрикс ваще штука кривая, делали лендинг на нём, щас переделываем, не приспособлен)))

[Afa]

эм
лендинг
на битриксе
богатенькие буратины
хочу столько таких серверов шоп оно хабратест выдержало

[BOBA]

- так серверок с битриксом наверное и так есть и на нем же, заодно еще и лендинг....

[Afa]

Сообщение от BOBA

- так серверок с битриксом наверное и так есть и на нем же, заодно еще и лендинг....

дело в том шо этот серверок с битрикс ляжет под стандартной нагрузкой лендинга

[BOBA]

Квит, а в итоге, чем Битрикс не понравился, жрал много?

[Фавн2]

Afa

монго кста тоже не люблю. у соседей 30 гиглв данных улетело в валгаллу. неделю потом регенерили

а в чем причина?
они придумали, что можно сделать чтоб такого не повторилось?

[Afa]

Сообщение от Фавн2

Afa

а в чем причина?
они придумали, что можно сделать чтоб такого не повторилось?

не знаю как сейчас а в те времена монго любила падая оставлять за собой неконсистентные данные. настолько невалидные что сама пережевать их не могла. и славилась этим долго. это нормально, когда молодой продукт такое творит - пг вполне с собой данные уволакивал, но настолько быстро исправились что считай никто и не заметил.
кста - на пгпро есть лекции по потрошкам постгресса, если чо. интересное.

учитывая что эти данные промежуточные и исходники всегда есть - не морочились. чуть схему поправили чтобы инкрементально накатить легко было и привыкли хранить бэкап недельной давности, на который инкремент за полчаса катается

[Фавн2]

vBulletin [media]

[Фавн2]

во наговорили... целый плейлист по пару часов на главу

vBulletin [media]

надеюсь попобльше конкретики наговорили, а то какие-то круги на воде этот кабанчик


ышо не смотрел


секта свидетели кабанчика, прям массоны какие-то

[Фавн2]

vBulletin [media]