Микросервисы и точки отказа.

Тот же упомянутый мной выше по треду Juno реализовывал каноничную микросервисную архитектуру...
Альтернативный подход исповедует, например, Gett, у которого огромный жабный монолит...
В Джуно, есличо, было около 80 разработчиков+qa+менеджмента

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

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

Какой смысл бить остальную систему? Я честно не понимаю, каким образом «предсказывать положение машины в условиях хренового интернета» становится легче реализовывать от того, что оно не реализовано в рамках монолита (в том числе модульного). Разница между модульным монолитом и макросервисами заключается в более жирном протоколе комуникации, дальше разница между макросервисами и микросервисами идет по числу исполняемых функций каждым сервисом. Ты в предыдущих сообщениях даже сам признал, что придерживаться правила «один сервис — одна функция» неудобно, часто хочется засунуть в сервис несколько смежных функций.

В идеале нужно разбить сервисы по границам команд разработки — на моем нынешнем рабстве примерно в таком духе и ведется разработка, хотя тут все-таки выраженные макросервисы. Но я честно не вижу, чем заняться 80 человекам, и тем более 200-300 человекам. Вся Dota 2 разрабатывалась командой 40-50 человек — клиент, сервер, графика. Эти 200-300 человек не сделают больше — они реализуют те же фичи за намного больший бюджет, вот и всё.

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

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

Это не только в машинном обучении select * from tablename можно встретить. :)

Есть задачи, где проще при запуске программы единоразово вытащить всю базу к себе и построить из неё все нужные структуры. А в базу только при изменении объектов писать и ничего не читать (до следующего перезапуска). Потому что объединение таблиц намного дороже, чем чтение поля структуры из памяти.

Хорошо, а как же форд с глюком руля?

Где-то за ДТП посадили инженера форда?

Есть задачи, где проще при запуске программы единоразово вытащить всю базу к себе и построить из неё все нужные структуры.

И потом мы ещё жалуемся на жирно вэб... нам блин «проще всю базу вытащить»... кого породили, те нас и имеют...

Подробностей не помню.

Хорошо, а как же форд с глюком руля?

Где-то за ДТП посадили инженера форда?

Кстати, да, забавно, что инженеры никогда не виноваты. Даже с 737 MAX боинг за откровенное мошенничество получил лишь штраф, никто из манаджмента не сел, судили только бывшего летчика-испытателя (при чем он тут вообще?). Так что да. корпорация всегда права, а виноват Ванька. Когда Airbus 320 разбился на презентации, тоже всё свалили на пилота.

И потом мы ещё жалуемся на жирно вэб... нам блин «проще всю базу вытащить»... кого породили, те нас и имеют

Как ни странно, удобнее и быстрее работать с данными, которые под рукой, а не теми. которые непонятно где. А значит, что либо нужно их самому иметь, либо попросить выполнить работу кого-то, у кого эти данные есть. Потому я фанат SQLite, как самого масштабируемого движка БД... ну хорошо, может быть еще LevelDB/RocksDB неплохи.

Как ни странно, удобнее и быстрее работать с данными, которые под рукой

Вэбер?

Вэбер?

«Официальный интернет-магазин легендарных американских грилей Weber» — видимо, нет.

Ну значит «шлангующий вебер».

Ну значит «шлангующий вебер»

Ты по-русски говорить умеешь?

И потом мы ещё жалуемся на жирно вэб… нам блин «проще всю базу вытащить»… кого породили, те нас и имеют…

Вот есть бухгалтерская база, есть запросы типа «рассчитать себестоимость списания в разрезе партий по FIFO». Если честно рассчитывать через

SELECT INTO TEMP Партии
CASE 
    WHEN Партия.Тип = &типпоступления THEN Поступление.МоментВремени
    WHEN Партия.Тип = &типприходования THEN Оприходование.МоментВремени
    WHEN Партия.Тип = ... -- здесь ещё пара десятков строк
