Да погугли, про это много материалов.

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

тогда еще нужна "высота" от уровня моря/земли : )

А в чем проблема?

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

Ну погугли. Там все равно параллельный поиск по шардам с последующим джойном, увы.

Если по термам, то вот можно сначала на одну ноду сходить, а потом если ввели другие термы ,то на другую. Спасибо всем.  Идея прояснилась.

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

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

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

Количество звёзд

+1
Готовься форкать все опенсорсное

Пока мелкий хватай все подряд но осторожно

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

без аудита никак)

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

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

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

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

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

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

Продукт новый для вас. Откуда у вас экспертиза и как вы посчитаете TCO?

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