Было бы неплохо использовать Terracotta в качестве решения для сохранения (замены базы данных)? Я специально интересуюсь проблемами целостности данных и поддержкой транзакционных систем.Об использовании Terracotta в качестве решения о постоянстве
Терракота является transactional (синхронизированные блоки образуют транзакции модифицированных объектов), но не является и не хочет быть совместимым с JTA. Существует довольно продолжительное обсуждение транзакций и некоторых распространенных заблуждений о Terracotta here.
Я написал blog post about data lifetimes и как это должно задуматься над тем, чтобы определить возможности использования Терракотты. Короче говоря, сладкое пятно Terracotta - это прецедент, где вам нужно постоянство и доступность (ваше приложение может потерпеть крах, но вам все еще нужны данные), но где данные не обязательно критически важны в долгосрочной перспективе.
Каноническим примером являются данные, важные в контексте пользовательского сеанса в веб-приложении, такие как информация о корзине покупок. Вы хотите сохранить эти данные постоянными, чтобы при сбое вашего веб-приложения вы поддерживали корзину покупок. Но сама тележка может или не может быть куплена. Таким образом, вы храните его в Terracotta до его покупки, а затем сохраняете в базе данных как данные «системы записи».
Исторически данные, хранящиеся в базе данных, всегда были «системой записи», которая была критически важна для долгосрочного успеха вашего бизнеса: клиентов, заказов и т. Д. С сегодняшними «безгосударственными» архитектурами (которые действительно 't без гражданства), мы переносим все среднесрочные данные в базу данных. Это означает, что мы бесполезно наказываем нашу базу данных (с дополнительной работой и хранением) и нашими разработчиками (которые должны обрабатывать несоответствие объектно-реляционного импеданса даже при использовании ORM). Лучший подход - оставить его в объектах и сгруппировать его с помощью Terracotta. Ряд недавних пользователей Terracotta использовали эту технику для значительного сокращения их базы данных (сэкономить миллионы долларов), одновременно увеличивая их способность масштабироваться.
Существует вопрос о точке интеграции с базой данных и о том, как надежно выполнить передачу. Мы видели это в качестве примера использования недавно выпущенного Examinator (веб-приложение для справки Spring/Terracotta/Tomcat/MySql). Когда экзамены ведутся, государство (ответы на вопросы, рандомизированные заказы на выбор, вопросы, отмеченные для обзора) хранится в Terracotta. Но когда экзамены завершены, итоговый балл рассчитывается и сохраняется в базе данных долгосрочно.
Чтобы сделать это безопасно, мы используем стратегию ключа Hibernate, которая сначала генерирует идентификатор строки базы данных в объекте в Terracotta, а затем сохраняет данные в db, а затем удаляет из Terracotta. Этот сценарий имеет потенциальное состояние гонки, если приложение падает после сохранения в базу данных, но перед удалением из Terracotta. В этом случае приложение может попытаться повторно сохранить данные в db, возможно, создав две строки. Но из-за предварительно сгенерированного идентификатора мы можем определить, была ли ранее написана строка или нет, и избежать этой проблемы.
Таким образом, я не думаю, что Terracotta заменит ваш db в ближайшее время. Это слишком новая операционная система, чтобы даже считаться таковой в большинстве магазинов. Модель использования отличается. В кучу нет запросов или возможностей SQL (ваши возможности запросов определяются вашей объектной моделью). Я думаю, что он может и начинает заменять среднесрочное использование данных, когда это намного дешевле и проще. Однако некоторые люди начинают экспериментировать с ним для длительного хранения.
Терракота - это только Java. Если это нормально для вас, чтобы вы были заблокированы в этой технологии, без возможности просто написать некоторые скрипты (без JVM) на других языках, а затем пойти с ним.
Статья Kill Your Database with Terracotta была действительно приятной.