END AS МоментВремени, Партия, Номенклатура, Остаток FROM
(SELECT Номенклатура, Партия, SUM(Количество) КАК Остаток from движения
INNER JOIN Товары ON Движения.Номенклатура = Товары.Номенклатура
GROUP BY Номенклатура, Партия) AS Остатки
LEFT JOIN Поступление ON Поступление.ссылка = Остатки.Партия
LEFT JOIN Оприходование ON Оприходование.ссылка = Остатки.Партия
...  -- здесь ещё пара десятков строк;


SELECT
  Товары.Номенклатура,
  ВТ1.Партия,
  CASE
     WHEN SUM(ВТ2.Остаток) - ВТ1.Остаток = 0
        THEN CASE
           WHEN Товары.Количество < ВТ1.Остаток
              THEN Товары.Количество
           ELSE ВТ1.Остаток
        END
     WHEN Товары.Количество - CASE
                                 WHEN Товары.Количество < SUM(ВТ2.Остаток) - ВТ1.Остаток
                                     THEN Товары.Количество
                                 ELSE SUM(ВТ2.Остаток) - ВТ1.Остаток
                              END < ВТ1.Остаток
     THEN Товары.Количество - CASE
                                 WHEN Товары.Количество < SUM(ВТ2.Остаток) - ВТ1.Остаток
                                     THEN Товары.Количество
                                  ELSE SUM(ВТ2.Остаток) - ВТ1.Остаток
                              END
           ELSE ВТ1.Остаток
  END AS Списать
FROM
   Товары AS Товары
     INNER JOIN Партии AS ВТ1
     ON Товары.Номенклатура = ВТ1.Номенклатура
     LEFT JOIN Партии AS ВТ2
       ON (ВТ1.Номенклатура = ВТ2.Номенклатура)
          AND (ВТ1.МоментВремени >= ВТ2.МоментВремени)

GROUP BY
   Товары.Номенклатура,
   ВТ1.Партия,
   ВТ1.МоментВремени,
   ВТ1.Остаток,
   Товары.Количество

HAVING
  Товары.Количество > SUM(ВТ2.Остаток) - ВТ1.Остаток

ORDER BY
  ВТ1.МоментВремени

будут жуткие тормоза.

А если есть таблица Партии с текущими остатками в памяти, то себестоимость формируются практически мгновенно.

Вэбер?

В вэбе так было пока не придумали дебильный вездесущий AJAX, который локальную страницу превратил в приложение-клиента. Хоть ЛОР это поветрие минуло и я могу писать этот текст и даже смотреть соседние сообщения даже с выключенным Интернетом.

Вэбер?

В вэбе так было пока не придумали дебильный вездесущий AJAX, который локальную страницу превратил в приложение-клиента. Хоть ЛОР это поветрие минуло и я могу писать этот текст и даже смотреть соседние сообщения даже с выключенным Интернетом

ВЫ О ЧЁМ? Я не могу понять, про что вы пишете, оба. Как «так», при чем тут AJAX, если LOR написан, внезапно, с AJAX-ом и перезагрузкой содержимого без перезагрузки страницы — что не мешает читать лор без интернета, но непонятно, как относится к треду.

Вэбер = weber = разработчик web (а.k.a. сайтов).

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

ЛОР написан с правильным использование AJAX. Все данные текущей страницы на клиенте и AJAX позволяет минимизировать обмен с сервером. Многие же с помощью AJAX, наоборот, делают обмен с сервером непрерывным.

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

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

Я возражаю, так как «форумы», которые подгружают следующее сообщение только по перемотке и полностью дохнут при малейшей потере связи реально бесят

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

Я хз как сейчас но со временем должны прийти к аналогии J2EE.

Нашел http://eventlet.net/ Вроде то что нужно. Всем отвечающим спасибо, как обычно.

В котором есть куча i/o. Но решение нашел же, пусть и самостоятельно. Оно ещё и psycopg2 вроде поддерживает, то что нужно.

