ฐานข้อมูลนี้กำลังลุกไหม้...

ให้ฉันเล่าเรื่องทางเทคนิค

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

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


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

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

การออกแบบการซิงค์ทุกวัน

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

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

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

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

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

อันแรกเรียกว่า ฐานข้อมูลเรียลไทม์ Firebaseและที่สอง - Firebase คลาวด์ Firestore. ทั้งสองเป็นผลิตภัณฑ์จาก ชุด Firebase Google. API ของพวกเขาถูกเรียกตามลำดับ firebase.database(…) и firebase.firestore(…).

เรื่องนี้เกิดขึ้นเพราะว่า ฐานข้อมูลเรียลไทม์ - มันเป็นเพียงต้นฉบับ Firebase ก่อนที่จะซื้อโดย Google ในปี 2014 จากนั้น Google จึงตัดสินใจสร้างเป็นผลิตภัณฑ์คู่ขนาน สำเนา Firebase อิงตามบริษัทข้อมูลขนาดใหญ่ และเรียกมันว่า Firestore พร้อมระบบคลาวด์ ฉันหวังว่าคุณจะยังไม่สับสน หากคุณยังคงสับสนไม่ต้องกังวลฉันเขียนบทความนี้ใหม่สิบครั้ง

เพราะคุณต้องระบุ Firebase ในคำถาม Firebase และ ร้านไฟ ในคำถามเกี่ยวกับ Firebase อย่างน้อยก็เพื่อให้คุณเข้าใจเมื่อไม่กี่ปีก่อนเกี่ยวกับ Stack Overflow

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

ชัยชนะแบบไพร์ริก

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

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

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

ที่นี่เราเริ่มเห็นสัญญาณแรกของ raison d'être ของ Firestore ฉันอาจจะผิด แต่ฉันสงสัยว่ามีผู้บริหารระดับสูงของ Google ดูที่ Firebase หลังจากการซื้อ และเพียงพูดว่า "ไม่ โอ้พระเจ้า ไม่" นี่เป็นที่ยอมรับไม่ได้ แค่ไม่อยู่ภายใต้การนำของฉัน”

เขาปรากฏตัวจากห้องของเขาและประกาศว่า:

“เอกสาร JSON ขนาดใหญ่หนึ่งฉบับเหรอ? เลขที่ คุณจะแบ่งข้อมูลออกเป็นเอกสารแยกกัน ซึ่งแต่ละเอกสารจะมีขนาดไม่เกิน 1 เมกะไบต์”

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

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

"อาร์เรย์ของอาร์เรย์ที่สามารถบรรจุองค์ประกอบอื่น ๆ แบบวนซ้ำได้? เลขที่ อาร์เรย์จะมีเฉพาะวัตถุหรือตัวเลขที่มีความยาวคงที่ตามที่พระเจ้าตั้งใจไว้"

ดังนั้นหากคุณหวังที่จะใส่ GeoJSON ลงใน Firestore ของคุณ คุณจะพบว่าเป็นไปไม่ได้ ไม่มีสิ่งใดที่ไม่ใช่มิติเดียวที่ยอมรับได้ ฉันหวังว่าคุณจะชอบ Base64 และ/หรือ JSON ภายใน JSON

“JSON นำเข้าและส่งออกผ่าน HTTP, เครื่องมือบรรทัดคำสั่งหรือแผงผู้ดูแลระบบ? เลขที่ คุณจะสามารถส่งออกและนำเข้าข้อมูลไปยัง Google Cloud Storage เท่านั้น ฉันคิดว่าตอนนี้มันถูกเรียกว่า และเมื่อฉันพูดว่า “คุณ” ฉันแค่พูดถึงผู้ที่มีข้อมูลประจำตัวเจ้าของโครงการเท่านั้น คนอื่นๆ สามารถไปสร้างตั๋วได้"

อย่างที่คุณเห็น โมเดลข้อมูล FireBase นั้นอธิบายได้ง่าย ประกอบด้วยเอกสาร JSON ขนาดใหญ่หนึ่งฉบับที่เชื่อมโยงคีย์ JSON กับเส้นทาง URL ถ้าเขียนด้วย HTTP PUT в / FireBase มีดังต่อไปนี้:

{
  "hello": "world"
}

ที่ GET /hello จะกลับมา "world". โดยพื้นฐานแล้วมันทำงานได้ตรงตามที่คุณคาดหวัง การรวบรวมวัตถุ FireBase /my-collection/:id เทียบเท่ากับพจนานุกรม JSON {"my-collection": {...}} ในรูทซึ่งมีเนื้อหาอยู่ในนั้น /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

