การใช้ไฟล์แฟลตเทียบกับฐานข้อมูล / API เป็นการขนส่งระหว่างส่วนหน้าและส่วนหลัง

ฉันมีแอปพลิเคชั่นที่สร้างการสนทนาที่ค่อนข้างร้อนแรงระหว่างนักพัฒนาสองคน

โดยทั่วไปจะแบ่งเป็นเลเยอร์เว็บและเลเยอร์แบ็กเอนด์ เลเยอร์เว็บรวบรวมข้อมูลโดยแบบฟอร์มเว็บอย่างง่ายหยุดข้อมูลนี้เป็นเอกสาร JSON (แท้จริงไฟล์. json) ลงในโฟลเดอร์เฝ้าดูที่ใช้โดยส่วนหลัง ส่วนหลังทำการสำรวจโฟลเดอร์นี้ทุกสองสามวินาทีหยิบไฟล์ขึ้นมาและทำหน้าที่ของมัน

ตัวไฟล์เองนั้นง่ายมาก (เช่นข้อมูลสตริงทั้งหมด, ไม่มีการซ้อน), และประมาณ 1-2k ที่ใหญ่ที่สุด, โดยระบบใช้เวลาส่วนใหญ่ในการใช้งาน (แต่การกระจายข้อความสูงสุด 100 ข้อความในเวลาใดก็ตาม) ขั้นตอนการประมวลผลส่วนหลังใช้เวลาประมาณ 10 นาทีต่อข้อความ

ข้อโต้แย้งเกิดขึ้นเมื่อผู้พัฒนารายหนึ่งแนะนำว่าการใช้ระบบไฟล์เป็นเลเยอร์การส่งข้อความเป็นวิธีแก้ปัญหาที่ไม่ดีเมื่อบางสิ่งเช่นฐานข้อมูลเชิงสัมพันธ์ (MySQL), ฐานข้อมูล noSQL (Redis) หรือแม้แต่การเรียก REST API ธรรมดาควรใช้แทน

ควรสังเกตว่า Redis ถูกใช้ที่อื่นในองค์กรสำหรับการจัดการข้อความที่อยู่ในคิว

ข้อโต้แย้งที่ฉันได้ยินแตกออกเป็นดังนี้

ในความโปรดปรานของไฟล์แบน:

• ไฟล์แบบเรียบมีความน่าเชื่อถือมากกว่าโซลูชันอื่น ๆ เนื่องจากไฟล์จะถูกย้ายจากโฟลเดอร์ "เฝ้าดู" ไปยังโฟลเดอร์ "กำลังดำเนินการ" หลังจากที่รับแล้วและท้ายที่สุดไปยังโฟลเดอร์ "เสร็จสิ้น" เมื่อเสร็จสิ้น ไม่มีความเสี่ยงของข้อความที่จะหายไปยกเว้นข้อผิดพลาดในระดับต่ำมากซึ่งจะทำลายสิ่งอื่น ๆ อย่างไรก็ตาม

• ไฟล์แบบแฟลตต้องการความซับซ้อนทางเทคนิคที่น้อยกว่าในการทำความเข้าใจ - เพียงแค่catมัน ไม่มีข้อสงสัยในการเขียนไม่มีความเสี่ยงในการเปิดข้อความโดยไม่ตั้งใจและทำให้ข้อความหายไปตลอดกาล

• รหัสการจัดการไฟล์นั้นง่ายกว่า API ฐานข้อมูลจากมุมมองการเขียนโปรแกรมเนื่องจากเป็นส่วนหนึ่งของไลบรารีมาตรฐานของทุกภาษา สิ่งนี้จะช่วยลดความซับซ้อนโดยรวมของฐานรหัสและจำนวนรหัสบุคคลที่สามที่ต้องนำเข้ามา

• หลักการ YAGNIรัฐว่าไฟล์แบนทำงานได้ดีในขณะนี้มีไม่แสดงให้เห็นถึงความจำเป็นในการเปลี่ยนไปเป็นวิธีการแก้ปัญหาที่มีความซับซ้อนมากขึ้นดังนั้นปล่อยให้มัน

ในความโปรดปรานของฐานข้อมูล:

• ง่ายต่อการปรับขนาดฐานข้อมูลมากกว่าไดเรกทอรีที่เต็มไปด้วยไฟล์

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

• ต้องการความซับซ้อนทางเทคนิคเพิ่มเติมสำหรับ T / S แอปหมายความว่าพนักงานที่ไม่มีการศึกษามีโอกาสน้อยที่จะพลาดอะไรบางอย่าง

