How is JPA and Memcached different?

I am trying to figure out the difference between Memcached and JPA, this is what I infer from the information I have

1. Memcached: Cache data and objects in memory, like an on the fly database to quickly access the data. This layer is just above the actual db (say my sql). It has its own columns and rows, where can you keep some temporary data (hot data). A small database, in RAM.

2. JPA: manage relational data (data which should go in databas开发者_如何转开发e), developed to make life easy, i.e. we don't have to go into hibernate and stuff. (I am a lil confused about JPA in layman's term :| )

So, from where I see":

1. Both give feature to save relational data in the memory. - WRONG
2. Used to make data access quick.- WRONG
3. Both are same (which I am sure are not)- WRONG

Now, some one told me that they used Memcahed and JPA in their system (they deal with huge datasets) So, how does that make sense?

ADDED Question: After reading the answers, if I am making a system which deals with huge datasets, I will go with memcached, but I still don't understand, why should I go for JPA if: 1. I need to deal with huge data sets, 2. Make system scalable.

JPA is an ORM (object-relational mapper) to map an object model to a relational database model.

Memcache is an in-memory cache that is little more than a key-value pair map.

They're really for different applications. JPA is an alternative to using SQL. It has caching elements but the primary data source is a database so is for presistent data. Memcache data lives in memory and isn't persistent so is for more transient data.

Let me add another possibly controversial point: JPA doesn't scale.

JPA (and all ORMs) are a convenience that can speed up development by projecting an object model onto a relational database but it's not as fast as native SQL. Often you'll end up figuring ou tthe right combination of settings that generates performant SQL. As Joel says, all abstractions are leaky. JPA is no exception.

Let me stress that you can go reasonably far with JPA but at some point you will need to go to SQL.

Memcache solves a different problem and shouldn't really be compared with JPA. Memcache scales extremely well however as long as you can partition your data, in which case you can have as many servers as you need and the bottleneck becomes network bandwidth, memory and CPU.

1) Both give feature to save relational data in the memory.

Arguably incorrect. Neither are about saving relational data. Memcache is not about saving data at all, AFAIK! JPA is about saving data that may-or-may-not be modeled by the developer as relational in a persistent store that may-or-may-not be a relational DBMS.

If you mean "caching relational data in the memory", the statement is still arguably incorrect. Neither Memcache or JPA have a relational model for data, and neither require the backend to be relational. And in the case of Memcache the data may not even be persistent.

2) Used to make data access quick.

Partly incorrect. Memcache is about making data access quick. But JPA is primarily about making data access ... and update ... more convenient for the Java application developer. JPA may be quicker than a poorly designed SQL/JDBC application, but that would be a consequence of the poor design, not of JPA being intrinsically faster.

3) Both are same (which I am sure are not)

Incorrect. Obviously.

EDIT - I don't think we can answer why you "should" use JPA. That is up to you to decide.

JPA does certain things more easily than plain SQL ... especially if you are dealing with data with complex schemas. But it is (probably) not effective as a cache of a huge dataset.

On the other hand, Memcached does caching of huge datasets well. But it works best if the dataset doesn't change and if they has a relatively simple schema. (If it has a complex schema, you have to do a bit of work to map that to memcache's name/value pair model, and you may loose efficiency in the process.)

At the end of the day, YOU need to understand the Memcache and JPA technologies and the functional and performance requirements of your application, and decide whic design is likely to give you the best results. That won't be easy ... and there are no magic bullet answers.