เหตุใดจึงต้องใช้ฐานข้อมูลแทนที่จะบันทึกข้อมูลลงดิสก์

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

ทำไมหนึ่งควรใช้ฐานข้อมูลแทนการบันทึกข้อมูลลงดิสก์

1. คุณสามารถสืบค้นข้อมูลในฐานข้อมูล (ถามคำถาม)
2. คุณสามารถค้นหาข้อมูลจากฐานข้อมูลได้อย่างรวดเร็ว
3. คุณสามารถเชื่อมโยงข้อมูลจากสองตารางที่แตกต่างกันโดยใช้ JOIN
4. คุณสามารถสร้างรายงานที่มีความหมายจากข้อมูลในฐานข้อมูล
5. ข้อมูลของคุณมีโครงสร้างในตัว
6. ข้อมูลประเภทที่กำหนดจะถูกเก็บไว้เพียงครั้งเดียวเสมอ
7. ฐานข้อมูลเป็นกรด
8. ฐานข้อมูลทนต่อความผิดพลาด
9. ฐานข้อมูลสามารถจัดการชุดข้อมูลที่มีขนาดใหญ่มาก
10. ฐานข้อมูลพร้อมกัน; ผู้ใช้หลายคนสามารถใช้พวกเขาในเวลาเดียวกันโดยไม่ทำลายข้อมูล
11. ฐานข้อมูลมีขนาดที่ดี

ในระยะสั้นคุณจะได้รับประโยชน์จากเทคโนโลยีที่ได้รับการยอมรับและได้รับการพิสูจน์มาเป็นระยะเวลาหลายปีซึ่งพัฒนาโดยคนที่ฉลาด

หากคุณกังวลว่าฐานข้อมูลมีจำนวนมากเกินไปให้ตรวจสอบ SQLite

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

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

สำหรับเมื่อใช้ RDBMS นี่คือบางจุดที่ควรพิจารณา:

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

สำหรับเมื่อใดที่จะใช้ NoSQL

• คุณมีข้อมูลจำนวนมากที่ต้องเก็บไว้ซึ่งไม่มีโครงสร้าง
• ความสามารถในการปรับขนาดและความเร็ว
• โดยทั่วไปคุณไม่จำเป็นต้องกำหนดสคีมาล่วงหน้าดังนั้นหากคุณมีข้อกำหนดที่เปลี่ยนแปลงนี่อาจเป็นจุดที่ดี

ในที่สุดเมื่อจะใช้ไฟล์

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

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

เมื่อคุณซับซ้อนมากขึ้นคุณกำลังสร้างฐานข้อมูลจริง ๆ สิ่งที่คุณต้องการเรียกใช้ฐานข้อมูลเป็นเพียงชุดของระเบียนที่เก็บไว้ในดิสก์ ไม่ว่าคุณจะสร้างไฟล์หรือMySQL , SQLiteหรืออะไรก็ตามที่สร้างไฟล์พวกเขาทั้งคู่เป็นฐานข้อมูล

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

สิ่งสำคัญที่สปริงใจคือการจัดทำดัชนี ตกลงเพื่อให้คุณสามารถเก็บ 10 หรือ 20 หรือแม้กระทั่ง 100 หรือ 1,000 บันทึกในอาร์เรย์ต่อเนื่องหรือสตริง JSON และดึงมันออกมาจากไฟล์ของคุณและย้ำมันค่อนข้างเร็ว

ตอนนี้คิดว่าคุณมี 10,000, 100,000 หรือแม้กระทั่ง 1,000,000 บันทึก เมื่อมีคนพยายามเข้าสู่ระบบคุณจะต้องเปิดไฟล์ที่มีขนาดใหญ่หลายร้อยเมกะไบต์ให้โหลดลงในหน่วยความจำในโปรแกรมของคุณดึงข้อมูลที่มีขนาดใกล้เคียงกันออกมา ค้นหาระเบียนหนึ่งรายการที่คุณต้องการเข้าถึง

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

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

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

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

แต่ถึงแม้จะมีรายการง่าย ๆ ที่คุณโหลดเก็บไว้ในหน่วยความจำแล้วเขียนเมื่อจำเป็นอาจประสบปัญหาหลายประการ:

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

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

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

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

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

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

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

โดยรวมแล้วฐานข้อมูล SQL นั้นดีกว่าอาร์เรย์ธรรมดาหากปริมาณข้อมูลอาจมีขนาดใหญ่ (สมมติว่ามีวัตถุมากกว่า 1,000 รายการ) การเข้าถึงข้อมูลในส่วนที่ไม่สำคัญและส่วนต่าง ๆ ของการเข้าถึงรหัสไปยังชุดย่อยของข้อมูลที่แตกต่างกัน

TLDR

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

คุณกำลังนั่งอยู่บนเครื่องบินต่อเนื่องพร้อมตัวเลือกที่จะเคลื่อนที่ไปในทิศทางใดทิศทางหนึ่ง

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

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