Ну судя по запросу, я ниразу не удивлен что оно крайне неспешное.

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

СУБД имеет очень ограниченные структуры данных. Фактически, только одну структуру: таблица с индексами. В памяти помимо таблицы могут быть массивы, графы, хеши, … которые обеспечивают намного большую скорость обработки.

Или возможно переписать запрос.

Как ни переписывай, JOIN всегда медленнее, чем доступ к полю объекта, а вытаскивание первых элементов на заданную сумму через нарастающий итог медленней, чем перебор отсортированной коллекции в памяти.

Я поэтому написал «возможно» left join намекает что что-то делают не так.

left join намекает что что-то делают не так.

???

В SQL есть другой способ отсортировать по полю объекта в поле таблицы? В данном случае по полю Партия.МоментВремени.

В SQL есть другой способ отсортировать по полю объекта в поле таблицы?

ЯННП какое отношение имеет left join к сортировке? Но в независимости от этого, сам по себе left join тяжелая операция с полным перебором.

ЯННП какое отношение имеет left join к сортировке?

Есть таблица с полями Номенклатура, Партия, Количество.

Надо получить записи, для которых поле МоментВремени записи, на которую ссылается поле Партия меньше заданной. Как будешь это делать без left join?

Изменишь структуру и добавишь в основную таблицу МоментВремени? Нарушение нормальной формы.

left join тяжелая операция с полным перебором.

С чего это с полным? По индексу log N.

left join подразумевает что у вас таблицы не связаны.

С чего это с полным? По индексу log N.

Если оно есть.

left join подразумевает что у вас таблицы не связаны.

Связаны. Но запись Партия может указывать на одну из нескольких таблиц с интерфейсом Партия (Поступление, Оприходование, Производство, …) в зависимости от поля ТипПартии.

Можно, конечно сделать пачку колонок типа

CREATE TABLE ДвиженияСклада
(
    ПартияПоступление int,
    ПартияОприходование int,
    ...
CONSTRAINT ПартияПоступления_fk 
    FOREIGN KEY (ПартияПоступление )  REFERENCES Поступления (Ссылка)
CONSTRAINT ПартияОприходование_fk 
    FOREIGN KEY (ПартияОприходование)  REFERENCES Оприходования (Ссылка)
   ...
    Subject varchar(50) NULL
)

но LEFT JOIN никуда не денется:

SELECT INTO TEMP Партии
CASE 
    WHEN NOT Поступление.МоментВремени IS NULL THEN Поступление.МоментВремени
    WHEN NOT Оприходование.МоментВремени IS NULL THEN Оприходование.МоментВремени
    ... -- здесь ещё пара десятков строк
END AS МоментВремени, ПартияПоступление, ПартияОприходование, ..., Номенклатура, Остаток FROM
(SELECT Номенклатура, ПартияПоступление, ПартияОприходование, ... SUM(Количество) КАК Остаток from движения
INNER JOIN Товары ON Движения.Номенклатура = Товары.Номенклатура
GROUP BY Номенклатура, ПартияПоступление, ПартияОприходование, ...) AS Остатки
LEFT JOIN Поступление ON Поступление.Ссылка = Остатки.ПартияПоступление
LEFT JOIN Оприходование ON Оприходование.Ссылка = Остатки.ПартияОприходование
...  -- здесь ещё пара десятков строк;

аналогии J2EE.

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

Но запись Партия может указывать на одну из нескольких таблиц

Это и значит, что не связаны

Можно, конечно сделать пачку колонок типа
но LEFT JOIN никуда не денется:

Вот как раз тогда можно будет заменить на inner join

Вот как раз тогда можно будет заменить на inner join

Нельзя. Из ПартияПоступление, ПартияОприходование, … только одна не NULL. И при INNER JOIN со всеми таблицами мы получим гарантированно пустой результат.

