จัดเก็บข้อมูลที่ดีที่สุดสำหรับหลายพันล้านแถว

ฉันต้องสามารถจัดเก็บข้อมูลขนาดเล็ก (ประมาณ 50-75 ไบต์) สำหรับบันทึกหลายพันล้านรายการ (~ 3 พันล้าน / เดือนต่อปี)

ข้อกำหนดเดียวคือการแทรกอย่างรวดเร็วและการค้นหาอย่างรวดเร็วสำหรับระเบียนทั้งหมดที่มี GUID เดียวกันและความสามารถในการเข้าถึงที่เก็บข้อมูลจาก. net

ฉันเป็นคนที่แต่งตัวประหลาดของเซิร์ฟเวอร์ SQL และฉันคิดว่า SQL Server สามารถทำสิ่งนี้ได้ แต่ด้วยการพูดคุยเกี่ยวกับ BigTable, CouchDB และโซลูชัน nosql อื่น ๆ มันฟังดูเป็นทางเลือกมากกว่า RDBS แบบเดิมอาจดีที่สุดเนื่องจากการเพิ่มประสิทธิภาพสำหรับ แบบสอบถามแบบกระจายและการปรับขนาด ฉันลองคาสแซนดร้าและไลบรารี. net ไม่ได้รวบรวมหรือทั้งหมดอาจมีการเปลี่ยนแปลงทั้งหมด (พร้อมกับคาสซานดราเอง)

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

หากคุณต้องจัดเก็บเร็กคอร์ดขนาดเล็ก 36 พันล้านแผ่นเพื่อให้เข้าถึงได้จาก. net จะเลือกอะไรและเพราะเหตุใด

การจัดเก็บข้อมูล ~ 3.5TB และการแทรกข้อมูลประมาณ 1K / วินาที 24x7 และการสืบค้นในอัตราที่ไม่ได้ระบุไว้เป็นไปได้ด้วย SQL Server แต่มีคำถามเพิ่มเติม:

• สิ่งที่คุณต้องการสำหรับสิ่งนี้? 99.999% uptime หรือ 95% เพียงพอหรือไม่
• คุณมีข้อกำหนดด้านความน่าเชื่อถืออะไรบ้าง? การขาดเม็ดมีดทำให้คุณเสียค่าใช้จ่าย 1 ล้านเหรียญหรือไม่?
• คุณมีข้อกำหนดในการกู้คืนอะไรบ้าง? หากคุณสูญเสียข้อมูลหนึ่งวันมันสำคัญหรือไม่?
• คุณมีข้อกำหนดด้านความสม่ำเสมออะไรบ้าง? จำเป็นต้องรับประกันว่างานเขียนจะปรากฏในการอ่านครั้งต่อไปหรือไม่?

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

เห็นได้ชัดว่าคุณได้ผ่อนคลายข้อกำหนดเหล่านี้บางส่วนแล้ว มีคู่มือภาพที่ดีในการเปรียบเทียบข้อเสนอ nosql ตามกระบวนทัศน์ 'เลือก 2 จาก 3' ที่Visual Guide to NoSQL Systems :

หลังจากอัปเดตความคิดเห็น OP

ด้วย SQL Server สิ่งนี้จะนำไปใช้โดยตรง:

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

การแบ่งพาร์ติชันและการบีบอัดเพจแต่ละครั้งต้องใช้ Enterprise Edition SQL Server ซึ่งจะไม่สามารถใช้งานได้กับ Standard Edition และทั้งสองอย่างมีความสำคัญมากในการตอบสนองความต้องการ

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

นี่คือวิธีที่ฉันจะทำใน SQL Server ข่าวดีก็คือปัญหาที่คุณต้องเผชิญนั้นเป็นที่เข้าใจกันดีและทราบวิธีแก้ปัญหาแล้ว นั่นไม่ได้แปลว่านี่จะดีกว่าสิ่งที่คุณสามารถทำได้ด้วย Cassandra, BigTable หรือ Dynamo ฉันจะให้ใครบางคนที่มีความรู้มากขึ้นในสิ่งที่ไม่มี sql-ish เพื่อโต้แย้งกรณีของพวกเขา

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

