การโทร jdbc แบบอะซิงโครนัสเป็นไปได้หรือไม่?

ฉันสงสัยว่ามีวิธีการโทรแบบอะซิงโครนัสกับฐานข้อมูลหรือไม่?

ตัวอย่างเช่นลองนึกภาพว่าฉันมีคำขอใหญ่ ๆ ที่ต้องใช้เวลานานในการประมวลผลฉันต้องการส่งคำขอและรับการแจ้งเตือนเมื่อคำขอนั้นส่งคืนค่า (โดยส่งผู้ฟัง / ติดต่อกลับหรือบางอย่าง) ฉันไม่ต้องการบล็อครอให้ฐานข้อมูลตอบ

ฉันไม่คิดว่าการใช้กลุ่มของเธรดเป็นวิธีแก้ปัญหาเพราะมันไม่ได้ปรับขนาดในกรณีที่มีการร้องขอที่เกิดขึ้นพร้อมกันจำนวนมากสิ่งนี้จะทำให้เกิดเธรดจำนวนมาก

เรากำลังประสบปัญหานี้กับเซิร์ฟเวอร์เครือข่ายและเราพบวิธีแก้ปัญหาโดยใช้การเรียกระบบเลือก / แบบสำรวจ / epoll เพื่อหลีกเลี่ยงการมีหนึ่งเธรดต่อการเชื่อมต่อ ฉันแค่สงสัยว่าจะมีคุณสมบัติที่คล้ายกับคำขอฐานข้อมูลได้อย่างไร

หมายเหตุ: ฉันทราบว่าการใช้ FixedThreadPool อาจเป็นการแก้ไขที่ดี แต่ฉันประหลาดใจที่ไม่มีใครพัฒนาระบบแบบอะซิงโครนัสจริงๆ (โดยไม่ต้องใช้เธรดพิเศษ)

** ปรับปรุง **
เพราะการขาดของการแก้ปัญหาในทางปฏิบัติจริงที่ฉันตัดสินใจที่จะสร้างห้องสมุด (ส่วนหนึ่งของ finagle) ตัวเอง: finagle-MySQL โดยทั่วไปจะทำการถอดรหัส / ถอดรหัสการร้องขอ / ตอบกลับ mysql และใช้ Finagle / Netty ภายใต้ประทุน มันปรับขนาดได้อย่างดีเยี่ยมแม้จะมีการเชื่อมต่อจำนวนมาก

ฉันไม่เข้าใจว่าวิธีการใด ๆ ที่เสนอให้ตัดการเรียก JDBC ใน Actors, executors หรือสิ่งอื่นใดสามารถช่วยได้ที่นี่ - ใครบางคนสามารถชี้แจงได้

แน่นอนปัญหาพื้นฐานคือการดำเนินการ JDBC บล็อกในซ็อกเก็ต IO เมื่อมันทำเช่นนี้มันจะบล็อคเธรดที่กำลังทำงานอยู่ - ตอนจบของเรื่อง กรอบการตัดใดก็ตามที่คุณเลือกที่จะใช้เพื่อจบลงด้วยหนึ่งเธรดที่ถูกเก็บไว้ไม่ว่าง / ถูกบล็อกตามคำขอที่เกิดขึ้นพร้อมกัน

ถ้าไดรเวอร์ฐานข้อมูลพื้นฐาน (MySql?) เสนอวิธีการสกัดกั้นการสร้างซ็อกเก็ต (ดู SocketFactory) จากนั้นฉันคิดว่ามันเป็นไปได้ที่จะสร้างเลเยอร์ฐานข้อมูลที่ขับเคลื่อนด้วยเหตุการณ์ async ที่ด้านบนของ JDBC api แต่เราต้อง encapsulate JDBC ทั้งหมดที่อยู่ด้านหลังของกิจกรรมที่สร้างจากด้านหน้าและซุ้มนั้นจะไม่ดูเหมือน JDBC (หลังจากนั้นจะเป็นตัวขับเคลื่อนเหตุการณ์) การประมวลผลฐานข้อมูลจะเกิดขึ้นแบบอะซิงโครนัสบนเธรดอื่นไปยังผู้เรียกและคุณต้องหาวิธีสร้างตัวจัดการทรานแซคชันที่ไม่ต้องอาศัยความสัมพันธ์ของเธรด

สิ่งที่ชอบวิธีที่ฉันพูดถึงจะช่วยให้แม้กระทั่งเธรดพื้นหลังเดียวในการประมวลผลการโหลดของ JDBC exec ที่เกิดขึ้นพร้อมกัน ในทางปฏิบัติคุณอาจใช้กลุ่มเธรดเพื่อใช้ประโยชน์จากหลายคอร์