Для этого заводятся «пустые» записи в соответствующих таблицах.

Для этого заводятся «пустые» записи в соответствующих таблицах.

С пустыми записями можно и в моём первом запросе всюду LEFT на INNER заменить. Будет типа

INNER JOIN Поступления ON 
  CASE 
    WHEN ТипПартии = &ТипПоступления THEN Остатки.Партия = Поступления.Ссылка
    ELSE Поступления.Ссылка IS NULL
  END
INNER JOIN Оприходования ON 
  CASE 
    WHEN ТипПартии = &ТипОприходования THEN Остатки.Партия = Оприходования.Ссылка
    ELSE Оприходования.Ссылка IS NULL
  END
...

Это тут причем ? J2EE это набор строгих стандартов и спецификаций. Если бы это применили к микросервисам то было бы плевать что там внутри и на каком языке, есть точное описание что должно быть на входе а что на выходе. К примеру в Ж2ЕЕ есть ждбс и плевать какая бд там используется …

Хз понятно ли я написал.

У вас всё так же не будет связности таблиц в виде внешних ключей.

Да не. Я про другое немного. Вот смотри, в решении более-менее реальных задач по машинному обучению, как правило есть циферки которые всякую статистику отображают о данных, с которыми работают. Эту статистику тоже сутки считать чисто вычислениями. Вместо того чтобы её посчитать 1 раз и залить в базу данных или хотя бы json сраный и уже оттуда смотреть по мере надобности, они (математики, особенно старой закалки, которые не любят программировать) разово сутки считают, потом смотрят на результат, а дальше его кусочками пересчитывают по мере необходимости. Практика показывает, что по несколько раз до конца проекта все данные будут пересчитаны. Т.е. реально из месяца исследований 3-5 дней будут убиты на лишние расчёты.

«Ой». Это «немного» жестко. Спасибо за пояснение.

Это и значит, что не связаны

вот и пошел разговор о том, как в базу класть объекты классов Base, Derived1, Derived2, Derived3 так, чтобы SQL это понимал на уровне связей между таблицами

и похоже тут все решения плохие, так?

а тебе усложненный вариант моего вопроса (если что, я сам ответ не знаю) — как класть в базу объекты классов с множественным наследованием, чтобы SQL понимал наследование на уровне связей между таблицами?

Просто потому, что язык Си никогда не проектировался и провоцирует на написание ошибок, что никак не оправдано близостью к железу, в то время, как Java защищает от уже написанных ошибок, хотя байткод JVM не сильно выше уровнем, чем ассемблер:

у тебя есть feature list языка программирования, который бы тебя устраивал?

вот и пошел разговор о том, как в базу класть объекты классов

Именно. Только вы ошиблись с началом, у вас это «объекты классов».

начало может быть в классах, а может быть в БД — это не столь важно

если хочется плясать от sql, то вопрос видимо будет звучать как-то так:

как сделать так, чтобы sql понимал, что каждый тапл/рекорд какой-то таблицы/вьюхи Derived одновременно является таплом/рекордом таблицы/вьюхи Base с теми же значениями полей и теми же id для внешних ключей

но это звучит как-то очень тяжеловесно и я даже не уверен что 100% правильно — особенно если там еще и триггеры

Я уже написал про вашу ошибку. Она заключается в том, что вы не думаете о данных.

я ничего не понял, давай подробнее

Проблема в том, что при проектировании СУБД нужно думать о данных, а не о том как это модно молодежно сделать. Так понятнее?

нет, не понятно

более того, подозреваю, что у тебя проблема останется (но в другой форме), а твои слова — чистые понты

нет, не понятно
а твои слова — чистые понты

Что же, ещё один прогульщик 1ц-ник детектед.

давай тогда, покажи класс, гы-гы

изобрази что-нить из предметной области, что обычно кладут на Base/Derived, причем обязательно с поведением, а не просто данные, и как ты это положишь в БД