ตรงกันข้ามกับความเชื่อที่นิยม NoSQL ไม่ได้เกี่ยวกับประสิทธิภาพหรือแม้แต่ความสามารถในการปรับขนาด ส่วนใหญ่เกี่ยวกับการลดความไม่ตรงกันของ Object-Relational impedance ที่เรียกว่า แต่ยังเกี่ยวกับความสามารถในการปรับขนาดในแนวนอนเทียบกับความสามารถในการปรับขนาดตามแนวตั้งทั่วไปของ RDBMS

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

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

ตัวเลือก NoSQL หลักอื่น ๆ มีการแจกจ่าย Key-Value Stores เช่น BigTable หรือ Cassandra สิ่งเหล่านี้มีประโยชน์อย่างยิ่งหากคุณต้องการปรับขนาดฐานข้อมูลของคุณในหลาย ๆ เครื่องที่ใช้ฮาร์ดแวร์สินค้า พวกเขาทำงานได้ดีบนเซิร์ฟเวอร์ด้วยเช่นกัน แต่อย่าใช้ประโยชน์จากฮาร์ดแวร์ระดับไฮเอนด์เช่นเดียวกับ SQL Server หรือ Oracle หรือฐานข้อมูลอื่น ๆ ที่ออกแบบมาสำหรับการปรับขนาดตามแนวตั้งและเห็นได้ชัดว่าพวกเขาไม่สัมพันธ์กันและไม่ดีสำหรับการบังคับใช้การทำให้เป็นมาตรฐาน หรือข้อ จำกัด ตามที่คุณสังเกตเห็นการสนับสนุน. NET มีแนวโน้มที่จะขาดหายไปในที่สุด

ผลิตภัณฑ์ฐานข้อมูลเชิงสัมพันธ์ทั้งหมดสนับสนุนการแบ่งพาร์ติชันของประเภทที่ จำกัด พวกเขาไม่ยืดหยุ่นเท่า BigTable หรือระบบ DKVS อื่น ๆ พวกเขาไม่แบ่งพาร์ติชันในเซิร์ฟเวอร์หลายร้อยเครื่องได้อย่างง่ายดายแต่มันฟังดูไม่ออกว่าเป็นสิ่งที่คุณกำลังมองหา พวกเขาค่อนข้างดีในการจัดการการบันทึกจำนวนเป็นพันล้านตราบใดที่คุณทำดัชนีและทำให้ข้อมูลเป็นปกติอย่างถูกต้องเรียกใช้ฐานข้อมูลบนฮาร์ดแวร์ที่มีประสิทธิภาพ (โดยเฉพาะ SSD หากคุณสามารถจ่ายได้) และแบ่งพาร์ติชันในดิสก์จริง 2 หรือ 3 หรือ 5 แผ่นหาก จำเป็น

หากคุณมีคุณสมบัติตรงตามเกณฑ์ข้างต้นหากคุณทำงานในสภาพแวดล้อมขององค์กรและมีเงินสำหรับใช้กับฮาร์ดแวร์และการเพิ่มประสิทธิภาพฐานข้อมูลที่เหมาะสมฉันจะใช้ SQL Server ในตอนนี้ หากคุณกำลังจับเหรียญเพนนีและต้องการเรียกใช้สิ่งนี้บนฮาร์ดแวร์คอมพิวเตอร์ระบบคลาวด์ Amazon EC2 ระดับล่างคุณอาจต้องการเลือกใช้ Cassandra หรือ Voldemort แทน (สมมติว่าคุณสามารถทำงานกับ. NET ได้)

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

36 พันล้าน 3 พันล้านต่อเดือนนั่นคือประมาณ 100 ล้านต่อวัน 4.16 ล้านต่อชั่วโมง ~ 70k แถวต่อนาที 1.1k แถวต่อวินาทีเข้าสู่ระบบในลักษณะที่ยั่งยืนเป็นเวลา 12 เดือนโดยสมมติว่าไม่มีเวลาหยุดทำงาน

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