• รหัสการเชื่อมต่อฐานข้อมูลโดยเฉพาะอย่างยิ่งสำหรับ Redis อย่างน้อยก็มีความทนทานเท่ากับฟังก์ชั่นการจัดการไฟล์ไลบรารีมาตรฐาน

• รหัสการเชื่อมต่อฐานข้อมูลมองเห็นได้ชัดเจน (ถ้าไม่สามารถใช้งานได้) ง่ายกว่าจากจุดยืนของนักพัฒนาเนื่องจากระดับที่สูงกว่าการจัดการไฟล์

จากสิ่งที่ฉันเห็นนักพัฒนาทั้งสองมีคะแนนที่ถูกต้องมากมาย

ดังนั้นในสองคนนี้คือ pro-files dev หรือ pro-database dev ซึ่งเป็นหนึ่งในแนวปฏิบัติที่ดีที่สุดสำหรับวิศวกรรมซอฟต์แวร์และทำไม?

เปลี่ยนเป็นโซลูชันที่เกี่ยวข้องกับฐานข้อมูลหรือระบบการจัดคิวที่ Ewan กล่าวถึง

• สร้างการพึ่งพาระบบใหม่ที่ซับซ้อนทั้งในส่วนหลังและส่วนหน้า
• นำเสนอความซับซ้อนที่ไม่จำเป็นและ sh * tload ของจุดใหม่ของความล้มเหลว
• เพิ่มค่าใช้จ่าย (รวมถึงต้นทุนการเป็นเจ้าของ)

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

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

ฉันไม่คิดว่าวิธีแก้ปัญหาอย่างใดอย่างหนึ่งเป็นการปฏิบัติที่ไม่ดีดังนั้นการตอบคำถามซึ่งเป็นวิธีปฏิบัติที่ดีที่สุดอาจเป็นเรื่องยาก

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

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

หากหลักการของ YAGNI มีผลกับที่นี่และไฟล์ไม่ได้เป็นคอขวดมันจะขยายตามขอบเขตและไม่มีปัญหาร้ายแรงฉันจะบอกว่าการติดกับไฟล์นั้นเป็น "แนวปฏิบัติที่ดีที่สุด" ไม่มีเหตุผลที่จะเปลี่ยนแปลงอะไรหากไม่มีปัญหาอาจจะเขียนการทดสอบบางส่วนเน้นมันและดูว่าข้อ จำกัด และคอขวดของคุณอยู่ที่ไหน

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

ในขณะที่ดี 'ol บันทึกไฟล์และคัดลอกไปยัง dir เสร็จเป็นหลักของเลเยอร์การสื่อสารหลาย esp ด้วยระบบเฟรมหลักที่เก่ากว่าและไม่ชอบ พวกต่อต้านมีจุด; ในกรณีที่มันมีปัญหามากมายและกรณีขอบ ซึ่งยากที่จะจัดการหากคุณต้องการ reliablitiy 100% และเกิดขึ้นบ่อยขึ้นเมื่อคุณขยายความถี่และปริมาณของไฟล์

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

โซลูชันฐานข้อมูลนั้นถูกต้อง มันแก้ปัญหาการพึ่งพาอาศัยกันมากกับโฮสต์หรือเงื่อนไขขอบเขต

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

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

นอกจากนี้ในระบบไฟล์หากคุณต้องการใส่แอปพลิเคชันในชื่อไฟล์เช่น OASIS คุณจะต้องสร้างไฟล์ OASIS.john_doe.system1.20160202 สิ่งนี้กลายเป็นเรื่องน่าเบื่อและสามารถแสดงได้ง่ายขึ้นในฐานข้อมูล คุณสามารถมีฟิลด์ว่างในฐานข้อมูลและตรรกะตามที่

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

เช่นคุณต้องการรันใหม่ แต่มีระบบที่แตกต่างจาก OASIS พูดว่า DESERT และ john_doe ไปยัง doe_smith และเดทจาก 20160101 ถึง 20151231

ง่ายต่อการสร้างแถวสำหรับ DESERT / doe_smith / 20151231 จากชุดดั้งเดิมแทนที่จะสร้างไฟล์เหล่านั้นด้วยเชลล์สคริปต์

ดังนั้นจากความสามารถในการอ่านจุดส่วนขยายของโซลูชันฐานข้อมูลมุมมองจะดีกว่า