JPA: Büyük sonuç kümeleri üzerinde yineleme yapmak için uygun model nedir?

Diyelim ki milyonlarca sıralı bir masam var. JPA kullanarak, bir sorguyu bu tabloya karşı yinelemenin doğru yolu nedir, öyle ki milyonlarca nesnenin bulunduğu bir bellek içi Listem yok ?

Örneğin, masa büyükse aşağıdakilerin patlayacağından şüpheleniyorum:

List<Model> models = entityManager().createQuery("from Model m", Model.class).getResultList();

for (Model model : models)
{
     System.out.println(model.getId());
}

Sayfalandırma (döngü ve manuel olarak güncelleme setFirstResult()/ setMaxResult()) gerçekten en iyi çözüm mü?

Düzenleme : Hedeflediğim birincil kullanım örneği bir tür toplu iştir. Koşması uzun sürerse sorun değil. Hiçbir web istemcisi yoktur; Her satır için bir seferde bir (veya küçük bir N) "bir şeyler yapmam" gerekiyor. Hepsinin aynı anda hafızada olmasını engellemeye çalışıyorum.

Hibernate ile Java Persistence, Sayfa 537 kullanarak bir çözüm sunar ScrollableResults, ancak bu sadece Hibernate içindir.

Bu yüzden setFirstResult/ setMaxResultsve manuel yinelemenin kullanılması gerçekten gerekli görünüyor. İşte JPA kullanan çözümüm:

private List<Model> getAllModelsIterable(int offset, int max)
{
    return entityManager.createQuery("from Model m", Model.class).setFirstResult(offset).setMaxResults(max).getResultList();
}

sonra, şu şekilde kullanın:

private void iterateAll()
{
    int offset = 0;

    List<Model> models;
    while ((models = Model.getAllModelsIterable(offset, 100)).size() > 0)
    {
        entityManager.getTransaction().begin();
        for (Model model : models)
        {
            log.info("do something with model: " + model.getId());
        }

        entityManager.flush();
        entityManager.clear();
        em.getTransaction().commit();
        offset += models.size();
    }
}

Burada sunulan cevapları denedim, ancak JBoss 5.1 + MySQL Connector / J 5.1.15 + Hibernate 3.3.2 bunlarla çalışmadı. JBoss 4.x'ten JBoss 5.1'e yeni geçtik, bu yüzden şimdilik buna bağlı kaldık ve bu nedenle kullanabileceğimiz en son Hazırda Bekletme 3.3.2.

Birkaç ekstra parametre eklemek işi yaptı ve bunun gibi kod OOME'lar olmadan çalışır:

        StatelessSession session = ((Session) entityManager.getDelegate()).getSessionFactory().openStatelessSession();

        Query query = session
                .createQuery("SELECT a FROM Address a WHERE .... ORDER BY a.id");
        query.setFetchSize(Integer.valueOf(1000));
        query.setReadOnly(true);
        query.setLockMode("a", LockMode.NONE);
        ScrollableResults results = query.scroll(ScrollMode.FORWARD_ONLY);
        while (results.next()) {
            Address addr = (Address) results.get(0);
            // Do stuff
        }
        results.close();
        session.close();

Önemli satırlar, createQuery ve scroll arasındaki sorgu parametreleridir. Bunlar olmadan "kaydırma" çağrısı her şeyi belleğe yüklemeye çalışır ve ya hiç bitmez ya da OutOfMemoryError'a çalışır.

Bunu doğrudan JPA'da gerçekten yapamazsınız, ancak Hibernate'in durum bilgisi olmayan oturumlar ve kaydırılabilir sonuç kümeleri için desteği vardır.

Onun yardımıyla rutin olarak milyarlarca satırı işliyoruz .

Belgelere bir bağlantı: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.html#batch-statelesssession

