เร็วกว่าอะไร ใช้ REST API หรือสอบถามฐานข้อมูลโดยตรง

16

ประสิทธิภาพที่รวดเร็วกว่าคืออะไร การสร้าง REST API และการมีเว็บแอปของคุณใช้ REST API เพื่อทำการโต้ตอบกับฐานข้อมูลของคุณหรือทำการสืบค้นฐานข้อมูลของคุณโดยตรง (เช่นการใช้วัตถุทั่วไปที่ภาษาของคุณใช้ในการสืบค้นฐานข้อมูลเช่น JDBC for Java)?

วิธีที่ฉันเห็นด้วย REST:

  1. คุณสร้างวัตถุในรหัสของคุณเพื่อเรียกใช้วิธีการ REST
  2. โทรวิธี http
  3. รหัสภายใน REST API ของคุณจะค้นหาฐานข้อมูล
  4. ฐานข้อมูลส่งคืนข้อมูลบางส่วน
  5. รหัส REST API จะแพ็คข้อมูลลงใน Json และส่งไปยังลูกค้าของคุณ
  6. ลูกค้าได้รับการตอบสนอง Json / XML
  7. แมปการตอบสนองกับวัตถุในรหัสของคุณ

ในทางตรงกันข้ามการสืบค้นฐานข้อมูลโดยตรง:

  1. คุณทำวัตถุด้วยสายอักขระแบบสอบถามเพื่อสอบถามฐานข้อมูล
  2. ฐานข้อมูลส่งคืนข้อมูลบางส่วน
  3. แมปการตอบสนองกับวัตถุในรหัสของคุณ

ดังนั้นนี่ไม่ได้หมายความว่าการใช้ REST API จะช้าลงหรือไม่ อาจขึ้นอยู่กับประเภทของฐานข้อมูล (SQL กับ NoSQL)?

database  rest  sql 
— ไมโคร
แหล่งที่มา
3
REST API ไม่ใช่โปรโตคอลการเข้าถึงฐานข้อมูลดังนั้นคำถามนี้เป็นข้อผิดพลาดใหญ่ ๆ ของหมวดหมู่ REST api เป็นที่เก็บเอกสาร อาจใช้ฐานข้อมูลทางฝั่งเซิร์ฟเวอร์ (หรืออาจไม่ได้) หากคุณไม่ต้องการ REST API แน่นอนว่าอย่าใช้ แต่สำหรับทุกสิ่ง หากคุณไม่ต้องการฐานข้อมูลไม่ได้ใช้งานการเขียนไปยังระบบไฟล์จะเร็วกว่าฐานข้อมูล หากคุณไม่ต้องการระบบไฟล์ไม่ใช้งานการเขียนลง RAM เร็วกว่าดิสก์ หากคุณไม่ต้องการ RAM ไม่ใช้งานการเขียนไปยัง CPU cache นั้นเร็วขึ้น ฯลฯ และอื่น ๆ
— Cormac Mulhall
1
"ในทางกลับกัน" คุณต้องเปิดเผยฐานข้อมูลของคุณสู่โลกที่เลวร้าย
— ปีเตอร์บี
@PieterB: ไม่ "ในทางกลับกัน" กำลังเปิดเผยฐานข้อมูลไปยังเว็บแอปที่เชื่อถือได้
— JacquesB
@JacquesB และเว็บแอปทำงานบนคอมพิวเตอร์ไคลเอนต์ ดังนั้นจึงไม่น่าเชื่อถือเพราะอาจเป็นรุ่นที่แก้ไข
— ปีเตอร์ B
@PieterB: คำถามไม่ได้ระบุอะไรเกี่ยวกับแอปพลิเคชันเว็บที่ทำงานบนเซิร์ฟเวอร์ที่ไม่น่าเชื่อถือ นั่นจะเป็นการติดตั้งที่ผิดปกติอย่างมาก
— JacquesB

คำตอบ:

18

เมื่อคุณเพิ่มความซับซ้อนรหัสจะทำงานช้าลง แนะนำเซอร์วิส REST หากไม่ต้องการจะทำให้การดำเนินการช้าลงเนื่องจากระบบกำลังทำงานมากขึ้น

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

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

