можно разнести нагрузку по разным репликам
например, явно обращаясь к реплике https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-preference.html
наверняка есть и другие варианты

Делать join между несколькими шардами нельзя. Но при индексации можно указать parent и оба документа окажутся на одном шарде.

Есть parent-child query. Это аналог join.

https://ru.m.wikipedia.org/wiki/Подсистема_для_приложений_на_базе_UNIX

Как вы шардируете данные?
Заводите новый индекс, через определенный интервал времени?
Просто на горячую изменить кол-во шардов для индекса невозможно.
Наверняка используете роутинг, т.к. при увеличении кол-ва данных будет падать скорость поиска.
Расскажите, пожалуйста, про "правильную готовку".

Согласен, я упомянул скролл, чтобы просто показать эту возможность.

Да это же просто пример на кошечках и собачках)
Не в посещаемости дело, а в возможностях поиска.

ES умеет постраничную выдачу. В этой статье есть секция "Сортировка", в ней используется ключ size.
Так же с помощью Scroll можно избежать проблемы постраничной выдачи, когда между получением страниц происходит вставка. Т.е. мы выбираем первую страницу, в кто-то добавил документ, который мог быть на первой странице, соответственно все документы съедут и последний документ с первой страницы продублируется и встанет на первое место на вторую страницу. А Scroll делает снимок и новый документ в выдачу не попадет. Надеюсь понятно объяснил)
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html

Распределенная система подвержена сетевым сбоям и разделению кластера. Что произойдет если кластер разделится на 2 половины и будет происходить запись в обе половины? Это условный пример, и нужно смотреть как ES поведет себя в этой ситуации, наверняка в меньшей части кластера мастер не будет выбран и запись не пойдет.
Я просто хочу обратить внимание, что с распределенными системами не все так просто. И придется чем-то жертвовать.
В сети есть много материалов, тот же Aphyr. Можно погуглить материалы про cap теорему.

Тут нужно быть осторожным, тк ES может потерять данные, особенно в кластерной конфигурации.
https://aphyr.com/posts/317-jepsen-elasticsearch
Я делал перевод статьи по ES как NoSQL базу — https://habrahabr.ru/company/percolator/blog/222765/
Есть даже проект Crate.io. Это что-то вроде sql над es: https://crate.io/a/how-is-crate-data-different-than-elasticsearch/
Postgresql из коробки не умеет кластер, есть PostgresXL но это немного не о том.

Для начала этого урока будет достаточно. Ваше приложение после записи в mysql будет писать данные в ES. Т.е. взаимодействие идет через приложение.
Я советую потом прочитать официальную документацию, она хорошо написана и там есть классные примеры.

Можно не только хранить ID, но и поля этого человека и уже не обращаться к mysql. Я упоминал об этом в статье.

Mysql — это надежное хранилище, источник исходных данных, ES — поисковый движок. У них разные задачи.
В большинстве случаев используют Mysql + ES. Бывают случаи, когда не очень важные данные хранят сразу в ES, например логи.
ES может забрать на себя нагрузку на чтение с Mysql, т.е. пишем в Mysql, а читаем из ES. ES горизонтально масштабируется значительно проще, чем mysql, т.к. есть автоматический шардинг.
Надо смотреть на конкретные запросы и вполне возможно, что mysql при выборке по первичному ключу будет быстрее.
Но нужно понимать, что в ES есть значительно больше типов запросов, чем в mysql, например поиск по geo координатам, с помощью плагинов можно сделать поиск по изображениям.
ПС. под mysql тут можно понимать любую реляционную БД.

буду признателен коллегам, которые обозначат эти решения.

github.com/darkleaf/date_range_formatter
Это решение для ruby или ruby on rails.
Все работает через локали github.com/darkleaf/date_range_formatter/blob/master/lib/locale/en.yml

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

Можем или в комментариях или в личке обсудить разные подходы.
Вот с что я использовал:

github.com/darkleaf/react-immutable-todo
Это один из первых экспериментов с react и immutable.
Для изменения состояния используются чистые функции github.com/darkleaf/react-immutable-todo/blob/master/lib/item/transitions.js

Недавно была задача реализовать сложные интерактивные формы для админки. Тут отлично подходили курсоры. Но не одна из реализаций мне не подошла по разным причинам. По этому я написал свою реализацию на 20 полезных строчек кода.
github.com/darkleaf/state/blob/master/state.js
Кратко про курсоры. Они позволяют пробрасывать некоторую часть состояния подкомпоненту, подкомпонент имеет доступ только к этим данным и может обновить только эти данные. При этом курсоры иммутабельны и позволяют использовать shouldComponentUpdate в реакте для очень быстрого рендеринга. Если интересно, то могу подробнее рассказать про курсоры.

Следующим шагом планирую разбираться с redux :)

> Вот честно, затея цикла публикаций может и хорошая, но реализация ни о чём: ни одна затронутая тема не раскрыта в достаточном объёме. Прочитал и не понял что хотел сказать автор и кто есть целевая аудитория. Новичкам слишком мало данных, а более опытным людям — слишком скучно и очевидно.

Спасибо за отзыв. У меня нет большого опыта в написании статей. Если у кого-то есть желание и время помочь в написании статей о rails, то я всегда открыт предложениям. Можно, например, по очереди публиковать статьи или проставлять ссылки на профиль.

> «отображение уведомлений»
тут имелись в виду flash и сообщения об ошибках-исключениях

> Пример со статусами проекта наигран
Естественно используется стейтмашина. Пример о том, что при завершении проекта нужно заполнить дополнительные поля. В форме редактирования проекта этих полей быть не должно. В примере кода все показано.

> С орзанизацией контроллеров
Тут нужно посмотреть на вашу ситуацию. Моя методика взята из статьи habrahabr.ru/post/136461. Я ее применяю на протяжении 3х лет и ни разу мои контроллеры не распухали. Метапрограммирование тоже полка о двух концах, с ним нужно быть аккуратным.

> Про хлебные крошки вообще не понятно…
Пробовал все гемы, которые нашел на github(их штук 5).
Они как я писал в статье, они все запрашивают слишком много данных. Моя реализация требует указания только самого необходимого. Все, что она может получить самостоятельно — получает сама. Например, по имени контроллера из локали получает заголовок, по названию action так же получает заголовок.

Я начал с самого простого. Бизнес-логику оставил на десерт. Про коллбэки тоже напишу.

Это от ситуации зависит.

Как в твоем случае сделать обработку прав доступа?
А если меню древовидное?
Удобнее иметь функцию, которая рендерит один элемент меню. А функция может быть любой: helper или partial.