Allereerst is het type zoekopdracht dat u uitvoert buitengewoon inefficiënt. Voor nu (Spark 1.5.0*) om join op deze manier uit te voeren, moeten beide tabellen worden geschud / gehash-partitioneerd elke keer dat de query wordt uitgevoerd. Het zou geen probleem moeten zijn in het geval van users tabel waar user_id = 123 predikaat is hoogstwaarschijnlijk ingedrukt, maar vereist nog steeds volledige shuffle op user_address .
Bovendien, als tabellen alleen worden geregistreerd en niet in de cache worden opgeslagen, zal elke uitvoering van deze query een heel user_address ophalen tabel van MySQL naar Spark.
Het is niet precies duidelijk waarom u Spark wilt gebruiken voor toepassingen, maar het instellen van een enkele machine, kleine gegevens en type query's suggereren dat Spark hier niet goed past.
Over het algemeen zal Spark SQL niet goed presteren als toepassingslogica toegang tot één record vereist. Het is ontworpen voor analytische zoekopdrachten en niet als vervanging van een OLTP-database.
Als een enkele tabel / dataframe veel kleiner is, kun je proberen te broadcasten.
import org.apache.spark.sql.DataFrame
import org.apache.spark.sql.functions.broadcast
val user: DataFrame = ???
val user_address: DataFrame = ???
val userFiltered = user.where(???)
user_addresses.join(
broadcast(userFiltered), $"address_id" === $"user_address_id")
* Dit zou in Spark 1.6.0 moeten veranderen met SPARK-11410 die permanente tabelpartitionering zou moeten inschakelen.