hazelcast 대 ehcache

hazelcast 대 ehcache

---

제목에서 알 수 있듯이 질문은 분명합니다. adv./disadv에 대한 귀하의 의견을 듣고 싶습니다. 그들 사이의 차이점.

업데이트 : 분산 캐싱 / 잠금 메커니즘과 같은 장점과 응용 프로그램에 적용하는 동안 매우 쉬운 구성 때문에 Hazelcast를 사용하기로 결정했습니다.

---

우리는 가장 큰 온라인 광고 및 전자 상거래 플랫폼 중 하나에 두 가지를 모두 시도했습니다. 우리는 ehcache / terracotta (서버 어레이)로 시작했는데, 잘 알려져 있고 Terracotta가 뒷받침하며 hazelcast보다 더 큰 커뮤니티 지원을 제공합니다.
프로덕션 환경 (분산, 하나의 노드 클러스터를 넘어서)에 변화를 주었을 때 백엔드 아키텍처가 정말 비싸 져서 hazelcast에 기회를 주기로 결정했습니다.

Hazelcast는 매우 간단하며, 구성 오버 헤드없이 말한대로 수행하고 성능이 매우 뛰어납니다.

우리의 캐싱 레이어는 1 년 넘게 헤이즐 캐스트 위에 올려 져 있습니다.

---

Ehcache는 Java 시스템에서 인기가 있었지만 다른 캐싱 솔루션보다 유연성이 떨어졌습니다. 나는 Hazelcast로 놀았고 예, 작업을 수행했으며 실행하기 쉬웠으며 Ehcache보다 최신입니다. Ehcache는 Hazelcast보다 훨씬 더 많은 기능을 가지고 있고, 더 성숙하고, 그 뒤에 큰 지원이 있다고 말할 수 있습니다.

좋은 오래된 Memcache, Membase (현재 CouchBase), Redis, AppFabric, 지속성을 포함하거나 포함하지 않는 키 값 저장소를 제공하는 여러 NoSQL 솔루션과 같은 모든 다른 속성 및 솔루션을 포함하는 여러 다른 좋은 캐시 솔루션도 있습니다. 그들은 모두 트랜잭션과 함께 CAP 정리 또는 BASE 정리를 구현한다는 점에서 다른 특성을 가지고 있습니다.

응용 프로그램에서 원하는 기능을 가진 기능에 대해 더 신경을 써야합니다. 다시 한 번 응용 프로그램에 대해 CAP 정리 또는 BASE 정리를 고려해야합니다.

이 테스트 는 Netflix의 클라우드 에서 Cassandra로 최근에 수행 되었습니다. 약 300 개의 인스턴스로 초당 백만 개의 쓰기에 도달했습니다 . Cassandra는 메모리 캐시가 아니지만 데이터 모델은 키 값 쌍으로 구성된 캐시와 같습니다. Cassandra 를 분산 메모리 캐시로 사용할 수도 있습니다 .

---

Hazelcast는 확장에 악몽이었으며 안정성은 여전히 ​​중요한 문제입니다.

그리드 구성 요소 선택에 대한 전용 클라이언트는 다음과 같습니다.

1. 백업 지점 (슈퍼 클라이언트)을 무효화하여 어디서나 노드 손실을 견딜 수없는 지저분한 버전
2. 그리드의 처리 노드에 어떤 유형의로드 밸런싱도 허용하지 않는 엄청나게 느린 기본 클라이언트 옵션입니다.

어떤 호스트가이 데이터 그리드에서 레코드를 요청할 수 있다면 그것은 좋은 디자인이 될 것이지만, 당신은 그 두 가지 부족한 옵션에 갇혀 있습니다.

또한 데이터베이스 스레드 풀이 개별 멤버를 잠그고 데이터베이스에 아무것도 쓰지 않는 여러 문제로 인해 영구 레코드 손실이 자주 발생하며 JVM을 새로 고치려면 몇 시간 동안 전체 작업을 중단해야하는 경우가 많습니다. 1.9.6에서는 약간 진정 된 것처럼 보이지만 스플릿 브레인도 여전히 문제입니다.

반창고로 사용하는 대신 Ehcache로 이동하고 데이터베이스 계층을 개선하기 위해 집결합니다.

---

Hazelcast는 노드 (표준 1)가있을 때마다 모든 것을 직렬화하므로 Hazelcast에 저장할 데이터는 직렬화를 구현해야합니다.

http://open.bekk.no/efficient-java-serialization/

---

