Д
на этом все прививки построены
Size: a a a
2020 March 16
A
работает
"оно не так работает" а не "оно не работает"
AH
ты во фростпанке что делаешь когда у тебя переполнение больниц?
если переполнение больше чем в два раза, обычно это намекает на рестарт. Если меньше (20 в больничке, 15 гуляют), то всё под контролем. Первые должны вылечиться быстрее чем вторые получить вторую степень болезни
AH
чтобы первые лечились быстрее, надо трансплантировать органы
A
потому что прививки нет
AH
тогда они лечатся за 20ч вместо 24
A
и подтверждений, что иммунитет вырабатывается вообще - тоже
Д
ну это да
NM
акции вещь такая, что они скорее от инфоповода падают, чем от реального положения дел
Да так оно и начинается, сначала инфоповод, потом дефицит, потом перепроизводство, а потом какая-нибудь великая депрессия
RM
У нас вот именно таких задач очень много.
Щас опишу как она решена в одном проекте
Есть сервис, который должен предоставлять ВСЕ данные какие возможно. Он потребляет все возможные кафки (а если инфа доступна только через апи, делают сервис, который поллит данные из апи и кладет в кафку) и складывает в единую сущность с примерно такой моделью:
ids: {
id1: optional id1
id2: optional id2
id3: optional id3
…
},
datasource1: optional datasource1,
datasource2: optional datasource2,
…
все датасорсы имеют свои айдишники, их надо как-то коррелировать, там могут быть разные отношения 1:1, 1:N, N:M это зависит
Если там 1:M например, то внутри ids будет массив других айдишников.
Как это наложить на твою БД и её индексы, зависит от БД. У нас в кассандре много таблиц маппинга, но какие-то бд умеют строить индексы по структуре
Далее основной пейлоад имеет поля в которые тупо перезаписывается (или мержится) пришедшая инфа из datasource. Соответственно может вообще нихуя не придти, поэтому все поля опциональные. У всех должен быть таймштапм послднего ingestion
У тебя может встать вопрос - а что если нужны поля, которые агрегируют несколько датасорсов?
Тогда тебе нужно организовать change feed. Допустим в агрегации участвуют поля datasource1 и datasource2. Когда кто-то из них изменяется посылается событие в топик и отдельные сервис будет пересчитывать aggregatedField и перезаписывать его при получении новых данных.
По итогу на каждое изменение полей (значимое) должно генериться событие в аутпут топик и консумеры должны получать инкременты изменений.
АПИ поверх этого должно учитывать что пейлоад ебанистичеки большой и консумер может хотеть получать только его часть поэтому можно в квери писать имена полей из финального респонса, которые ты хочешь получить (соответственно из БД только их и грузить).
Ты скажешь - ну это же графкуэль - я отвечу - ПОХОЖЕ, но моё мнение что графкуэль говна самовар.
Щас опишу как она решена в одном проекте
Есть сервис, который должен предоставлять ВСЕ данные какие возможно. Он потребляет все возможные кафки (а если инфа доступна только через апи, делают сервис, который поллит данные из апи и кладет в кафку) и складывает в единую сущность с примерно такой моделью:
ids: {
id1: optional id1
id2: optional id2
id3: optional id3
…
},
datasource1: optional datasource1,
datasource2: optional datasource2,
…
все датасорсы имеют свои айдишники, их надо как-то коррелировать, там могут быть разные отношения 1:1, 1:N, N:M это зависит
Если там 1:M например, то внутри ids будет массив других айдишников.
Как это наложить на твою БД и её индексы, зависит от БД. У нас в кассандре много таблиц маппинга, но какие-то бд умеют строить индексы по структуре
Далее основной пейлоад имеет поля в которые тупо перезаписывается (или мержится) пришедшая инфа из datasource. Соответственно может вообще нихуя не придти, поэтому все поля опциональные. У всех должен быть таймштапм послднего ingestion
У тебя может встать вопрос - а что если нужны поля, которые агрегируют несколько датасорсов?
Тогда тебе нужно организовать change feed. Допустим в агрегации участвуют поля datasource1 и datasource2. Когда кто-то из них изменяется посылается событие в топик и отдельные сервис будет пересчитывать aggregatedField и перезаписывать его при получении новых данных.
По итогу на каждое изменение полей (значимое) должно генериться событие в аутпут топик и консумеры должны получать инкременты изменений.
АПИ поверх этого должно учитывать что пейлоад ебанистичеки большой и консумер может хотеть получать только его часть поэтому можно в квери писать имена полей из финального респонса, которые ты хочешь получить (соответственно из БД только их и грузить).
Ты скажешь - ну это же графкуэль - я отвечу - ПОХОЖЕ, но моё мнение что графкуэль говна самовар.
о, очень спасибо
VS
Да так оно и начинается, сначала инфоповод, потом дефицит, потом перепроизводство, а потом какая-нибудь великая депрессия
Вы находитесь тут ——> (c)
RM
почему тебе графкуль не нравится
Могу ответить почему я не использую.
Язык крутой, я бы его использовал, если бы он еще и в спеке пагинацию и фильтрацию, и сортировку описывал, а не только запрос по условному id.
Язык крутой, я бы его использовал, если бы он еще и в спеке пагинацию и фильтрацию, и сортировку описывал, а не только запрос по условному id.
R
но в графкуле ты сам играешь в валидатора и сам играешь в планировщика
Мило. Мне кажется, инженерная сложность грамотной валидации сложности запроса существенно выше сложности решения, где есть разные эндпоинты с урезанными проекциями
Д
Мило. Мне кажется, инженерная сложность грамотной валидации сложности запроса существенно выше сложности решения, где есть разные эндпоинты с урезанными проекциями
так тебе не нужно знать насколько запрос сложный, просто условно делишь поля на средние, тяжелые и дохуя тяжелые
Д
и по аргументам рандомные веса вешаешь
R
лол
Д
никто же не предлагает графкуль открывать, можно сделать так что придётся полчаса сначала запрос подбирать чтобы он прошёл валидатор
R
у тебя ж эффективность напрямую зависит от структуры хранения в базе и индексов
Д
нет
Д
графкуль не про базу вообще