Dürüst olmak gerekirse, JPA'dan ayrılmanızı ve JDBC'ye bağlı kalmanızı öneririm (ama kesinlikle JdbcTemplatedestek sınıfı veya benzeri bir şey kullanın). JPA (ve diğer ORM sağlayıcıları / spesifikasyonları), yüklenen her şeyin birinci seviye önbellekte kalması gerektiğini varsaydığından (dolayısıyla clear()JPA'da ihtiyaç duyulmaktadır ) tek bir işlemdeki birçok nesne üzerinde çalışmak üzere tasarlanmamıştır .

Ayrıca, daha düşük seviyeli bir çözüm öneriyorum, çünkü ORM'nin ek yükü (yansıma bir buzdağının sadece bir ucu) o kadar önemli olabilir ki, düz üzerinden yineleme ResultSet, bahsedildiği gibi hafif bir destek kullanmak bile JdbcTemplateçok daha hızlı olacaktır.

JPA, büyük miktarda varlık üzerinde işlem gerçekleştirmek için tasarlanmamıştır. Kaçınmak için flush()/ ile oynayabilirsiniz , ancak bunu bir kez daha düşünün. Büyük kaynak tüketiminin bedelini ödeyerek çok az kazanırsınız.clear()OutOfMemoryError

EclipseLink I 'kullanıyorsanız, yinelenebilir sonuç almak için bu yöntemi kullanıyorum

private static <T> Iterable<T> getResult(TypedQuery<T> query)
{
  //eclipseLink
  if(query instanceof JpaQuery) {
    JpaQuery<T> jQuery = (JpaQuery<T>) query;
    jQuery.setHint(QueryHints.RESULT_SET_TYPE, ResultSetType.ForwardOnly)
       .setHint(QueryHints.SCROLLABLE_CURSOR, true);

    final Cursor cursor = jQuery.getResultCursor();
    return new Iterable<T>()
    {     
      @SuppressWarnings("unchecked")
      @Override
      public Iterator<T> iterator()
      {
        return cursor;
      }
    }; 
   }
  return query.getResultList();  
}  

kapat Yöntemi

static void closeCursor(Iterable<?> list)
{
  if (list.iterator() instanceof Cursor)
    {
      ((Cursor) list.iterator()).close();
    }
}

Yapmanız gereken operasyonun türüne bağlıdır. Neden bir milyondan fazla satırda ilerliyorsunuz? Toplu modda bir şey mi güncelliyorsunuz? Tüm kayıtları bir müşteriye gösterecek misiniz? Alınan varlıklar hakkında bazı istatistikler mi hesaplıyorsunuz?

İstemciye bir milyon kayıt gösterecekseniz, lütfen kullanıcı arayüzünüzü yeniden gözden geçirin. Bu durumda, uygun çözüm sonuçlarınızı Sayfalara ayırma ve kullanıyor setFirstResult()ve setMaxResult().

Büyük miktarda kayıt için güncelleme başlattıysanız, güncellemeyi basit ve kullanışlı tutmanız daha iyi olur Query.executeUpdate(). İsteğe bağlı olarak, bir Message-Driven Bean oa Work Manager kullanarak güncellemeyi asenkron modda gerçekleştirebilirsiniz.

Alınan varlıklar üzerinde bazı istatistikler hesaplıyorsanız, JPA spesifikasyonu tarafından tanımlanan gruplama işlevlerinden yararlanabilirsiniz.

Diğer durumlar için lütfen daha spesifik olun :)

Bunu yapmak için "uygun" bir şey yoktur, bu JPA veya JDO veya başka herhangi bir ORM'nin amaçladığı şey değildir, düz JDBC en iyi alternatifiniz olacaktır, çünkü onu az sayıda satırı geri getirecek şekilde yapılandırabilirsiniz. bir zaman ve kullanıldıkça temizleyin, bu nedenle sunucu tarafı imleçleri mevcuttur.

ORM araçları toplu işleme için tasarlanmamıştır, nesneleri değiştirmenize ve verilerin depolandığı RDBMS'yi olabildiğince şeffaf hale getirmeye çalışmanıza izin verecek şekilde tasarlanmıştır, çoğu şeffaf kısımda en azından bir dereceye kadar başarısız olur. Bu ölçekte, yüzbinlerce satırı (Nesneler), herhangi bir ORM ile çok daha azını işlemenin ve nesne somutlaştırma ek yükü nedeniyle makul bir süre içinde basit ve basit bir şekilde çalıştırmanın bir yolu yoktur.

Uygun aracı kullanın. Düz JDBC ve Depolanan Prosedürler kesinlikle 2011'de, özellikle de bu ORM çerçevelerine kıyasla daha iyi yaptıkları şeylerde bir yere sahiptir.

List<Integer>Nasıl yaparsanız yapın , bir milyondan fazlasını, hatta basit bir şeye çekmek çok verimli olmayacak. İstediğiniz şeyi yapmanın doğru yolu, basit SELECT id FROM table, SERVER SIDE(satıcıya bağlı) olarak ayarlanmış ve imleç FORWARD_ONLY READ-ONLYbunun üzerinde ve üzerinde yineleme yapmaktır .