ในแง่ของการจัดเก็บ / เรียกค้นและสิ่งที่ค่อนข้างสำคัญที่คุณไม่ได้กล่าวถึงคืออายุของข้อมูลเก่า - การลบไม่ฟรี

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

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

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

"ฉันต้องสามารถจัดเก็บข้อมูลขนาดเล็ก (ประมาณ 50-75 ไบต์) สำหรับบันทึกหลายพันล้านรายการ (~ 3 พันล้าน / เดือนต่อปี)

ข้อกำหนดเดียวคือการแทรกอย่างรวดเร็วและการค้นหาอย่างรวดเร็วสำหรับระเบียนทั้งหมดที่มี GUID เดียวกันและความสามารถในการเข้าถึงที่เก็บข้อมูลจาก. net "

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

ตารางถูกแบ่งพาร์ติชัน 256 พาร์ติชั่นโปรดทราบว่านี่คือเวอร์ชัน 2005 SQL ... และเราก็ทำตามที่คุณพูดและนั่นคือการจัดเก็บข้อมูลเล็กน้อยโดย GUID และดึงข้อมูลโดย GUID ได้อย่างรวดเร็ว

เมื่อฉันจากไปเรามีบันทึกประมาณ 2-3 พันล้านรายการและการดึงข้อมูลก็ยังค่อนข้างดี (1-2 วินาทีหากผ่าน UI หรือน้อยกว่าหากใช้ RDBMS) แม้ว่านโยบายการเก็บรักษาข้อมูลกำลังจะถูกสร้างอินสแตนซ์ก็ตาม

ดังนั้นเรื่องสั้นสั้น ๆ ฉันเอาถ่านตัวที่ 8 (เช่นอยู่ที่ไหนสักแห่งที่อยู่ตรงกลาง) จากสตริง GUID และ SHA1 แฮชและส่งเป็น int เล็ก ๆ (0-255) และเก็บไว้ในพาร์ติชันที่เหมาะสมและใช้การเรียกฟังก์ชันเดียวกันเมื่อได้รับ ข้อมูลกลับ

ping me ถ้าคุณต้องการข้อมูลเพิ่มเติม ...

บทความต่อไปนี้กล่าวถึงการนำเข้าและการใช้ตาราง16 พันล้านแถวใน Microsoft SQL http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-tablehttp://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table

จากบทความ:

นี่คือเคล็ดลับบางประการจากประสบการณ์ของฉัน:

• ยิ่งคุณมีข้อมูลในตารางที่มีดัชนีคลัสเตอร์ที่กำหนดไว้มากเท่าใดข้อมูลก็จะยิ่งนำเข้าระเบียนที่ไม่ได้เรียงลำดับได้ช้าลงเท่านั้น เมื่อถึงจุดหนึ่งมันช้าเกินไปที่จะใช้งานได้จริง
• หากคุณต้องการส่งออกตารางเป็นไฟล์ที่เล็กที่สุดให้จัดรูปแบบเนทีฟ วิธีนี้ได้ผลดีที่สุดกับตารางที่มีคอลัมน์ตัวเลขเป็นส่วนใหญ่เนื่องจากมีการแสดงในเขตข้อมูลไบนารีอย่างกะทัดรัดมากกว่าข้อมูลอักขระ หากข้อมูลทั้งหมดของคุณเป็นตัวเลขและตัวอักษรคุณจะไม่ได้รับประโยชน์มากนักจากการส่งออกในรูปแบบดั้งเดิม การไม่อนุญาตให้มีค่าว่างในช่องตัวเลขสามารถบีบอัดข้อมูลได้อีก หากคุณอนุญาตให้ฟิลด์เป็นโมฆะการแทนค่าไบนารีของฟิลด์จะมีคำนำหน้า 1 ไบต์เพื่อระบุจำนวนไบต์ของข้อมูลที่จะตามมา
• คุณไม่สามารถใช้ BCP สำหรับระเบียนมากกว่า 2,147,483,647 เนื่องจากตัวแปรตัวนับ BCP เป็นจำนวนเต็ม 4 ไบต์ ฉันไม่พบข้อมูลอ้างอิงใด ๆ เกี่ยวกับเรื่องนี้ใน MSDN หรืออินเทอร์เน็ต หากตารางของคุณประกอบด้วย
  ระเบียนมากกว่า 2,147,483,647 รายการคุณจะต้องส่งออกเป็นชิ้น ๆ
  หรือเขียนกิจวัตรการส่งออกของคุณเอง