เมื่อใดจะทำในสิ่งที่คุณทำ

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

นอกจากนี้ยังเป็นการผสมผสานที่ง่ายในการเขียนโค้ดสำหรับ - APIนั้นค่อนข้างตรงไปตรงมาและเป็นพื้นฐานและใช้รหัสไม่กี่บรรทัดเพื่อให้มันทำงานได้

โดยทั่วไปแล้วมันเหมาะอย่างยิ่งที่จะทำสิ่งที่คุณทำเมื่อ:

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

ทางเลือก

คุณมีตัวเลือกที่ต่อเนื่องและมีสองทิศทางที่คุณสามารถไปจากที่นี่สิ่งที่ฉันคิดว่าเป็น 'ลง' และ 'ขึ้น':

ลง

นี่เป็นตัวเลือกที่มีโอกาสน้อยที่สุดที่จะนำไปใช้ แต่เพื่อประโยชน์ที่ครบถ้วน:

คุณสามารถลงไปได้ถ้าคุณต้องการข้ามระบบปฏิบัติการและระบบไฟล์ไปพร้อม ๆ กันและเขียนและอ่านโดยตรงจากดิสก์ ตัวเลือกนี้มักจะเกี่ยวข้องเฉพาะในกรณีที่จำเป็นต้องใช้ประสิทธิภาพสูงสุด - ตัวอย่างเช่นอุปกรณ์เล่นMP3ขนาดจิ๋ว / เล็กไม่มีRAMเพียงพอสำหรับระบบปฏิบัติการที่ใช้งานได้สมบูรณ์หรือสิ่งที่ต้องการWayback Machineซึ่งต้องการมวลที่มีประสิทธิภาพอย่างเหลือเชื่อ การดำเนินการเขียนข้อมูล (ร้านค้าส่วนใหญ่แลกกับการเขียนที่ช้ากว่าเพื่อการอ่านที่เร็วขึ้นเนื่องจากเป็นกรณีการใช้งานทั่วไปที่แพร่หลายมากขึ้นสำหรับแอปพลิเคชันเกือบทั้งหมด)

ขึ้น

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

แหล่งข้อมูลที่มีประสิทธิภาพยิ่งขึ้น

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

นี่คือเส้นทางที่ชัดเจนในการขยายขนาดเมื่อสิ่งต่อไปนี้อธิบายใบสมัครของคุณ:

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

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

ตัวอย่างที่รู้จักกันดี: CouchDB , MongoDB , Redis , โซลูชั่นการจัดเก็บข้อมูลบนคลาวด์เช่นAzureของ Microsoft , Google App Data Store และ ECE ของ Amazon

เอ็นจิ้นการจัดการข้อมูลที่ซับซ้อนมากขึ้น

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

• คุณต้องอ่านอย่างสม่ำเสมอแม้ว่ามันจะหมายความว่าคุณจะได้รับความนิยม
• คุณกำลังมองหาที่จะทำการจัดการข้อมูลที่ซับซ้อนอย่างมีประสิทธิภาพ - คิดถึงการดำเนินการ JOIN และ UPDATE ที่ซับซ้อนมากลูกบาศก์ข้อมูลและการแบ่งส่วน ฯลฯ
• คุณสามารถตกลงกับการซื้อขายที่เข้มงวดสำหรับประสิทธิภาพ (คิดว่าถูกบังคับรูปแบบการจัดเก็บข้อมูลคงที่เช่นตารางซึ่งไม่สามารถเปลี่ยนแปลงได้ง่ายและ / หรือมีประสิทธิภาพ)
• คุณมีทรัพยากรที่จะจัดการกับชุดเครื่องมือและอินเทอร์เฟซที่ซับซ้อนกว่าบ่อยครั้ง

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

ตัวอย่างที่รู้จักกันเป็นอย่างดีMySQL , SQL Server , ฐานข้อมูลของออราเคิลและDB2

จ้างงานจากภายนอก

มีเครื่องมือและไลบรารีของบุคคลที่สามที่ทันสมัยและหลากหลายซึ่งผสานเข้าด้วยกันระหว่างเครื่องมือจัดเก็บข้อมูลและแอปพลิเคชันของคุณเพื่อช่วยคุณจัดการความซับซ้อน

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

ตัวอย่างที่รู้จักกันดีMVCเครื่องมือ ( Django , Yii ), Ruby on RailsและDatomic มันยากที่จะยุติธรรมที่นี่เนื่องจากมีเครื่องมือและไลบรารีหลายสิบตัวที่ทำหน้าที่ห่อหุ้ม APIs ของที่เก็บข้อมูลต่างๆ

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

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

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

