Sesuatu boleh menggandakan kecekapan pembangunan pengaturcara Java

Dilema pengkomputeran dalam aplikasi
Pembangunan dan Rangka Kerja, yang manakah harus diberi keutamaan yang lebih tinggi?
Java adalah bahasa pengaturcaraan yang paling biasa digunakan dalam pembangunan aplikasi. Tetapi menulis kod untuk memproses data dalam Java tidaklah mudah. Sebagai contoh, di bawah ialah kod Java untuk melaksanakan pengumpulan & pengagregatan pada dua medan:

Map<Integer, Map<String, Double>> summary = new HashMap<>();
    for (Order order : orders) {
        int year = order.orderDate.getYear();
        String sellerId = order.sellerId;
        double amount = order.amount;
        Map<String, Double> salesMap = summary.get(year);
        if (salesMap == null) {
            salesMap = new HashMap<>();
            summary.put(year, salesMap);
        }
        Double totalAmount = salesMap.get(sellerId);
        if (totalAmount == null) {
            totalAmount = 0.0;
        }
        salesMap.put(sellerId, totalAmount + amount);
    }
    for (Map.Entry<Integer, Map<String, Double>> entry : summary.entrySet()) {
        int year = entry.getKey();
        Map<String, Double> salesMap = entry.getValue();
        System.out.println("Year: " + year);
        for (Map.Entry<String, Double> salesEntry : salesMap.entrySet()) {
            String sellerId = salesEntry.getKey();
            double totalAmount = salesEntry.getValue();
            System.out.println("  Seller ID: " + sellerId + ", Total Amount: " + totalAmount);
        }
    }

Sebaliknya, rakan sejawat SQL adalah lebih mudah. Satu klausa GROUP BY sudah cukup untuk menutup pengiraan.

PILIH tahun(tarikh pesanan),id penjual,jumlah(jumlah) DARI pesanan KUMPULAN MENGIKUT tahun(Tarikh pesanan),id penjual

Memang, aplikasi awal berfungsi dengan kerjasama Java dan SQL. Proses perniagaan telah dilaksanakan di Java pada bahagian aplikasi, dan data telah diproses dalam SQL dalam pangkalan data bahagian belakang. Rangka kerja sukar untuk dikembangkan dan dipindahkan kerana had pangkalan data. Ini sangat tidak mesra dengan aplikasi kontemporari. Selain itu, pada banyak keadaan SQL tidak tersedia apabila tiada pangkalan data atau pengiraan silang pangkalan data terlibat.

Memandangkan perkara ini, kemudiannya banyak aplikasi mula mengguna pakai rangka kerja berasaskan Java sepenuhnya, di mana pangkalan data hanya melakukan operasi baca dan tulis yang mudah dan proses perniagaan serta pemprosesan data dilaksanakan di Java di bahagian aplikasi, terutamanya apabila perkhidmatan mikro muncul. Dengan cara ini, aplikasi dipisahkan daripada pangkalan data dan mendapat kebolehskalaan dan kebolehhijrahan yang baik, yang membantu memperoleh kelebihan rangka kerja sambil menghadapi kerumitan pembangunan Java yang dinyatakan sebelum ini.

Nampaknya kita hanya boleh fokus pada satu aspek – pembangunan atau rangka kerja. Untuk menikmati kelebihan rangka kerja Java, seseorang mesti menanggung kesukaran pembangunan; dan untuk menggunakan SQL, seseorang perlu bertolak ansur dengan kekurangan rangka kerja. Ini mewujudkan dilema.

Kemudian apa yang boleh kita lakukan?
Bagaimana pula dengan meningkatkan keupayaan pemprosesan data Java? Ini bukan sahaja mengelakkan masalah SQL, tetapi juga mengatasi kekurangan Java.

Sebenarnya, Java Stream/Kotlin/Scala semuanya cuba melakukannya.

Strim

