Google App Engine의 Java용 JDO 및 JPA

StackOverflow https://stackoverflow.com/questions/1418219

문제

Struts2를 사용하여 Google App Engine에서 프로젝트를 개발하고 싶습니다.데이터베이스에는 JPA와 JDO의 두 가지 옵션이 있습니다.너희들이 나에게 그것에 대해 제안해 주시겠습니까?둘 다 나에게는 새로운 것이므로 배워야 한다.그래서 나는 당신의 대답 후에 하나에 집중할 것입니다.

감사해요.

도움이 되었습니까?

해결책

JPA는 Sun의 끈기에 대한 표준이며, JDO는 IMHO 죽어 가고 있습니다 (실제로는 죽었지 만 여전히 움직입니다). 다시 말해, JPA는 장기적으로 더 나은 투자 인 것 같습니다. 그래서 둘 다 새로운 것이라면 JPA를 선택할 것 같아요.

다른 팁

GAE/J Google Group에는 바로 그 문제에 대한 몇 가지 게시물이 있습니다. 나는 거기에서 검색을하고 사람들의 의견을 봅니다. 위에서 표현 된 의견에 대해 매우 다른 메시지를 받게됩니다. 또한 bigtable이 RDBM이 아니라는 사실에도 집중하십시오. 작업에 적합한 도구를 사용하십시오

방금 Datanucleus 자체에 의해 JPA와 JDO의 비교를 보았습니다.http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html눈을 뜨는 사람.

나는 JDO의 행복한 사용자입니다. 좋은 일을 계속하십시오.

JDO가 죽었다고 주장하는 사람들은 장점이 없습니다. 여기에 내가 읽은 내용은 Pro EJB 3 Java Persistence API에서 읽은 내용입니다. 앞으로 표준. ". 저자 Mike Keith는 EJB3의 공동 특성 리더입니다. 물론 그는 JPA의 큰 지지자이지만, 그가 거짓말을하기에 충분히 편견이 있다고 의심합니다.

이 책이 출판되었을 때 JDO는 JPA보다 고급 기술 기능을 가지고 있지만 대부분의 주요 공급 업체는 JDO가 아닌 JPA 뒤에 통합 된 것이 사실입니다. IBM/Oracle과 같은 EE 세계의 큰 플레이어도 큰 RDBMS 공급 업체이기 때문에 놀라운 일이 아닙니다. 더 많은 고객이 프로젝트에서 비 RDMB보다 RDMB를 사용하고 있습니다. Jdo는 Gae가 큰 부스트를 줄 때까지 죽어 가고있었습니다. GAE Data Store는 관계형 데이터베이스가 아니기 때문에 의미가 있습니다. 일부 JPA 기능은 Aggregation Queries, Join Queries, 소유 한 관계를 소유 한 BigTable과 함께 작동하지 않습니다. BTW, GAE는 JDO 2.3을 지원하지만 JPA 1.0 만 지원합니다. GAE가 대상 클라우드 플랫폼이라면 JDO를 추천합니다.

레코드의 경우 GAE (Google App Engine)이므로 Oracle/Sun 규칙이 아닌 Google 규칙을 사용합니다.

그 아래에서 JPA는 GAE에 적합하지 않으며 불안정하며 예상대로 작동하지 않습니다. Google은 기꺼이 지원하지는 않지만 최소한의 경우를 기꺼이 지원하지 않습니다.

다른 부분의 경우 JDO는 GAE에서 상당히 안정적이며 Google에서 잘 문서화되어 있습니다.

그러나 Google은 그 중 어느 것도 권장하지 않습니다.

http://code.google.com/appengine/docs/java/datastore/overview.html

저수준 API는 최고의 성능을 제공하고 GAE는 성능에 관한 것입니다.

http://gaejava.appspot.com/

예를 들어 10 개 엔티티를 추가하십시오

파이썬 : 68ms

JDO : 378ms

Java Native : 30ms

JDO와 JPA 사이의 경주에서 나는 Datanucleus 포스터에만 동의 할 수 있습니다.

우선, 그리고 가장 중요한 것은 Datanucleus의 포스터는 그들이 무엇을하고 있는지 알고 있습니다. 그들은 결국 지속적인 라이브러리를 개발하고 있으며 관계 (예 : 큰 테이블) 이외의 데이터 모델에 익숙합니다. 나는 Hibernate의 개발자가 여기에 있었을 것이라고 확신합니다. "핵심 라이브러리를 구축 할 때의 모든 가정은 관계형 모델과 밀접하게 결합되어 있으며, Hibernate는 GAE에 최적화되지 않습니다."

둘째, JPA는 의심 할 여지없이보다 광범위하게 사용되며 공식 Java EE Stack의 일부가되는 것이 약간 도움이되지만 반드시 더 나은 것은 아닙니다. 실제로, JDO는 그것에 대해 읽는다면 JPA보다 높은 수준의 추상화에 해당합니다. JPA는 RDBMS 데이터 모델과 밀접하게 결합됩니다.

프로그래밍 스탠드 포인트에서 JDO API를 사용하는 것이 훨씬 더 나은 옵션입니다. 개념적으로 훨씬 덜 타협하기 때문입니다. 사용하는 공급자가 기본 데이터베이스를 지원하는 경우 원하는 데이터 모델로 이론적으로 전환 할 수 있습니다. (실제로 당신은 GAE의 객체에 기본 키를 설정하고 특정 데이터베이스 제공 업체 (예 : Google)에 자신을 묶을 것이기 때문에 그러한 높은 수준의 투명성을 거의 달성하지 못합니다). 그래도 마이그레이션하는 것이 더 쉽습니다.