헤이즐 캐스트는 저에게 악몽이었습니다. 클러스터 된 Websphere 환경에서 "작동"할 수있었습니다. 나는 "일하는"이라는 용어를 느슨하게 사용합니다. 첫째, Hazelcast의 모든 문서는 오래되었으며 더 이상 사용되지 않는 메서드 호출을 사용하는 예제 만 보여줍니다. Javadocs에 주석없이 새 코드를 사용하고 문서에 예제가없는 것은 매우 어렵습니다. 또한 J2EE 컨테이너 코드는 Websphere에서 XA 트랜잭션을 지원하지 않기 때문에이 시점에서 작동하지 않습니다. 유일한 J2EE 예제를 명시 적으로 따르는 코드를 호출하면 오류가 발생합니다 (마일스톤 3.0이이 문제를 해결하는 것처럼 보입니다). Hazelcast를 J2EE 트랜잭션에 참여시키는 것을 잊어야했습니다. Hazelcast는 확실히 비 EJB / Non-J2EE 컨테이너 환경에 맞춰진 것 같습니다. Hazelcast에 전화를 겁니다. getAllInstances ()는 한 엔터프라이즈 Java Bean에서 다른 Java Bean으로 전환 할 때 Hazelcast의 상태에 대한 정보를 유지하지 못합니다. 따라서 데이터에 대한 액세스 권한을 부여하는 호출을 실행하기 위해 새 Hazelcast 인스턴스를 만들어야합니다. 이로 인해 많은 Hazelcast 인스턴스가 동일한 JVM에서 시작됩니다. 또한 Hazelcast에서 데이터를 검색하는 것은 빠르지 않습니다. Native Client를 사용하고 클러스터의 구성원으로 직접 데이터 검색을 시도했습니다. 나는 헤이즐 캐스트에 625 개의 개체만을 포함하는 51 개의 목록을 저장했습니다. 목록에서 직접 쿼리를 수행 할 수 없었고 해당 기능에 액세스하기 위해지도를 저장하고 싶지 않았습니다 (지도에서 SQL 작업을 수행 할 수 있음). Hazelcast는 전체 목록을 직렬화하고 단순히 델타 (변경된 사항)를 제공하지 않고 유선으로 전송하기 때문에 625 개 개체의 각 목록을 검색하는 데 약 0.5 초가 걸렸습니다. 또 다른 한 가지는 TCPIP 구성으로 전환하고 클러스터에 포함하려는 서버의 IP 주소를 명시 적으로 나열해야했습니다. 기본 멀티 캐스트 구성이 작동하지 않았고 Google의 그룹 토론에서 다른 사람들도 이러한 어려움을 겪고 있습니다. 요약하자면 결국 여러 시간의 고문적인 프로그래밍 구성과 시행 착오를 통해 클러스터에서 8 대의 시스템이 통신하게되었지만 (문서는 거의 도움이되지 않음) 그렇게했을 때도 각각에 생성되는 인스턴스와 파티션의 수를 제어 할 수 없었습니다. JVM은 EJB / J2EE에 대한 Hazelcast의 절반 완료 특성으로 인해 매우 느 렸습니다. 저는 제가 작업하는 실업 보험 응용 프로그램에서 실제 사용 사례를 구현했으며 코드는 데이터베이스에 대한 직접 호출을 훨씬 빠르게 수행했습니다. Hazelcast가 광고 된대로 작동했다면 내가하려는 작업을 구현하기 위해 별도의 서비스를 사용하고 싶지 않았기 때문에 멋 졌을 것입니다. MongoDB를 광범위하게 사용했기 때문에 메모리 캐시의 전체를 건너 뛰고 내 개체를 별도의 저장소에 문서로 직렬화 할 수 있습니다.

---

Ehcache의 한 가지 장점은 대규모 성능 랩에서 광범위한 성능, 장애 조치 및 플랫폼 테스트를 수행하는 회사 (Terracotta)의 지원을 받는다는 것입니다. 테라코타는 지원, 배상금 등을 제공합니다. 많은 회사에게 이러한 종류의 것이 중요합니다.

Hazelcast를 사용하지 않았지만 사용하기 쉽고 작동한다고 들었습니다. Hazelcast 대 Terracotta / Ehcache의 확장 성 또는 성능과 관련하여 아무것도 듣지 못했지만 Terracotta가 수행하는 확장 성 및 장애 조치 테스트의 양을 고려할 때 Hazelcast가 프로덕션 배포에서 경쟁력이있을 것이라고 상상하기 어렵습니다. 그러나 나는 그것이 더 작은 용도로 잘 작동 할 것이라고 생각합니다.

[편견 : 저는 Terracotta의 전직 직원입니다.]

참고 URL : https://stackoverflow.com/questions/5245487/hazelcast-vs-ehcache