• ศูนย์การบริหาร
• ความซับซ้อนต่ำติดตั้งง่าย
• ทำงานร่วมกับระบบปฏิบัติการภาษาแพลตฟอร์มไลบรารี ฯลฯ
• เฉพาะการตั้งค่าการกำหนดค่าเป็นไดเรกทอรี
• ทดสอบเล็กน้อย
• ตรวจสอบเล็กน้อยด้วยเครื่องมือที่มีอยู่สำรองข้อมูลแก้ไข ฯลฯ
• ลักษณะการทำงานที่ดีและปรับตามระบบปฏิบัติการ
• ง่ายสำหรับนักพัฒนาที่จะเข้าใจ
• ไม่มีการพึ่งพาไม่มีไดรเวอร์เพิ่มเติม
• รูปแบบความปลอดภัยนั้นเป็นเรื่องที่เข้าใจได้ง่ายและเป็นส่วนสำคัญของระบบปฏิบัติการ
• ข้อมูลไม่สามารถเข้าถึงจากภายนอก

(ที่มา )

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

ดังนั้นคุณใช้ฐานข้อมูล โพสต์อื่น ๆ สามารถโต้แย้งเกี่ยวกับคุณประโยชน์ของฐานข้อมูลประเภทต่างๆ ...

ฐานข้อมูลเป็นสิ่งจำเป็นหากคุณมีหลายกระบวนการ (ผู้ใช้ / เซิร์ฟเวอร์) แก้ไขข้อมูล จากนั้นฐานข้อมูลจะทำหน้าที่ป้องกันไม่ให้เขียนทับการเปลี่ยนแปลงของกันและกัน

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

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

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

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

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

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

หากคุณต้องการเรียนรู้ORM ที่จัดการโดยภาษาที่คุณเลือกแทนที่จะเรียนรู้ SQL ไปลองใช้ แต่ลองติดตั้งสร้างตารางและดึงข้อมูลบางส่วนออกจากฐานข้อมูลยอดนิยมด้วย SQL (Select * From; ไม่ใช่ ใจ). มันง่ายที่จะทำ นั่นเป็นสาเหตุที่มีคนสร้างมันขึ้นมาตั้งแต่แรก ดูเหมือนว่าการลงทุนครั้งใหญ่จะไม่สามารถตัดสินใจได้อย่างมีข้อมูล คุณอาจทำแบบทดสอบประสิทธิภาพก็ได้เช่นกัน

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

ตัวอย่างเช่น key = ghostwriter จะอยู่ใน g / ho / stwriter.json หรือ g / h / o / stwriter.json หรือ g / ho / ghostwriter.json หรือ g / h / o / ghostwriter.json เลือกรูปแบบการตั้งชื่อตามการกระจายคีย์ของคุณ หากพวกเขาเป็นหมายเลขลำดับ 5/4/3 / 12345.json ดีกว่าวิธีอื่น ๆ

นั่นคือฐานข้อมูลและถ้ามันทำทั้งหมดที่คุณต้องการจากนั้นก็ทำอย่างนั้น ทุกวันนี้ที่เรียกว่าฐานข้อมูล NoSQL เช่น GDBM หรือ Berkeley db ทางเลือกมากมาย ก่อนอื่นให้หาสิ่งที่คุณต้องการจากนั้นสร้างไลบรารีอินเทอร์เฟซเพื่อจัดการกับรายละเอียดบางทีอาจเป็นอินเตอร์เฟสรับ / ตั้งค่าเช่น memcached หรืออินเตอร์เฟส CRUD จากนั้นคุณจะสามารถสลับไลบรารีหากคุณต้องการเปลี่ยนรูปแบบฐานข้อมูลสำหรับ ที่มีลักษณะแตกต่างกัน

โปรดทราบว่าฐานข้อมูล SQL บางตัวเช่น PostgreSQL และ Apache Derby DB จะอนุญาตให้คุณทำแบบสอบถาม SQL ที่อยู่ด้านบนของรูปแบบ NoSQL จำนวนมากรวมถึงฐานข้อมูลของคุณเอง ไม่แน่ใจเกี่ยวกับ MyBatis แต่มันอาจจะคล้ายกัน

หลีกเลี่ยง NoSQL hype อ่านเกี่ยวกับคุณสมบัติทดสอบประสิทธิภาพและความสามารถแล้วเลือกตามความเหมาะสมของแอปพลิเคชันของคุณ

http://www.hdfgroup.org/HDF5/เป็นอีกหนึ่งรูปแบบดาต้าสโตร์ที่น่าสนใจและใช้กันอย่างแพร่หลายซึ่งผู้คนมักจะไม่พิจารณา

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

คุณต้องมีฐานข้อมูลเพื่อจัดเก็บ / รับ QA เหมือนกับที่เราโพสต์ไว้ที่นี่! ไฟล์แบบง่ายไม่สามารถจัดระเบียบข้อมูลที่เกี่ยวข้องกับหัวข้อต่างๆ