Strim yang diperkenalkan dalam Java 8 menambahkan banyak kaedah pemprosesan data. Berikut ialah kod Strim untuk melaksanakan pengiraan di atas:

Map<Integer, Map<String, Double>> summary = orders.stream()
            .collect(Collectors.groupingBy(
                    order -> order.orderDate.getYear(),
                    Collectors.groupingBy(
                            order -> order.sellerId,
                            Collectors.summingDouble(order -> order.amount)
                    )
            ));

    summary.forEach((year, salesMap) -> {
        System.out.println("Year: " + year);
        salesMap.forEach((sellerId, totalAmount) -> {
            System.out.println("  Seller ID: " + sellerId + ", Total Amount: " + totalAmount);
        });
    });

Strim memang memudahkan kod dalam beberapa tahap. Tetapi secara keseluruhan, ia masih menyusahkan dan jauh lebih ringkas daripada SQL.

Kotlin

Kotlin, yang mendakwa lebih berkuasa, bertambah baik lagi:

val summary = orders
        .groupBy { it.orderDate.year }
        .mapValues { yearGroup ->
            yearGroup.value
                .groupBy { it.sellerId }
                .mapValues { sellerGroup ->
                    sellerGroup.value.sumOf { it.amount }
                }
        }
    summary.forEach { (year, salesMap) ->
        println("Year: $year")
        salesMap.forEach { (sellerId, totalAmount) ->
            println("  Seller ID: $sellerId, Total Amount: $totalAmount")
        }
    }

Kod Kotlin adalah lebih mudah, tetapi peningkatan adalah terhad. Masih terdapat jurang yang besar berbanding dengan SQL.

Scala

Kemudian terdapat Scala:

val summary = orders
        .groupBy(order => order.orderDate.getYear)
        .mapValues(yearGroup =>
            yearGroup
                .groupBy(_.sellerId)
                .mapValues(sellerGroup => sellerGroup.map(_.amount).sum)
    )
    summary.foreach { case (year, salesMap) =>
        println(s"Year: $year")
        salesMap.foreach { case (sellerId, totalAmount) =>
            println(s"  Seller ID: $sellerId, Total Amount: $totalAmount")
        }
    }

Scala sedikit lebih ringkas daripada Kotlin, tetapi masih tidak boleh dibandingkan dengan SQL. Selain itu, Scala terlalu berat dan menyusahkan untuk digunakan.

Malah, teknologi ini berada di jalan yang betul, walaupun tidak sempurna.

Bahasa yang disusun tidak boleh ditukar panas
Selain itu, Java, sebagai bahasa yang disusun, tidak mempunyai sokongan untuk pertukaran panas. Mengubah suai kod memerlukan penyusunan semula dan penempatan semula, selalunya memerlukan perkhidmatan dimulakan semula. Ini menghasilkan pengalaman yang tidak optimum apabila menghadapi perubahan keperluan yang kerap. Sebaliknya, SQL tidak mempunyai masalah dalam hal ini.

Pembangunan Java adalah rumit, dan terdapat juga kekurangan dalam rangka kerja. SQL mempunyai kesukaran untuk memenuhi keperluan untuk rangka kerja. Dilema sukar diselesaikan. Adakah terdapat cara lain?

Penyelesaian muktamad – esProc SPL
esProc SPL ialah bahasa pemprosesan data yang dibangunkan semata-mata di Jawa. Ia mempunyai pembangunan yang mudah dan rangka kerja yang fleksibel.

Sintaks ringkas
Mari semak pelaksanaan Java untuk operasi pengelompokan dan pengagregatan di atas:

Bandingkan dengan kod Java, kod SPL adalah lebih ringkas:

Orders.groups(year(orderdate),sellerid;sum(amount))

Ia semudah pelaksanaan SQL:

SELECT year(orderdate),sellerid,sum(amount) FROM orders GROUP BY year(orderDate),sellerid