— Klee
แหล่งที่มา
+1 สำหรับการกล่าวถึงแคช extra workแม้ว่ามันจะทำ แต่จริงๆแล้วมันอาจเร็วกว่านี้ด้วยการแคชคิวรีซ้ำ
— Yana Agun Siswanto
3
@Klee คำตอบของคุณไม่ถูกต้องนัก »แนะนำบริการ REST หากไม่ต้องการจะทำให้การดำเนินการช้าลงเนื่องจากระบบทำงานได้มากขึ้น«ไม่ได้ในทุกกรณีที่มีการรับส่งข้อมูลไปยังจุดสิ้นสุดเลยถ้าเช่นพร็อกซีย้อนกลับสามารถจัดการผลลัพธ์ได้
— Thomas Junk
@klee เหตุผลที่ฉันถามคำถามนี้มาจากprogrammers.stackexchange.com/questions/277701/โพสต์นี้- คำตอบหนึ่งที่พูดถึงว่า Amazon ประสบความสำเร็จได้อย่างไรโดยใช้ระบบ RESTful แทนการเข้าถึงโดยตรง เพิ่งได้รับฉันคิดว่า ...
— Micro
9

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

พิจารณาว่าความกังวลหลักของคุณคือการทำงานร่วมกัน (มือถือ, เว็บ, B2B) ตอนนี้ REST น่าสนใจมากเพราะเป็นผู้ไม่เชื่อเรื่องเทคโนโลยี

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

คำตอบที่แท้จริงนั้นขึ้นอยู่กับมันแต่หวังว่าฉันจะให้สิ่งที่คุณคิด!

— Romski
แหล่งที่มา
6

หากพบว่ามันยากที่จะตอบคำถามนี้

คำตอบทั่วไปที่ถูกต้องควรเป็น: มันขึ้นอยู่กับ

วิธีที่ฉันเห็นด้วย REST:

  1. คุณสร้างวัตถุในรหัสของคุณเพื่อเรียกใช้วิธีการ REST
  2. โทรวิธี http
  3. รหัสภายใน REST API ของคุณจะค้นหาฐานข้อมูล
  4. ฐานข้อมูลส่งคืนข้อมูลบางส่วน
  5. รหัส REST API จะแพ็คข้อมูลลงใน Json และส่งไปยังลูกค้าของคุณ
  6. ลูกค้าได้รับการตอบสนอง Json / XML
  7. แมปการตอบสนองกับวัตถุในรหัสของคุณ

มีความผิดพลาดในความคิดของคุณ

และความผิดพลาดนี้เกิดจากความจริงที่ว่าคุณไม่เข้าใจส่วนที่เหลือและหลักการของ REST ไม่ได้ถูกประดิษฐ์เนื่องจาก nerds บางคนพบว่ามันเจ๋ง (แน่นอนมัน) ในการส่ง Javascript-objects ผ่าน HTTP ผ่านทางสาย ประโยชน์หลักของการใช้ HTTP ความเป็นไปได้ของการใช้แคช ถ้าคุณทำให้ผลลัพธ์ของคุณแคชแล้วมีคำขอน้อยที่จะทำกับฐานข้อมูล และไม่มีมาร์แชลล์มีส่วนเกี่ยวข้อง สามารถส่งคำตอบได้โดยตรง

Insofar @Klees คำตอบไม่ถูกต้อง :

เมื่อคุณเพิ่มความซับซ้อนรหัสจะทำงานช้าลง แนะนำเซอร์วิส REST หากไม่ต้องการจะทำให้การดำเนินการช้าลงเนื่องจากระบบกำลังทำงานมากขึ้น

เมื่อจัดการกับผลลัพธ์ที่แคชได้จะไม่มีผลกระทบต่อแอปพลิเคชันของคุณ: การส่งคำตอบที่เป็นที่รู้จักไปยังคำถามที่รู้จักสามารถทำได้ผ่าน reverse-proxies

— โทมัสขยะ
แหล่งที่มา
4
หากข้อมูลสามารถแคชได้ในเลเยอร์เซอร์วิสส่วนที่เหลือจะสามารถแคชได้ในเว็บแอปซึ่งจะดีกว่ามากสำหรับประสิทธิภาพ
— JacquesB
วิธีที่เร็วที่สุดคือไม่ตีเว็บแอปเลย
— Thomas Junk
1
และเพื่อทำให้มันน่าสนใจยิ่งขึ้นไม่ใช่ "ฮิต" ทั้งหมดในฐานข้อมูลเท่ากันถ้าคุณสามารถเข้าถึงในหน่วยความจำ v. ดิสก์
— JeffO
@ThomasJunk: ถ้าฉันเข้าใจคำถามเดิมถูกต้องไคลเอนต์เป็นเว็บแอพและคำถามคือถ้าเว็บแอปควรเชื่อมต่อกับฐานข้อมูลโดยตรงหรือโทรผ่านบริการส่วนที่เหลือ
— JacquesB
1
นั่นไม่เปลี่ยนแปลงอะไรเลยในคำตอบของฉัน การโทรหา REST-Service นั้นรวมถึงการโทรออกไปยังเว็บเซิร์ฟเวอร์ซึ่งอาจจะอยู่หลังพร็อกซีย้อนกลับซึ่งอาจเป็นคำตอบที่เป็นไปได้ที่แคชไว้ - อย่างที่ฉันพูดไปแล้ว
— โทมัสขยะ
2

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

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

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