วิธีนี้ใช้ได้ผลดีหากเม็ดมีดแต่ละอันมี ID ที่ไม่มีการชนกัน ซึ่งระบบมีโซลูชันมาตรฐานให้

กล่าวอีกนัยหนึ่ง ฐานข้อมูลเข้ากันได้กับ JSON(*) 100% และใช้งานได้ดีกับ HTTP เช่น CouchDB แต่โดยพื้นฐานแล้ว คุณจะใช้มันผ่าน API แบบเรียลไทม์ที่สรุปเว็บซ็อกเก็ต การอนุญาต และการสมัครรับข้อมูล แผงผู้ดูแลระบบมีความสามารถทั้งสองอย่าง ช่วยให้แก้ไขแบบเรียลไทม์และการนำเข้า/ส่งออก JSON หากคุณทำแบบเดียวกันในโค้ดของคุณ คุณจะแปลกใจว่าโค้ดพิเศษจะสูญเปล่าไปมากเพียงใดเมื่อคุณตระหนักว่า JSON แพตช์และส่วนต่างสามารถแก้ปัญหา 90% ของงานประจำในการจัดการสถานะถาวร

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

พวกเขาใช้ฐานข้อมูล NoSQL แบบเรียลไทม์และเปลี่ยนให้เป็นฐานข้อมูลที่ไม่ใช่ SQL ที่ช้าพร้อมการรวมอัตโนมัติและคอลัมน์ที่ไม่ใช่ JSON ที่แยกต่างหาก บางอย่างเช่น GraftQL.

ชวาร้อน

หาก Firestore ควรเชื่อถือได้และปรับขนาดได้มากกว่านี้ สิ่งที่น่าประชดก็คือนักพัฒนาโดยเฉลี่ยจะจบลงด้วยโซลูชันที่น่าเชื่อถือน้อยกว่าการเลือก FireBase ทันที ซอฟต์แวร์ประเภทที่ผู้ดูแลระบบฐานข้อมูล Grumpy ต้องการนั้นต้องใช้ความพยายามและความสามารถในระดับที่ไม่สมจริงสำหรับกลุ่มเฉพาะที่ผลิตภัณฑ์ควรจะทำได้ดี สิ่งนี้คล้ายกับการที่ HTML5 Canvas ไม่สามารถทดแทน Flash ได้เลย หากไม่มีเครื่องมือในการพัฒนาและโปรแกรมเล่น ยิ่งไปกว่านั้น Firestore ยังติดอยู่กับความต้องการความบริสุทธิ์ของข้อมูลและการตรวจสอบความถูกต้องแบบปลอดเชื้อซึ่งไม่สอดคล้องกับวิธีที่ผู้ใช้ทางธุรกิจโดยเฉลี่ย รักที่จะทำงาน: สำหรับเขาทุกอย่างเป็นทางเลือกเพราะทุกอย่างเป็นเพียงแบบร่างจนถึงที่สุด

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

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

ฉันไม่รู้ตรรกะทั้งหมดที่อยู่เบื้องหลังการสร้าง Firestore การคาดเดาถึงแรงจูงใจที่เกิดขึ้นภายในกล่องดำก็เป็นส่วนหนึ่งของความสนุกเช่นกัน การเทียบเคียงกันของฐานข้อมูลสองฐานข้อมูลที่คล้ายกันอย่างยิ่งแต่หาที่เปรียบมิได้นี้ค่อนข้างหายาก เหมือนมีคนคิดว่า: "Firebase เป็นเพียงฟังก์ชันที่เราสามารถจำลองได้ใน Google Cloud"แต่ยังไม่ได้ค้นพบแนวคิดในการระบุข้อกำหนดในโลกแห่งความเป็นจริงหรือการสร้างโซลูชันที่มีประโยชน์ที่ตรงตามข้อกำหนดเหล่านั้นทั้งหมด “ให้นักพัฒนาคิดเกี่ยวกับมัน แค่ทำให้ UI สวยงาม... เพิ่มไฟเพิ่มได้ไหม?”

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

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

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

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

(*) นี่เป็นเรื่องตลกไม่มีสิ่งที่เรียกว่า รองรับ JSON 100%.

เป็นโฆษณา

กำลังมองหา VDS สำหรับการดีบักโครงการ เซิร์ฟเวอร์สำหรับการพัฒนาและการโฮสต์? คุณคือลูกค้าของเราอย่างแน่นอน 🙂 ราคารายวันสำหรับเซิร์ฟเวอร์ที่มีการกำหนดค่าต่างๆ ใบอนุญาตต่อต้าน DDoS และ Windows ได้รวมอยู่ในราคาแล้ว

ที่มา: will.com