(แน่นอนฉันไม่ได้แสดงความคิดเห็นในตรรกะของคำถามเดิมเพียงแค่การตอบสนองที่บ่งบอกว่าการเกิดพร้อมกันในสถานการณ์ที่มีการปิดกั้นซ็อกเก็ต IO เป็นไปได้โดยไม่ต้องใช้รูปแบบตัวเลือก - ง่ายกว่า ในกลุ่มการเชื่อมต่อที่มีขนาดเหมาะสม)

ดูเหมือนว่า MySql อาจทำบางสิ่งตามบรรทัดที่ฉันแนะนำ --- http://code.google.com/p/async-mysql-connector/wiki/UsageExample

เป็นไปไม่ได้ที่จะทำการโทรแบบอะซิงโครนัสไปยังฐานข้อมูลผ่าน JDBC แต่คุณสามารถทำการโทรแบบอะซิงโครนัสกับ JDBCกับนักแสดง (เช่นนักแสดงทำการโทรไปยังฐานข้อมูลผ่าน JDBC และส่งข้อความไปยังบุคคลที่สาม หรือถ้าคุณชอบ CPS พร้อมสัญญาซื้อขายล่วงหน้า (สัญญา) (การดำเนินการที่ดีคือสัญญาScalaz )

ฉันไม่คิดว่าการใช้กลุ่มของเธรดเป็นวิธีแก้ปัญหาเพราะมันไม่ได้ปรับขนาดในกรณีที่มีการร้องขอที่เกิดขึ้นพร้อมกันจำนวนมากสิ่งนี้จะทำให้เกิดเธรดจำนวนมาก

นักแสดงสกาล่าโดยค่าเริ่มต้นจะขึ้นอยู่กับเหตุการณ์ (ไม่ใช่ตามเธรด) - การกำหนดตารางเวลาต่อเนื่องช่วยให้สามารถสร้างนักแสดงหลายล้านคนบนการตั้งค่า JVM มาตรฐาน

หากคุณกำหนดเป้าหมายเป็น Java Akka Frameworkเป็นการนำโมเดล Actor ไปใช้ซึ่งมี API ที่ดีทั้งสำหรับ Java และ Scala

นอกจากนั้นธรรมชาติของ JDBC ซิงโครนัสก็สมเหตุสมผลดีสำหรับฉัน ค่าใช้จ่ายของเซสชันฐานข้อมูลสูงกว่าค่าใช้จ่ายของเธรด Java ที่ถูกบล็อก (ทั้งในส่วนหน้าหรือส่วนหลัง) และรอการตอบกลับ หากแบบสอบถามของคุณทำงานนานจนความสามารถของบริการผู้ปฏิบัติการ (หรือการตัดกรอบงานพร้อมกันของ Actor / fork-join / contract) ไม่เพียงพอสำหรับคุณ โหลดฐานข้อมูล โดยปกติแล้วการตอบสนองจากฐานข้อมูลจะกลับมาอย่างรวดเร็วและบริการผู้ให้บริการที่สำรองข้อมูลด้วยเธรดพูลคงที่นั้นเป็นทางออกที่ดีพอ หากคุณมีคิวรีที่ใช้เวลานานเกินไปคุณควรพิจารณาการประมวลผลล่วงหน้า (ล่วงหน้า) เช่นการคำนวณใหม่ทุกคืนของข้อมูลหรืออะไรทำนองนั้น

บางทีคุณอาจใช้ระบบการส่งข้อความแบบอะซิงโครนัส JMS ซึ่งมีขนาดค่อนข้างดี IMHO:

• ส่งข้อความไปยังคิวที่สมาชิกจะยอมรับข้อความและเรียกใช้กระบวนการ SQL กระบวนการหลักของคุณจะยังคงทำงานและยอมรับหรือส่งคำขอใหม่

• เมื่อกระบวนการ SQL สิ้นสุดลงคุณสามารถเรียกใช้วิธีตรงกันข้าม: ส่งข้อความไปยัง ResponseQueue ด้วยผลลัพธ์ของกระบวนการและผู้ฟังทางฝั่งไคลเอ็นต์ยอมรับและดำเนินการรหัสเรียกกลับ

ไม่มีการสนับสนุนโดยตรงใน JDBC แต่คุณมีหลายตัวเลือกเช่น MDB, Executors จาก Java 5

"ฉันไม่คิดว่าการใช้กลุ่มเธรดเป็นวิธีแก้ปัญหาเพราะมันไม่ได้ปรับขนาดในกรณีที่มีการร้องขอพร้อมกันอย่างมากสิ่งนี้จะทำให้เกิดเธรดจำนวนมาก"

ฉันสงสัยว่าทำไมกลุ่มของเธรดที่มีขอบเขตจะไม่ขยายขนาด มันเป็นพูลที่ไม่ใช่เธรดต่อการร้องขอเพื่อวางเธรดต่อการร้องขอแต่ละครั้ง ฉันเคยใช้สิ่งนี้มานานแล้วบนเว็บโหลดหนักและเรายังไม่พบปัญหาใด ๆ

ดูเหมือนว่า jdbc API แบบอะซิงโครนัสใหม่ "JDBC next" จะอยู่ในผลงาน

ดูการนำเสนอที่นี่

คุณสามารถดาวน์โหลด API ได้จากที่นี่

ตามที่ระบุไว้ในคำตอบอื่น ๆ JDBC API ไม่ใช่ Async โดยธรรมชาติ
อย่างไรก็ตามหากคุณสามารถใช้ชีวิตกับชุดย่อยของการดำเนินการและ API ที่แตกต่างกันมีวิธีแก้ปัญหา ตัวอย่างหนึ่งคือhttps://github.com/jasync-sql/jasync-sqlที่ทำงานกับ MySQL และ PostgreSQL

โครงการ Ajdbc ดูเหมือนจะตอบปัญหานี้ได้http://code.google.com/p/adbcj/

ปัจจุบันมีไดร์เวอร์ async แบบทดลอง 2 ตัวสำหรับ mysql และ postgresql

คำถามเก่า แต่มีข้อมูลเพิ่มเติม เป็นไปไม่ได้ที่จะมีปัญหา JDBC ร้องขอแบบอะซิงโครนัสไปยังฐานข้อมูลเองเว้นแต่ผู้ขายจะให้ส่วนขยายกับ JDBC และ wrapper เพื่อจัดการกับ JDBC ด้วย ที่กล่าวว่าเป็นไปได้ที่จะรวม JDBC เข้ากับการประมวลผลคิวและเพื่อใช้ตรรกะที่สามารถประมวลผลคิวในการเชื่อมต่อที่แยกจากกัน ข้อดีอย่างหนึ่งของสิ่งนี้สำหรับการโทรบางประเภทคือตรรกะหากมีภาระมากพอสามารถแปลงการเรียกไปเป็นแบตช์ JDBC สำหรับการประมวลผลซึ่งสามารถเพิ่มความเร็วของตรรกะได้อย่างมาก สิ่งนี้มีประโยชน์มากที่สุดสำหรับการโทรที่มีการใส่ข้อมูลและผลลัพธ์ที่แท้จริงต้องได้รับการบันทึกหากมีข้อผิดพลาด ตัวอย่างที่ดีของสิ่งนี้คือถ้ามีการแทรกส่วนแทรกเพื่อบันทึกกิจกรรมของผู้ใช้ แอปพลิเคชันชนะ

ในฐานะที่เป็นหมายเหตุด้านผลิตภัณฑ์หนึ่งในตลาดมีวิธีการผลักดันนโยบายเพื่อให้การโทรแบบอะซิงโครนัสเหมือนที่ฉันอธิบายให้ทำแบบอะซิงโครนัส ( http://www.heimdalldata.com/ ) ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้ร่วมก่อตั้ง บริษัท นี้ อนุญาตให้ใช้นิพจน์ทั่วไปกับการร้องขอการแปลงข้อมูลเช่นการแทรก / อัพเดต / ลบสำหรับแหล่งข้อมูล JDBC ใด ๆ และจะทำการแบทช์เข้าด้วยกันโดยอัตโนมัติเพื่อการประมวลผล เมื่อใช้กับ MySQL และตัวเลือก rewriteBatchStatements ( MySQL และ JDBC กับ rewriteBatchStatements = true ) สิ่งนี้จะทำให้ภาระโดยรวมลดลงอย่างมากในฐานข้อมูล

คุณมีสามทางเลือกในความคิดของฉัน:

1. ใช้คิวที่เกิดขึ้นพร้อมกันเพื่อกระจายข้อความข้ามเธรดจำนวนน้อยและคงที่ ดังนั้นหากคุณมี 1,000 การเชื่อมต่อคุณจะมี 4 กระทู้ไม่ใช่ 1000 กระทู้
2. ทำการเข้าถึงฐานข้อมูลบนโหนดอื่น (เช่นกระบวนการหรือเครื่องอื่น) และให้ไคลเอนต์ฐานข้อมูลของคุณทำการเชื่อมต่อเครือข่ายแบบอะซิงโครนัสไปยังโหนดนั้น
3. ใช้ระบบการกระจายที่แท้จริงผ่านข้อความแบบอะซิงโครนัส เพื่อที่คุณจะต้องมีคิวการส่งข้อความเช่น CoralMQ หรือ Tibco

คำปฏิเสธ:ฉันเป็นหนึ่งในผู้พัฒนาของ CoralMQ

มีการพัฒนาโซลูชันเพื่อให้สามารถเชื่อมต่อรีแอกทีฟได้ด้วยฐานข้อมูลเชิงสัมพันธ์มาตรฐาน

ผู้ที่ต้องการปรับขนาดในขณะที่การใช้งานฐานข้อมูลเชิงสัมพันธ์นั้นถูกตัดออกจากการเขียนโปรแกรมปฏิกิริยาเนื่องจากมาตรฐานที่มีอยู่ตามการบล็อก I / O R2DBC ระบุ API ใหม่ที่อนุญาตให้ใช้รหัสปฏิกิริยาที่ทำงานอย่างมีประสิทธิภาพกับฐานข้อมูลเชิงสัมพันธ์

R2DBC เป็นข้อมูลจำเพาะที่ออกแบบมาตั้งแต่ต้นสำหรับการเขียนโปรแกรมเชิงโต้ตอบด้วยฐานข้อมูล SQL ที่กำหนด SPI ที่ไม่ปิดกั้นสำหรับผู้พัฒนาโปรแกรมควบคุมฐานข้อมูลและผู้เขียนไลบรารีไคลเอ็นต์ ไดรเวอร์ R2DBC ใช้โพรโทคอล wire ของฐานข้อมูลด้านบนของเลเยอร์ I / O ที่ไม่บล็อก

เว็บไซต์ของ R2DBC

GitHub ของ R2DBC

คุณสมบัติเมทริกซ์

ตัวเรียกใช้Java 5.0อาจมีประโยชน์

คุณสามารถมีจำนวนเธรดที่แน่นอนเพื่อจัดการกับการดำเนินการที่ต้องใช้เวลานาน และRunnableคุณสามารถใช้Callableแทนซึ่งจะส่งคืนผลลัพธ์ ผลที่ได้ถูกห่อหุ้มในFuture<ReturnType>วัตถุดังนั้นคุณสามารถรับมันได้เมื่อมันกลับมา

นี่คือโครงร่างเกี่ยวกับสิ่งที่ jdbc api ที่ไม่มีการบล็อกอาจมีลักษณะเช่นนี้จาก Oracle ที่นำเสนอที่ JavaOne: https://static.rainfocus.com/oracle/oow16/sess/1461693351182001EmRq/ppt/CONF1578%2020160916.pdf

ดังนั้นดูเหมือนว่าในที่สุดการโทร JDBC แบบอะซิงโครนัสอย่างแท้จริงจะเป็นไปได้จริง ๆ

เป็นความคิดที่บ้าคลั่ง: คุณสามารถใช้รูปแบบ Iteratee บนชุดผลลัพธ์ JBDC ในอนาคต / สัญญาบางอย่าง

แฮมเมอร์ไม่ว่าสำหรับMongoDB

ฉันแค่คิดไอเดียที่นี่ ทำไมคุณถึงไม่มีพูลการเชื่อมต่อฐานข้อมูลกับแต่ละอันที่มีเธรด แต่ละเธรดสามารถเข้าถึงคิวได้ เมื่อคุณต้องการทำแบบสอบถามที่ใช้เวลานานคุณสามารถใส่คิวและจากนั้นหนึ่งในเธรดจะรับและจัดการ คุณจะไม่มีเธรดมากเกินไปเนื่องจากจำนวนเธรดของคุณถูก จำกัด ขอบเขต

แก้ไข: หรือดีกว่าเพียงแค่จำนวนกระทู้ เมื่อเธรดเห็นบางสิ่งในคิวมันจะขอการเชื่อมต่อจากกลุ่มและจัดการกับมัน

ห้องสมุดคอมมอน-dbutils มีการสนับสนุนการAsyncQueryRunnerที่คุณให้ไปและจะส่งกลับExecutorService Futureคุ้มค่าที่จะเช็คเอาท์เพราะมันใช้งานง่ายและให้แน่ใจว่าคุณจะไม่รั่วไหลของทรัพยากร

หากคุณมีความสนใจใน API ฐานข้อมูลแบบอะซิงโครนัสสำหรับ Java คุณควรทราบว่ามีความคิดริเริ่มใหม่ที่จะเกิดขึ้นกับชุดของ API มาตรฐานโดยยึดตาม CompletableFuture และ lambdas นอกจากนี้ยังมีการใช้งาน API เหล่านี้ผ่าน JDBC ซึ่งสามารถใช้เพื่อฝึก API เหล่านี้: https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ JavaDoc ถูกกล่าวถึงใน README โครงการ GitHub