셋째, 최대 절전 모드, 일식 링크, 심지어 GAE와 함께 스프링을 사용할 수도 있습니다. Google은 응용 프로그램을 구축하는 데 사용되는 프레임 워크를 사용할 수 있도록 큰 노력을 기울인 것 같습니다. 그러나 사람들이 RDBMS에서 실행중인 것처럼 GAE 응용 프로그램을 구축 할 때 깨닫는 것은 느린다는 것입니다. gae의 봄은 느립니다. 이 주제에 대한 Google Google IO 비디오를 통해 사실이라는 것을 확인할 수 있습니다.

또한 표준을 준수하는 것은 원칙적으로 내가 박수를 보내는 좋은 합리적인 일입니다. 반면에 JPA는 Java EE Stack의 일부인 경우 때때로 사람들이 옵션 개념을 잃게 만듭니다. 만약 당신이 원한다면, Java Server가 직면 한 것이 Java Ee 스택의 일부라는 것을 깨달으십시오. 그리고 웹 GUI 개발을위한 믿을 수 없을 정도로 깔끔한 솔루션입니다. 그러나 결국, 왜 사람들, 내가 그렇게 말할 수 있다면 더 똑똑한 사람들 이이 표준에서 벗어나 GWT를 대신 사용합니까?

이 모든 것에서, 나는 JPA에 대한 매우 중요한 일이 있다고 생각해야한다. 그것은 Guice와 JPA에 대한 편리한 지원입니다. Google 은이 시점에서 평소와 같이 똑똑하지 않은 것으로 보이며 현재는 JDO를 지원하지 않는 것이 좋습니다. 나는 여전히 그들이 그것을 감당할 수 있다고 생각하고, 결국 Guice는 Jdo도 마찬가지입니다.

가서 jdo. 경험이 없더라도 픽업하기가 어렵지 않으며 벨트 아래에 새로운 기술을 갖게 될 것입니다!

내가 생각하는 것은 사용에 대해 끔찍하다 JDO 글을 쓰는 시점에서 이것은 유일한 구현 공급 업체가 Datanucleus 그리고 그 단점은 경쟁의 부족으로 다음과 같은 수많은 문제로 이어집니다.

  1. 같은 일부 측면에 대한 자세한 문서 extensions
  2. 당신은 일반적으로 저자들로부터 냉소적 인 반응을 얻습니다 (로그를 확인 했습니까?
  3. 당신은 도움이되는 시간 안에 질문에 대한 답을 얻지 못합니다. 때로는 7 일 이내에 답을 얻는다면 여기에서도 행운을 생각해야합니다. StackOverflow

나는 항상 누군가가 구현을 시작하기를 바라고 있습니다 JDO 사양 자체는 더 많은 것을 제공 할 수 있습니다. 무료 커뮤니티에 대한 관심과 지원 비용을 지불하는 것에 대해 항상 귀찮게하지는 않지만 Datanucleus 저자는 상업적 지원에만 관심이 있지만 나는 단지 말하고 있습니다.

나는 개인적으로 고려합니다 Datanucleus 저자는 의무가 없습니다 Datanucleus 그 자체도 커뮤니티입니다. 그들은 언제든지 전체 프로젝트를 중단 할 수 있으며 아무도 그것을 판단 할 수 없습니다. 그것은 그들의 노력과 자신의 재산입니다. 그러나 당신은 당신이 무엇을하고 있는지 알아야합니다. 우리 개발자 중 한 명이 사용할 프레임 워크를 찾으면 프레임 워크의 저자를 처벌하거나 명령 할 수는 없지만 반면에 작업이 필요합니다! 그 프레임 워크를 쓸 시간이 있다면 왜 처음에 하나를 찾을 수 있습니까?!

반면에, JDO 그 자체는 객체 수명주기와 같은 합병증과 직관적이지 않고 일반적이지 않은 물건을 가지고 있습니다 (제 생각에는).

편집 : 이제 나도 알고 있습니다 JPA 객체 수명주기 메커니즘을 시행하므로 표준 ORM API (즉 JPA 또는 JDO)

내가 가장 좋아하는 것 JDO 상당한 노력없이 데이터베이스 관리 시스템을 사용하는 능력입니다.

GAE/J는 연말 전에 MySQL을 추가 할 예정입니다.

JPA는 표준화 된 API로 푸시 된 것처럼 보이며 최근 EJB3.0에서 추진력을 얻었습니다. JDO는 증기를 잃어버린 것 같습니다.

어느 것도 아니다!

더 저렴하고(더 적은 리소스 사용) 더 빠르기 때문에 Objectify를 사용하세요.참고: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify는 Google App Engine Datastore 용으로 특별히 설계된 Java Data Access API입니다.그것은 "중간 지대"를 차지합니다.JDO 또는 JPA보다 사용하기 쉽고 투명하지만 저수준 API보다 훨씬 편리합니다.Objectify는 다음을 위해 설계되었습니다. 초보자는 즉시 생산적이면서도 모든 힘을 노출합니다. GAE 데이터 저장소.

Objectify를 사용하면 자신이 입력한 개체를 유지, 검색, 삭제 및 쿼리할 수 있습니다.

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top