Her biri ile bir web sunucusunu arayarak işlemek için gerçekten milyonlarca kimliği çekiyorsanız, bunun herhangi bir makul sürede çalışması için bazı eşzamanlı işlemler de yapmanız gerekecektir. Bir JDBC imleci ile çekip bunlardan birkaçını bir ConcurrentLinkedQueue'ya bir seferde yerleştirmek ve küçük bir iş parçacığı havuzuna (# CPU / Cores + 1) sahip olmak, görevinizi herhangi bir makinede tamamlamanın tek yoludur " zaten belleğinizin tükendiğini göz önünde bulundurarak normal "RAM miktarı.

Bu yanıtı da görün .

Başka bir "numara" kullanabilirsiniz. İlgilendiğiniz varlıkların yalnızca tanımlayıcı koleksiyonunu yükleyin. Diyelim ki tanımlayıcı uzun = 8 bayt türünde, sonra 10 ^ 6 bu tür tanımlayıcıların bir listesi yaklaşık 8 Mb. Toplu işlemse (her seferinde bir örnek), o zaman katlanılabilir. Sonra tekrarlayın ve işi yapın.

Başka bir açıklama - yine de bunu parçalar halinde yapmalısınız - özellikle kayıtları değiştirirseniz, aksi takdirde veritabanındaki geri alma segmenti büyür.

FirstResult / maxRows stratejisini belirlemeye gelince - uzak sonuçlar için ÇOK ÇOK yavaş .