Malah, kod SPL selalunya lebih mudah daripada rakan SQLnya. Dengan sokongan untuk pengiraan berasaskan pesanan dan prosedur, SPL lebih baik dalam melaksanakan pengiraan yang kompleks. Pertimbangkan contoh ini: hitung bilangan maksimum hari kenaikan berturut-turut bagi sesuatu saham. SQL memerlukan pernyataan bersarang tiga lapisan berikut, yang sukar difahami, apatah lagi menulis.

select max(continuousDays)-1
  from (select count(*) continuousDays
    from (select sum(changeSign) over(order by tradeDate) unRiseDays
       from (select tradeDate,
          case when closePrice>lag(closePrice) over(order by tradeDate)
          then 0 else 1 end changeSign
          from stock) )
group by unRiseDays)

SPL melaksanakan pengiraan dengan hanya satu baris kod. Ini lebih mudah daripada kod SQL, apatah lagi kod Java.

stock.sort(tradeDate).group@i(price<price[-1]).max(~.len())

Comprehensive, independent computing capability
SPL has table sequence – the specialized structured data object, and offers a rich computing class library based on table sequences to handle a variety of computations, including the commonly seen filtering, grouping, sorting, distinct and join, as shown below:

Orders.sort(Amount) // Sorting
Orders.select(Amount*Quantity>3000 && like(Client,"*S*")) // Filtering
Orders.groups(Client; sum(Amount)) // Grouping
Orders.id(Client) // Distinct
join(Orders:o,SellerId ; Employees:e,EId) // Join
……

More importantly, the SPL computing capability is independent of databases; it can function even without a database, which is unlike the ORM technology that requires translation into SQL for execution.

Efficient and easy to use IDE
Besides concise syntax, SPL also has a comprehensive development environment offering debugging functionalities, such as “Step over” and “Set breakpoint”, and very debugging-friendly WYSIWYG result viewing panel that lets users check result for each step in real time.

Support for large-scale data computing
SPL supports processing large-scale data that can or cannot fit into the memory.

In-memory computation:

External memory computation:

We can see that the SPL code of implementing an external memory computation and that of implementing an in-memory computation is basically the same, without extra computational load.

It is easy to implement parallelism in SPL. We just need to add @m option to the serial computing code. This is far simpler than the corresponding Java method.

Seamless integration into Java applications
SPL is developed in Java, so it can work by embedding its JARs in the Java application. And the application executes or invokes the SPL script via the standard JDBC. This makes SPL very lightweight, and it can even run on Android.

Call SPL code through JDBC:

Class.forName("com.esproc.jdbc.InternalDriver");
    con= DriverManager.getConnection("jdbc:esproc:local://");
    st =con.prepareCall("call SplScript(?)");
    st.setObject(1, "A");
    st.execute();
    ResultSet rs = st.getResultSet();
    ResultSetMetaData rsmd = rs.getMetaData();

As it is lightweight and integration-friendly, SPL can be seamlessly integrated into mainstream Java frameworks, especially suitable for serving as a computing engine within microservice architectures.

Highly open framework
SPL’s great openness enables it to directly connect to various types of data sources and perform real-time mixed computations, making it easy to handle computing scenarios where databases are unavailable or multiple/diverse databases are involved.

Regardless of the data source, SPL can read data from it and perform the mixed computation as long as it is accessible. Database and database, RESTful and file, JSON and database, anything is fine.

Databases:

RESTful and file:

JSON and database:

Interpreted execution and hot-swapping
SPL is an interpreted language that inherently supports hot swapping while power remains switched on. Modified code takes effect in real-time without requiring service restarts. This makes SPL well adapt to dynamic data processing requirements.

This hot—swapping capability enables independent computing modules with separate management, maintenance and operation, creating more flexible and convenient uses.

SPL can significantly increase Java programmers’ development efficiency while achieving framework advantages. It combines merits of both Java and SQL, and further simplifies code and elevates performance.

SPL open source address

Atas ialah kandungan terperinci Sesuatu boleh menggandakan kecekapan pembangunan pengaturcara Java. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!