• การกำหนดดัชนีคลัสเตอร์บนตารางพรีเติมจะใช้เนื้อที่ดิสก์มาก ในการทดสอบของฉันบันทึกของฉันระเบิดเป็น 10 เท่าของ
  ขนาดตารางเดิมก่อนที่จะเสร็จสมบูรณ์
• เมื่ออิมพอร์ตเร็กคอร์ดจำนวนมากโดยใช้คำสั่ง BULK INSERT ให้รวมพารามิเตอร์ BATCHSIZE และระบุจำนวน
  เร็กคอร์ดที่จะคอมมิตในแต่ละครั้ง หากคุณไม่รวมพารามิเตอร์นี้
  ไฟล์ทั้งหมดของคุณจะถูกนำเข้าเป็นธุรกรรมเดียวซึ่ง
  ต้องใช้พื้นที่บันทึกจำนวนมาก
• วิธีที่เร็วที่สุดในการรับข้อมูลลงในตารางที่มีดัชนีคลัสเตอร์คือการจัดเรียงข้อมูลก่อน จากนั้นคุณสามารถนำเข้าโดยใช้
  คำสั่งBULK INSERT พร้อมกับพารามิเตอร์ ORDER

มีความผิดปกติที่ดูเหมือนจะมองข้ามไป

" โดยทั่วไปหลังจากแทรกแถว 30Mil ในหนึ่งวันฉันจำเป็นต้องดึงข้อมูลแถวทั้งหมดด้วย GUID เดียวกัน (อาจจะ 20 แถว) และต้องแน่ใจว่าจะได้รับคืนทั้งหมด "

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

ฉันมีคำถามเกี่ยวกับการแทรกข้อมูล: มีการแทรกข้อมูลอย่างไร?

• นี่เป็นการแทรกจำนวนมากในตารางเวลาที่แน่นอน (ต่อนาทีต่อชั่วโมง ฯลฯ ) หรือไม่
• ข้อมูลนี้ถูกดึงมาจากแหล่งใด (ไฟล์แบบแบน OLTP ฯลฯ )

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

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

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

ดังนั้น SELECT และโดยเฉพาะอย่างยิ่ง SELECT ที่รวมกันจึงรวดเร็วมาก การโหลดข้อมูลขนาดใหญ่ควรทำด้วยคำสั่ง COPY จากไฟล์ csv ของ Amazon S3 ข้อเสียคือ DELETE และ UPDATE ช้ากว่าปกติ แต่นั่นคือสาเหตุที่ Redshift ไม่ได้เป็นฐานข้อมูลข้ามชาติเป็นหลัก แต่เป็นแพลตฟอร์มคลังข้อมูลมากกว่า

คุณสามารถลองใช้ Cassandra หรือ HBase ได้แม้ว่าคุณจะต้องอ่านวิธีการออกแบบตระกูลคอลัมน์ตามกรณีการใช้งานของคุณ Cassandra มีภาษาแบบสอบถามของตัวเอง แต่คุณต้องใช้ Java APIs ของ HBase เพื่อเข้าถึงข้อมูลโดยตรง หากคุณต้องการใช้ Hbase ฉันขอแนะนำให้ค้นหาข้อมูลด้วย Apache Drill จาก Map-R ซึ่งเป็นโครงการโอเพ่นซอร์ส ภาษาแบบสอบถามของ Drill นั้นสอดคล้องกับ SQL (คำหลักในการเจาะลึกมีความหมายเหมือนกับที่จะมีใน SQL)

