У меня нет большого опыта запуска ES в продакшене, но, по сути, гарантировать, что когда вы сохраняете данные, они остаются постоянными, особенно в распределенной системе, сложно. Есть много-много пограничных случаев, которые очень трудно исправить, и базе данных требуется время, чтобы созреть и отсортировать эти пограничные случаи. Менее надежная база данных — это та, в которой, вероятно, не устранены все эти проблемы.
Конечно, ElasticSearch — это популярная база данных с открытым исходным кодом, которую поддерживает процветающее сообщество, поэтому, скорее всего, нет четко определенных случаев, когда «ваши данные будут потеряны в этом случае», скорее, есть вероятные случаи, которые еще не встречались, или когда с ними сталкивались пользователи в дикой природе, пользователи, которые сталкивались с ними, не заботились об отладке, потому что они использовали ES только в качестве вторичного хранилища данных и могли восстановить его из своего основного хранилища данных. Всякий раз, когда выявляется случай, когда ES теряет данные при хорошо понятных обстоятельствах, специалисты по сопровождению ES будут быстро это исправлять.
Наиболее типичными вариантами использования ES являются вторичное хранилище базы данных, и в таком случае надежность не так важна, поскольку хранилище данных может быть перестроено из основного хранилища. Соответственно, вы обнаружите, что надежность не является таким высоким приоритетом для сопровождающих ES, потому что их пользователи не просят об этом — это не значит, что это не высокий приоритет, просто по сравнению с другими базами данных, это не так высоко.
Таким образом, если вы используете ES, у вас больше шансов столкнуться с ошибками, из-за которых вы потеряете данные, чем с другими базами данных, которые либо более зрелые, либо уделяют больше внимания надежности при их разработке.
Что касается того, следует ли вам регулярно удалять базу данных ES и воспроизводить события, это действительно зависит от вашего варианта использования и того, насколько важно, чтобы ваша база данных ES была согласованной. Многие крайние случаи, связанные с надежностью ES, вероятно, приводят к серьезным повреждениям со значительной потерей данных — т. е. вы будете знать, если это произойдет, поэтому в этом случае нет необходимости регулярно отбрасывать и воспроизводить заново. Еще одна вещь, которую следует учитывать, заключается в том, что из-за того, как работают стороны чтения CQRS, у вас будет только ограниченное количество писателей в вашем хранилище ES, и вы можете легко контролировать этот параллелизм. Это означает, что всплеск нагрузки не приведет к всплеску числа одновременных операций записи, а произойдет то, что ваше хранилище ES может временно отставать по согласованности от вашего основного хранилища. Из-за этого вы, вероятно, с меньшей вероятностью столкнетесь с пограничными случаями, которые могут привести к потере данных ES.
Таким образом, вы, вероятно, в порядке, не беспокоясь об удалении и восстановлении, если только не произойдет что-то катастрофическое, если только последствия незаметной потери небольших объемов данных таким образом, что вы этого не заметите, настолько высоки, что невероятно малая вероятность того, что это может произойти, неприемлема. .
person
James Roper
schedule
17.05.2018
