把 Java 8 流解析成 SQL

有個問題立馬就出現了，這個問題就是將來自數據庫中的所有數據行轉移到數據庫中，其延時太長了。后果就是沒能有多少盈余留下來對內存中的數據進行處理。即使你可以使用 Java 8 中新的工具做一些真正令人驚訝的東西出來，但這種好處卻因為性能的消耗過甚而并不適用于數據庫應用程序。

當我開始想 Speedment 開源 項目做貢獻是，很快就意識到用 Java 8 的方式利用數據庫的潛力，不過我們確實需要一個聰明的方式來處理性能問題。在本文中我會向你展示如何使用自定義的 Stream API 代理，在后臺操作一個流，對于 SQL 查詢的結果進行優化，以解決這個問題。

假設在遠程數據庫服務器上你有一張用戶表，你想打印年齡大于 70 歲的用戶名字。 在 Java 8 中使用 Speedment 可能會是這樣:

final UserManager users = speedment.managerOf(User.class);
users.stream()
    .filter(User.AGE.greaterThan(70))
    .map(User.NAME.get())
    .forEach(System.out::println);

看你這些代碼你不僅要先打一個冷顫，我的程序會從數據庫下載整個數據表，然后在客戶端做過濾嗎？如果我有 100,000,000 個用戶會發生什么?網絡延遲足以殺死應用程序！哇噢，事實并不是這樣，就像我前面說過的。Speedment 在結束前會分析流。

讓我們來看看幕后發生了什么。UserManager 中的方法 .stream() 會返回一個流接口的自定義實現，包含流的所有無數據一直到流關閉，元數據可以被終止的事件使用以優化流。當方法 .forEach 被調用時，管道看起來會是這樣：

終止活動（在這個例子中 ForEach 將會向后遍歷管道，看看它是否可以優化，首先它遇到從 User 到 String 的映射。Speedment 識別出它是一個 Getter 函數，User.NAME 字段是使用它來生成。Getter 可以解析到 SQL，所以終止活動切換到讀操作，因為 NAME 列和映射被移除。

接著是 .filter。filter 也被識別出是一個自定義操作，在這個例子中是一個謂詞。因為它是一個自定義實現，它可以包含 SQL 查詢中需要的所有元數據，所以可以安全地從流中移除并附加在寫操作）

此時終止活動繼續查找管道，它會發現流的源頭，一旦到達流的源頭，讀操作會解析到 SQL 并提交到 SQL 管理系統。最后 Stream<String> 會被最被的 .forEach 終止掉。上面的內容會生成確切的 SQL：

SELECT `name` FROM `User` WHERE `User`.`age` > 70;

Java 代碼不需要改變和特殊的操作！

這是一個簡單的例子，演示了流在執行前 Speedment 如何使用一個自定義實現使它簡化。歡迎你查看  the source code 尋找更好的辦法來優化這個技術。它真的幫助我們改善了系統性能，并在可以在 Java-8 的任何分布式環境下工作。