Size: a a a

Архитектура ИТ-решений

2020 October 15

PD

Phil Delgyado in Архитектура ИТ-решений
Да погугли, про это много материалов.
источник

N

Nikolay in Архитектура ИТ-решений
То ,что там инвертированный индекс это понятно. Как его шардировать. Вот эту идею хочу понять.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Oleg Soroka
смотря для каких целей
как человек, выросший в городе без улиц - я немного шире смотрю на топик 🙂
тогда еще нужна "высота" от уровня моря/земли : )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Nikolay
То ,что там инвертированный индекс это понятно. Как его шардировать. Вот эту идею хочу понять.
А в чем проблема?
источник

N

Nikolay in Архитектура ИТ-решений
Phil Delgyado
А в чем проблема?
на первый взгляд можно по термам. может лучшие есть варианты.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну погугли. Там все равно параллельный поиск по шардам с последующим джойном, увы.
источник

N

Nikolay in Архитектура ИТ-решений
Если по термам, то вот можно сначала на одну ноду сходить, а потом если ввели другие термы ,то на другую. Спасибо всем.  Идея прояснилась.
источник

D

Danil in Архитектура ИТ-решений
По каким признакам вы решаете использовать некий опенсорс проект у себя или нет. Я говорю скорее не про nginx или clickhouse условный, а более мелкие проекты. Я вот сейчас смотрю репо небольшого проекта для интеграции куба с ажуровским хранилищем секретов.
Он находится в оф. группе Azure, но при этом в документации пишется, что проект к разработчикам и сапорту Azure не имеет никакого отношения.

Какие кто критерии использует обычно?
источник

A

Alex in Архитектура ИТ-решений
Danil
По каким признакам вы решаете использовать некий опенсорс проект у себя или нет. Я говорю скорее не про nginx или clickhouse условный, а более мелкие проекты. Я вот сейчас смотрю репо небольшого проекта для интеграции куба с ажуровским хранилищем секретов.
Он находится в оф. группе Azure, но при этом в документации пишется, что проект к разработчикам и сапорту Azure не имеет никакого отношения.

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

N

Nikolay in Архитектура ИТ-решений
Danil
По каким признакам вы решаете использовать некий опенсорс проект у себя или нет. Я говорю скорее не про nginx или clickhouse условный, а более мелкие проекты. Я вот сейчас смотрю репо небольшого проекта для интеграции куба с ажуровским хранилищем секретов.
Он находится в оф. группе Azure, но при этом в документации пишется, что проект к разработчикам и сапорту Azure не имеет никакого отношения.

Какие кто критерии использует обычно?
Количество звёзд
источник

IA

Igor A in Архитектура ИТ-решений
+1
Готовься форкать все опенсорсное
источник

IA

Igor A in Архитектура ИТ-решений
Пока мелкий хватай все подряд но осторожно
источник

D

Danil in Архитектура ИТ-решений
ну меня например еще несколько смущает то, что конкретно этот служит для того, чтобы забирать секреты из хранилища - пароли/сертификаты/... Прослойка между кубом и ажуровским сервисом. У проекта 200 звезд. И как понять насколько я доверяю? Только код читать?
источник

A

Alex in Архитектура ИТ-решений
без аудита никак)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Danil
По каким признакам вы решаете использовать некий опенсорс проект у себя или нет. Я говорю скорее не про nginx или clickhouse условный, а более мелкие проекты. Я вот сейчас смотрю репо небольшого проекта для интеграции куба с ажуровским хранилищем секретов.
Он находится в оф. группе Azure, но при этом в документации пишется, что проект к разработчикам и сапорту Azure не имеет никакого отношения.

Какие кто критерии использует обычно?
- в github смотрим количество звёзд и форков, это косвенно говорит о зрелости и популярности
- в github смотрим Insights/Pulse и Insights/Commits , это косвенно говорит о том, развивается проект или нет
- всесторонне тестируем весь нужный нам фунционал, в том числе нагружаем и тестируем отказоустойчивость
- не забываем про дизайн и абстракции, в идеале нужно иметь возможность выпилить всё что угодно если это потребуется
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Можно использовать всё что угодно, если вы уверены, что это работает, не умирает под вашими нагрузками и ведёт себя предсказуемо при падениях инфраструктуры, пусть даже и виртуальной. Но главное, обеспечить себе возможность выпилить за разумное время, если что-то пошло не так.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Первое, на что смотрю лично я - это архитектура. Хорошо когда архитектура хотя бы верхнеуровнево описана. По архитектуре можно судить о многом. При этом, архитектура должна интуитивно нравиться. Если кажется, что архитектура выглядит как какая-то непонятная хрень, то скорее всего так и есть.

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

Бывает такая архитектура - история забытых компромиссов.
источник

IV

Igor Voronin in Архитектура ИТ-решений
Danil
По каким признакам вы решаете использовать некий опенсорс проект у себя или нет. Я говорю скорее не про nginx или clickhouse условный, а более мелкие проекты. Я вот сейчас смотрю репо небольшого проекта для интеграции куба с ажуровским хранилищем секретов.
Он находится в оф. группе Azure, но при этом в документации пишется, что проект к разработчикам и сапорту Azure не имеет никакого отношения.

Какие кто критерии использует обычно?
По стоимости владения и наличии экспертизы и поддержки
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Igor Voronin
По стоимости владения и наличии экспертизы и поддержки
Продукт новый для вас. Откуда у вас экспертиза и как вы посчитаете TCO?
источник

IV

Igor Voronin in Архитектура ИТ-решений
Gennadiy Kruglov
Продукт новый для вас. Откуда у вас экспертиза и как вы посчитаете TCO?
Это и есть основной вопрос. Как будут решаться проблемы, кем и за чей счёт.
источник