ด้วยการบันทึกจำนวนมากต่อปีในที่สุดคุณก็จะหมดพื้นที่ ทำไมไม่จัดเก็บระบบไฟล์เช่น xfs ซึ่งรองรับไฟล์ 2 ^ 64 และใช้กล่องขนาดเล็ก ไม่ว่าผู้คนที่ต้องการได้รับหรือจำนวนเงินจะต้องเสียค่าใช้จ่ายในการสร้างระบบที่มีฐานข้อมูล SQL NoSQL ก็ตาม .. บันทึกจำนวนมากเหล่านี้มักทำโดย บริษัท ไฟฟ้าและสถานีตรวจอากาศ / ผู้ให้บริการเช่นกระทรวงสิ่งแวดล้อมที่ควบคุมขนาดเล็ก สถานีทั่วประเทศ. หากคุณกำลังทำอะไรบางอย่างเช่นการเก็บความดัน .. อุณหภูมิ .. ความเร็วลม .. ความชื้น ฯลฯ ... และแนวทางคือตำแหน่ง.. คุณยังสามารถแบ่งข้อมูลตามปี / เดือน / วัน / ชั่วโมง สมมติว่าคุณเก็บข้อมูล 4 ปีต่อฮาร์ดไดรฟ์ จากนั้นคุณสามารถใช้งานบน Nas ที่มีขนาดเล็กกว่าพร้อมกระจกเงาซึ่งจะให้ความเร็วในการอ่านที่ดีขึ้นและมีจุดยึดหลายจุด .. ตามปีที่สร้าง คุณสามารถสร้างเว็บอินเทอร์เฟซสำหรับการค้นหาได้ดังนั้นการทิ้งสถานที่ 1/2001/06/01 // อุณหภูมิและสถานที่ 1/2545/06/01 // อุณหภูมิจะทิ้งเฉพาะเนื้อหาของอุณหภูมิรายชั่วโมงสำหรับวันที่ 1 ของฤดูร้อนในช่วง 2 ปีนั้น (24 ชม. * 2) ไฟล์ขนาดเล็ก 48 ไฟล์เทียบกับการค้นหาฐานข้อมูลที่มีบันทึกหลายพันล้านรายการและอาจใช้เวลานับล้าน วิธีง่ายๆในการมองสิ่งต่างๆ .. เว็บไซต์ 1.5 พันล้านแห่งในโลกกับพระเจ้ารู้ดีว่าแต่ละหน้ามีกี่หน้าหาก บริษัท อย่าง Google ต้องเสียเงินหลายล้านต่อการค้นหา 3 พันล้านครั้งเพื่อจ่ายเงินให้กับซูเปอร์คอมพิวเตอร์เพื่อสิ่งนี้พวกเขาจะยากจน แต่พวกเขามีค่าไฟ ... คอมพิวเตอร์อึสองสามล้านเครื่อง และดัชนีคาเฟอีน ... พิสูจน์อนาคต.. ให้เพิ่มมากขึ้น. และใช่เมื่อการสร้างดัชนีที่รันโดย SQL นั้นสมเหตุสมผลแล้วการสร้างซูเปอร์คอมพิวเตอร์ที่ยอดเยี่ยมสำหรับงานเส็งเคร็งด้วยสิ่งที่คงที่เช่นสภาพอากาศ ... สถิติและอื่น ๆ เพื่อให้เทคโนโลยีสามารถโม้ระบบของพวกเขา crunches xtb ในเวลา x วินาที ... ไปใช้จ่ายที่อื่น ..

เก็บบันทึกในไฟล์ไบนารีธรรมดาหนึ่งไฟล์ต่อ GUID จะไม่เร็วไปกว่านั้น

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

Sharding ใน MongoDb ยังไม่พร้อมผลิต