Это не вопрос выбора, а вопрос закупок.

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

Заголовок вебинара: «Как выбрать поставщика IT-системы для энтерпрайза»

Я думаю, принцип выбора: разделяй и ограничивай власть ))

Ген, а ИТшники полную оценку и сравнение ТКП в одно лицо могут? Мне чот кажется, что не очень. Там финансисты нужны рядом как минимум ИМХО, безопасники и много кто ещё.

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

Это зависит. Кто-то и может

https://t.me/bellsoftware друзья, мы сделали канал в котором будем рассказывать о всем интересном, что происходит в OpenJDK и мире Java. Добро пожаловать!

Добрый вечер.
У кого был опыт использования arangodb , подскажите, какие есть плюсы / минусы использования как search engine в сравнении с классикой Solr или Elastic?

arangodb не использовал, т.к. она по сути платная. Все что там интересного идет за деньги. Ну если вы выходите за рамки одного узла. А если вы в рамках одного узла, берите postgresql

А в чём преимущество поискового движка на постгресе?

Смотря что вам нужно от поискового движка.

Коллеги, кто нибудь имеет опыт использования Structurizr от Симона Брауна?

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

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

Да преимущества-то понятны. Поддержка транзакций (поисковый индекс же означает, что у нас есть еще и основное хранилище), понятная и прозрачная история с read your own writes (в es все не так прозрачно), нормальная работа со схемами данных, безопасность опять-таки. Поисковые структуры данных такие же, как в ES. А, и еще в случае чего можно нормально выкачать пару миллионов документов.

ES кажется удобным тем, что туда можно заслать json и он как бы сам разберется со структурой. Но это миф, поскольку работает только на очень простых документах. Ну и про jsonb в postgresql не забываем.  Все-таки изначально ES создавался для задач "поиск a-la google", когда надо достать первые 100 документов да и то не целиком, а лишь сниппет да url из них. И не так уж далеко он от этого ушел за годы развития.

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

Мы планируем пристально на него посмотреть. Было бы интересно послушать про чей-нибудь опыт.

Мы используем. Но пока не очень интенсивно. Жутко неудобный интерфейс редактирования, но работает. В перспективе часть диаграмм хотим генерить из кода, но пока руками. Отлично интегрируется в Confluence. Стремный опыт конкурентного изменения (теряли работу).

Спасибо за сравнение. Стало понятнее)

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

А какие задачи по поиску? Что именно нужно? Именно фултекст? Чем не устраивает full-text в том же PG? Да и чем ES не устраивает?