Ayrıca, veritabanının muhtemelen okumaya bağlı izolasyonda çalıştığını da göz önünde bulundurun , bu nedenle fantomun yük tanımlayıcılarını okumasını ve ardından varlıkları birer birer (veya 10'a 10 veya her neyse) yüklemesini önlemek için.

Buradaki cevaplarda saklı yordamların kullanımının daha fazla ön plana çıkmadığını görünce şaşırdım. Geçmişte böyle bir şey yapmak zorunda kaldığımda, verileri küçük parçalar halinde işleyen, sonra biraz uyuyan ve sonra devam eden bir saklı yordam oluşturdum. Uykunun nedeni, muhtemelen bir web sitesine bağlanma gibi daha gerçek zamanlı sorgulama türleri için de kullanılan veritabanını bunaltmamaktır. Veritabanını kullanan başka kimse yoksa, uykuyu dışarıda bırakabilirsiniz. Her kaydı bir kez ve yalnızca bir kez işlediğinizden emin olmanız gerekiyorsa, yeniden başlatmalarda esnek olmak için hangi kayıtları işlediğinizi depolamak için ek bir tablo (veya alan) oluşturmanız gerekecektir.

Buradaki performans tasarrufları, büyük olasılıkla JPA / Hibernate / AppServer alanında yapabileceğiniz her şeyden daha hızlıdır ve veritabanı sunucunuz büyük sonuç kümelerini verimli bir şekilde işlemek için büyük olasılıkla kendi sunucu tarafı imleç tipi mekanizmaya sahip olacaktır. Performans tasarrufları, verileri veritabanı sunucusundan, verileri işlediğiniz ve ardından geri gönderdiğiniz uygulama sunucusuna göndermek zorunda kalmamaktan gelir.

Depolanan prosedürleri kullanmanın, bunu sizin için tamamen dışlayabilecek bazı önemli dezavantajları vardır, ancak kişisel alet çantanızda bu beceriye sahipseniz ve bu tür durumlarda onu kullanabiliyorsanız, bu tür şeyleri oldukça hızlı bir şekilde ortadan kaldırabilirsiniz. .

@Tomasz Nurkiewicz'in cevabını genişletmek için. Size DataSourcebir bağlantı sağlayabilecek olana erişiminiz var

@Resource(name = "myDataSource",
    lookup = "java:comp/DefaultDataSource")
private DataSource myDataSource;

Kodunuzda var

try (Connection connection = myDataSource.getConnection()) {
    // raw jdbc operations
}

Bu, içe aktarma / dışa aktarma gibi bazı belirli büyük toplu işlemler için JPA'yı atlamanıza izin verir, ancak yine de ihtiyacınız varsa diğer JPA işlemleri için varlık yöneticisine erişebilirsiniz.

PaginationSonucu almak için Konsepti kullanın

Bunu kendim merak ettim. Önemli gibi görünüyor:

• veri kümeniz ne kadar büyük (satırlar)
• hangi JPA uygulamasını kullanıyorsunuz
• her satır için ne tür işlemler yapıyorsunuz.

Her iki yaklaşımı da değiştirmeyi kolaylaştırmak için bir Yineleyici yazdım (findAll vs findEntries).

İkisini de denemenizi tavsiye ederim.

Long count = entityManager().createQuery("select count(o) from Model o", Long.class).getSingleResult();
ChunkIterator<Model> it1 = new ChunkIterator<Model>(count, 2) {

    @Override
    public Iterator<Model> getChunk(long index, long chunkSize) {
        //Do your setFirst and setMax here and return an iterator.
    }

};

Iterator<Model> it2 = List<Model> models = entityManager().createQuery("from Model m", Model.class).getResultList().iterator();


public static abstract class ChunkIterator<T> 
    extends AbstractIterator<T> implements Iterable<T>{
    private Iterator<T> chunk;
    private Long count;
    private long index = 0;
    private long chunkSize = 100;

    public ChunkIterator(Long count, long chunkSize) {
        super();
        this.count = count;
        this.chunkSize = chunkSize;
    }

    public abstract Iterator<T> getChunk(long index, long chunkSize);

    @Override
    public Iterator<T> iterator() {
        return this;
    }

    @Override
    protected T computeNext() {
        if (count == 0) return endOfData();
        if (chunk != null && chunk.hasNext() == false && index >= count) 
            return endOfData();
        if (chunk == null || chunk.hasNext() == false) {
            chunk = getChunk(index, chunkSize);
            index += chunkSize;
        }
        if (chunk == null || chunk.hasNext() == false) 
            return endOfData();
        return chunk.next();
    }

}

Parça yineleyicimi kullanmadım (bu yüzden test edilmemiş olabilir). Bu arada, kullanmak istiyorsanız google koleksiyonlarına ihtiyacınız olacak.

Hazırda bekletme modunda, istediğinizi elde etmenin 4 farklı yolu vardır. Her birinin tasarım ödünleri, sınırlamaları ve sonuçları vardır. Her birini keşfetmenizi ve sizin durumunuz için hangisinin doğru olduğuna karar vermenizi öneririm.

1. Scroll () ile durum bilgisiz oturum kullan
2. Her yinelemeden sonra session.clear () kullanın. Diğer varlıkların eklenmesi gerektiğinde, bunları ayrı bir oturumda yükleyin. etkili bir şekilde ilk oturum durum bilgisi olmayan oturumu taklit eder, ancak nesneler ayrılana kadar durum bilgisi olan bir oturumun tüm özelliklerini korur.
3. İterate () veya list () kullanın, ancak ilk sorguda yalnızca kimlikleri alın, ardından her yinelemede ayrı bir oturumda, yinelemenin sonunda session.load yapın ve oturumu kapatın.
4. EntityManager.detach () aka Session.evict () ile Query.iterate () kullanın;

Burada basit, düz bir JPA örneği (Kotlin'de), imleç kullanmadan bir seferde 100 öğelik parçaları okuyarak (her imleç veri tabanındaki kaynakları tüketir) rastgele büyük bir sonuç kümesi üzerinde nasıl sayfalara ayırabileceğinizi gösterir. Keyset sayfalandırmasını kullanır.

Görmek https://use-the-index-luke.com/no-offset anahtar kümesi şekilde sayfa numarası konsepti için ve https://www.citusdata.com/blog/2016/03/30/five-ways-to- sayfalandırmanın farklı yollarının dezavantajları ile karşılaştırılması için.

/*
create table my_table(
  id int primary key, -- index will be created
  my_column varchar
)
*/

fun keysetPaginationExample() {
    var lastId = Integer.MIN_VALUE
    do {

        val someItems =
        myRepository.findTop100ByMyTableIdAfterOrderByMyTableId(lastId)

        if (someItems.isEmpty()) break

        lastId = someItems.last().myTableId

        for (item in someItems) {
          process(item)
        }

    } while (true)
}

JPA ve NativeQuery öğelerinin ofsetleri kullanarak boyutlarını her defasında getiren bir Örnek

public List<X> getXByFetching(int fetchSize) {
        int totalX = getTotalRows(Entity);
        List<X> result = new ArrayList<>();
        for (int offset = 0; offset < totalX; offset = offset + fetchSize) {
            EntityManager entityManager = getEntityManager();
            String sql = getSqlSelect(Entity) + " OFFSET " + offset + " ROWS";
            Query query = entityManager.createNativeQuery(sql, X.class);
            query.setMaxResults(fetchSize);
            result.addAll(query.getResultList());
            entityManager.flush();
            entityManager.clear();
        return result;
    }