— JacquesB
แหล่งที่มา
1

มันขึ้นอยู่กับ.

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

มีเหตุผลอื่นที่จะซ่อนฐานข้อมูลของคุณไว้หลังเลเยอร์ชั้นกลางเช่นความปลอดภัย

— gbjbaanb
แหล่งที่มา
-2

ฉันไม่รู้ว่าคุณหลงทางไหน แต่ก็ค่อนข้างชัดเจนเมื่อคุณใช้ REST API คุณกำลังทำขั้นตอนเพิ่มเติมและขั้นตอนพิเศษ "เสมอ" หมายถึงช้าลงเมื่อมีการเขียนโปรแกรมที่เกี่ยวข้อง

มีข้อดีข้อเสีย แต่ถ้าคุณสามารถเข้าถึงฐานข้อมูลโดยตรงจากแอปพลิเคชันของคุณมันจะดีกว่าที่จะเรียกมันโดยตรงแทนที่จะใช้ Web API แน่นอนถ้าคุณใช้ Web API คุณสามารถพอร์ตแอปพลิเคชันของคุณไปยังแพลตฟอร์มอื่นได้อย่างง่ายดาย

— KIRIE
แหล่งที่มา
1
»ฉันไม่รู้ว่าคุณหลงทางไหน แต่ก็ชัดเจนเมื่อคุณใช้ REST API คุณกำลังทำขั้นตอนเพิ่มเติมและขั้นตอนพิเศษ "เสมอ" หมายถึงช้าลงเมื่อโปรแกรมที่เกี่ยวข้อง«ถ้านั่นหมายถึงการทำงานที่ช้าลง นั่นไม่ถูกต้อง
— โทมัสขยะ
1
ไม่มีสถานการณ์ที่การเข้าถึงฐานข้อมูลเป็นความคิดที่ดีนอกเหนือจากการพกพาได้หรือไม่ บางครั้งการมี REST API และอื่น ๆ สามารถรักษาความปลอดภัยได้มากกว่า
— J Trana
@JTrana อาจเป็นได้หรือไม่นั้นขึ้นอยู่กับว่าคุณทำสิ่งใดในขณะที่การแนะนำเลเยอร์เพิ่มเติมสามารถเพิ่มความปลอดภัยให้กับเลเยอร์เพิ่มเติมการเพิ่มเลเยอร์พิเศษก็หมายความว่าคุณมีโอกาสมากขึ้นที่จะทำให้เมามากขึ้น ฉันคิดว่าจุดของ Web API คือการเปิดเผย "API" ของคุณ แอปพลิเคชันขนาดใหญ่เช่น Facebook, Amazon, Google ที่จำเป็นต้องให้การเข้าถึงบุคคลที่สามและมีแพลตฟอร์มจำนวนมากจะต้องมี Web API แต่สำหรับแอปพลิเคชันขนาดเล็กคุณต้องคิดสองครั้งก่อนที่จะทำ
— kirie
-2

ส่วนที่เหลือ:

  • เปิดให้หลายส่วนหน้าและ 1 แบ็กเอนด์
  • จำเป็นต้องสร้าง API ของคุณเอง (หรือใช้หนึ่งอย่างเช่นลูปแบ็ค)
  • ไม่ทำงานครับ

ฐานข้อมูลท้องถิ่น:

  • ไม่เปิดเป็น 'ระดับ' พวกเขาต้องเข้าถึงแบ็กเอนด์ของคุณเพื่อซิงโครไนซ์
  • ไม่จำเป็นต้องสร้าง API ใช้อินเตอร์เฟส DB
  • ทำงานออฟไลน์

นี่คือความแตกต่างที่มีขนาดใหญ่มากคนมักจะลืมคะแนนเหล่านี้

— Benjamin Fuentes
แหล่งที่มา
2
-1 แม้ว่าจะไม่มี "ความต้องการ" ในการสร้าง API แต่การสร้าง DAL มักจะนำไปสู่ความเจ็บปวดอย่างมากหากจำเป็นต้องเปลี่ยนแบ็กเอนด์ฐานข้อมูล นอกจากนี้ยังไม่มีเหตุผลว่าทำไมหากคุณมีฐานข้อมูล "ออฟไลน์" ที่บริการส่วนที่เหลือไม่สามารถให้บริการได้เช่นกัน
— James Snell
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.