Schema-less / ยืดหยุ่น + ฐานข้อมูล ACID?

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

ฉันกำลังดูตัวเลือกฐานข้อมูล: ตัวเลือกของฉันคือ RDBMS: Postgresql / MySQL ฉันอาจขยายผู้ใช้มากถึง 400 คนในปีแรกโดยทั่วไปแล้วมีจำนวนการดู 20-40 หน้า / ต่อวันต่อผู้ใช้ส่วนใหญ่สำหรับธุรกรรมที่ไม่ใช่มุมมองแบบคงที่ แต่ละมุมมองจะเกี่ยวข้องกับการดึงข้อมูลและอัปเดตข้อมูล การปฏิบัติตามข้อกำหนดของกรดเป็นสิ่งที่จำเป็น (หรือฉันคิดว่า) ดังนั้นปริมาณธุรกรรมไม่มาก

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

1. มีการออกแบบสคีมา RDBMS แบบดั้งเดิมใน MySQl / Postgresql ด้วยฐานข้อมูลเดียวที่โฮสต์ผู้เช่าหลายคน และเพิ่มคอลัมน์ "ลอยฟรี" มากพอในแต่ละตารางเพื่ออนุญาตให้มีการเปลี่ยนแปลงในอนาคตเมื่อฉันเพิ่มลูกค้ามากขึ้นหรือเปลี่ยนแปลงสำหรับลูกค้าปัจจุบัน สิ่งนี้อาจมีข้อเสียของการเผยแพร่การเปลี่ยนแปลงไปยังฐานข้อมูลทุกครั้งที่มีการเปลี่ยนแปลงเล็กน้อยกับสคีมา ฉันจำได้ว่าการอ่านว่าในการอัพเดตสกีมา Postgresql สามารถทำได้แบบเรียลไทม์โดยไม่ต้องล็อค แต่ไม่แน่ใจว่าเจ็บปวดหรือใช้งานได้จริงในกรณีนี้อย่างไร และเนื่องจากการเปลี่ยนแปลงของ schema อาจแนะนำการเปลี่ยนแปลง SQL ใหม่ / รองเช่นกัน
2. มี RDBMS แต่ออกแบบสคีมาฐานข้อมูลอย่างยืดหยุ่น: ใกล้กับเอนทิตีแอตทริบิวต์ - ค่าหรือเป็นที่เก็บคีย์ - ค่า (ตัวอย่างเช่นวันทำงาน, FriendFeed)
3. มีทุกสิ่งในหน่วยความจำเป็นวัตถุและเก็บไว้ในล็อกไฟล์เป็นระยะ ๆ (เช่น edval, lmax)
4. ไปหา NoSQL DB เช่น MongoDB หรือ Redis แต่จากสิ่งที่ฉันสามารถรวบรวมได้พวกเขาไม่เหมาะกับกรณีการใช้งานนี้และไม่เข้ากับกรดอย่างสมบูรณ์
5. ไปหา NewSQL Dbs เช่น VoltDb หรือ JustoneDb (cloud based) ซึ่งยังคงรักษาพฤติกรรมที่สอดคล้องกับ SQL และ ACID และเป็น "new-gen" RDBMS
6. ฉันดู neo4j (graphdb) แต่ไม่แน่ใจว่าจะเหมาะกับกรณีการใช้งานนี้หรือไม่

ในกรณีที่ใช้งานของฉันมากกว่าการขยายขนาดหรือการคำนวณแบบกระจายฉันกำลังมองหาวิธีที่ดีกว่าเพื่อให้บรรลุ "ความยืดหยุ่นใน Schema + ACID + ประสิทธิภาพที่เหมาะสม" บทความส่วนใหญ่ที่ฉันพบในเครือข่ายพูดถึงความยืดหยุ่นในสคีมาเป็นสาเหตุที่นำไปสู่ประสิทธิภาพ (ในกรณีของ NoSQL DBs) และความสามารถในการปรับขยายในขณะที่แยกออกจากด้านกรด / ธุรกรรม

นี่เป็นกรณี "หรือ" ของธุรกรรม 'Schema คล่องตัวเทียบกับกรด' หรือมีวิธีที่ดีกว่า?

ตัวเลือกที่ 1

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

• ใช้แพลตฟอร์ม RDBMS ที่คุณเลือก

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

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

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

เหตุผลเบื้องหลังนี้คือ:

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

• เป็นเทคโนโลยีที่ผู้ใหญ่เข้าใจดี

• การจัดการระบบการสำรอง / กู้คืนการทำซ้ำการรายงานและการกู้คืนความเสียหายทั้งหมดนั้นได้รับการจัดเรียงอย่างดีบนแพลตฟอร์ม RDBMS

• คุณสามารถรับไลบรารีไคลเอ็นต์รวมถึง JDBC สำหรับแพลตฟอร์ม RDBMS ที่สำคัญทั้งหมด

• มุมมองสามารถใช้สำหรับการปรับแต่งต่อผู้ใช้และสร้างขึ้นจากเมตาดาต้าแอปพลิเคชันของคุณ

• มันมีประสิทธิภาพมากกว่าฟิลด์ XML หรือโครงสร้าง EAV อย่างมาก

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

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

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

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

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

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

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