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

เรากำลังมองหาการพัฒนาเครื่องมือในการจับและวิเคราะห์ข้อมูล netflow ซึ่งเราได้รวบรวมจำนวนมหาศาล ในแต่ละวันเราบันทึกเร็กคอร์ดกระแสประมาณ 1.4 พันล้านรายการซึ่งจะมีลักษณะเช่นนี้ในรูปแบบ json:

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

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

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

เรามีการประเมิน couchbase, Cassandra และ mongodb ให้มากที่สุดเท่าที่จะเป็นไปได้สำหรับผู้สมัครสำหรับโครงการนี้อย่างไรก็ตามแต่ละคนเสนอความท้าทายของตนเอง ด้วย couchbase การจัดทำดัชนีจะทำตามช่วงเวลาและไม่ใช่ระหว่างการแทรกข้อมูลดังนั้นมุมมองไม่ทันสมัยดัชนีรองของ Cassandra ไม่ได้มีประสิทธิภาพมากในการส่งคืนผลลัพธ์เนื่องจากโดยทั่วไปแล้วพวกเขาต้องการสแกนกลุ่มทั้งหมดเพื่อผลลัพธ์และ mongodb ดูมีแนวโน้ม แต่ ดูเหมือนว่าจะยากต่อการปรับขนาดเนื่องจากมันเป็น Master / Slave / Sharded ผู้สมัครอื่น ๆ ที่เราวางแผนจะประเมินคือ elasticsearch, mysql (ไม่แน่ใจว่ามันใช้งานได้จริง) และฐานข้อมูลเชิงสัมพันธ์เชิงคอลัมน์ ข้อเสนอแนะใด ๆ หรือประสบการณ์ในโลกแห่งความจริงจะได้รับการชื่นชม

ใน บริษัท ฉันทำงานให้เรากำลังจัดการกับข้อมูลจำนวนใกล้เคียงกัน (ประมาณ 10 TBs ของข้อมูลเรียลไทม์ที่ค้นหาได้) เราแก้ปัญหานี้ด้วย Cassandra และฉันอยากจะพูดถึงแนวคิดสองสามข้อที่จะช่วยให้คุณค้นหา O (1) บนฐานข้อมูลหลาย TB นี่ไม่ใช่เฉพาะกับ Cassandra db แต่คุณสามารถใช้กับฐานข้อมูลอื่นได้เช่นกัน

ทฤษฎี

• แบ่งปันข้อมูลของคุณ ไม่มีทางที่เซิร์ฟเวอร์เดียวจะเชื่อถือปริมาณข้อมูลดังกล่าวได้และเป็นจริง
• เตรียมพร้อมสำหรับความผิดพลาดของฮาร์ดแวร์และความล้มเหลวของโหนดทั้งหมดทำซ้ำข้อมูล
• เริ่มใช้เซิร์ฟเวอร์แบ็คเอนด์มากมายตั้งแต่ต้น
• ใช้เซิร์ฟเวอร์สินค้าโภคภัณฑ์ราคาถูกจำนวนมากเมื่อเทียบกับเซิร์ฟเวอร์ประสิทธิภาพสูงระดับบน
• ตรวจสอบให้แน่ใจว่ามีการกระจายข้อมูลอย่างเท่าเทียมกันทั่วทั้งเศษ
• ใช้เวลาวางแผนคำถามของคุณเป็นจำนวนมาก รับ API จากคิวรีแล้วออกแบบตารางอย่างระมัดระวัง นี่เป็นภารกิจที่สำคัญและยาวนานที่สุด
• ในคาสซานดราคุณสามารถออกแบบคีย์คอลัมน์คอมโพสิตและเข้าถึงคีย์นั้นใน O (1) ใช้เวลาทำงานกับพวกเขา สิ่งนี้จะถูกใช้เพื่อเข้าถึงระเบียนที่ค้นหาได้แทนดัชนีรอง
• ใช้ประโยชน์จากแถวกว้าง มันมีประโยชน์สำหรับการจัดเก็บเหตุการณ์ที่ประทับเวลา
• ห้ามทำการสแกนเต็มรูปแบบหรือในความเป็นจริงการดำเนินการใด ๆ ที่มากกว่า O (Log N) บนโวลุ่มดังกล่าว หากคุณต้องการอะไรมากกว่า O (Log N) ให้ลดการดำเนินการดังกล่าวลงในแผนที่ - ลดอัลกอริทึม

การปฏิบัติ

• อย่าใช้เวลาสร้างอิมเมจระบบปฏิบัติการหรือติดตั้งเซิร์ฟเวอร์บนเครื่องจริง ใช้ผู้ให้บริการบนคลาวด์สำหรับการสร้างต้นแบบอย่างรวดเร็ว ฉันทำงานกับ Amazon EC2 และสามารถแนะนำได้อย่างมากสำหรับความเรียบง่ายความน่าเชื่อถือและความเร็วในการสร้างต้นแบบ
• เครื่อง Windows มักจะทำงานช้าลงในช่วงเวลาบู๊ตเครื่องและใช้ทรัพยากรมากขึ้นในสถานะ Idle พิจารณาใช้ระบบปฏิบัติการที่ใช้ Unix โดยส่วนตัวแล้วฉันพบว่าเซิร์ฟเวอร์ Ubuntu เป็นระบบปฏิบัติการที่เชื่อถือได้ แต่ยิ่งไปกว่านั้นยังมีชุมชนที่ดีมากที่Askubuntu
• คิดเกี่ยวกับระบบเครือข่ายโหนดจะต้องอยู่ติดกันเพื่อให้สามารถนินทาและแลกเปลี่ยนข้อมูลได้อย่างรวดเร็ว
• อย่าเข้าสู่กรณีที่รุนแรง: แถวคอลัมน์กว้างจริง ๆ หรือตระกูลคอลัมน์ที่ยาวเป็นพิเศษ (ตาราง) ประสิทธิภาพที่ดีที่สุดนั้นเกิดขึ้นได้ในขอบเขตของสติ - ถ้า db สนับสนุนการออกแบบแถวNแถวนั้นมันไม่ได้หมายความว่ามันทำงานได้ดี
• การค้นหาของเราใช้เวลาประมาณ 3-5 วินาทีส่วนใหญ่เกิดจากโหนดระดับกลางระหว่าง UI และฐานข้อมูล พิจารณาวิธีที่จะทำให้คำขอเข้าใกล้ฐานข้อมูลมากขึ้น
• ใช้ตัวโหลดบาลานซ์ของเครือข่าย เลือกหนึ่งที่จัดตั้งขึ้น เราใช้ HAProxy ซึ่งง่าย แต่ตายเร็ว ไม่เคยมีปัญหากับมัน
• ชอบความเรียบง่ายถึงโซลูชั่นที่ซับซ้อน
• มองหาโซลูชันโอเพ่นซอร์สฟรีเว้นแต่คุณจะได้รับการสำรองข้อมูลด้วยงบประมาณขนาดของ บริษัท เมื่อคุณไปมากกว่าเซิร์ฟเวอร์หลายเครื่องค่าใช้จ่ายของโครงสร้างพื้นฐานอาจสูงขึ้น

ฉันไม่ทำงานให้กับ Amazon และไม่มีความสัมพันธ์กับทีม HAProxy และ Ubuntu นี่เป็นความเห็นส่วนตัวแทนที่จะเป็นรายการส่งเสริมการขายใด ๆ

ถ้าฉันจะใส่ลงใน SQL Server ฉันจะแนะนำตารางเช่น:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

สิ่งนี้ส่งผลให้เกิดข้อกำหนดการจัดเก็บโดยประมาณทั้งหมดสำหรับตารางเดียวโดยไม่มีดัชนีเพิ่มเติม 5.5 TB สำหรับ 43.2 beeellion records (ข้อกำหนดที่คุณระบุ) ซึ่งจะคำนวณเป็น 130 ไบต์สำหรับตัวข้อมูลเองบวก 7 ไบต์ต่อแถวของค่าใช้จ่ายและเพิ่ม 96 ไบต์ต่อหน้าค่าใช้จ่าย SQL Server เก็บข้อมูลในหน้า 8KB ซึ่งอนุญาตให้ 59 แถวต่อหน้า ซึ่งเท่ากับ 732,203,390 หน้าสำหรับข้อมูลหนึ่งเดือน

SQL Server ชอบเขียนไปยังดิสก์ในกลุ่ม 8 หน้า (64KB) ซึ่งเท่ากับ 472 แถวต่อ I / O จริง ด้วยเร็กคอร์ดการไหลที่สร้างขึ้น 16,203 ทุกวินาทีคุณจะต้องมีอัตรา I / O ขั้นต่ำ 34 IOps รับประกันทุก ๆ วินาที แม้ว่าสิ่งนี้จะไม่มากนัก แต่ I / O อื่น ๆ ในระบบ (SQL Server และอื่น ๆ ) จำเป็นต้องไม่ละเมิดอัตราที่จำเป็นของ IOps ดังนั้นคุณจะต้องออกแบบระบบที่มีความสามารถอย่างน้อยที่สุดตามลำดับของขนาด IOps หรือ 340 แบบต่อเนื่องที่มี IOPS - ฉันคาดว่าคุณจะต้องมีขนาดของคำสั่งที่ 2 ขนาดที่ยั่งยืนยิ่งขึ้นเพื่อรับประกันปริมาณงาน

คุณจะสังเกตเห็นว่าฉันไม่ได้จัดเก็บที่อยู่ IP ในรูปแบบทศนิยมประ สิ่งนี้ช่วยประหยัดพื้นที่เก็บข้อมูลจำนวนมาก (7 ไบต์ต่อที่อยู่) และยังทำให้การจัดทำดัชนีการดึงการเรียงลำดับและการเปรียบเทียบที่อยู่ IP มีประสิทธิภาพมากกว่า ข้อเสียที่นี่คือคุณจำเป็นต้องแปลง IP ที่มีทศนิยมแบบจุดเป็นจำนวนเต็ม 8 ไบต์ก่อนที่จะจัดเก็บและกลับไปเป็น IP แบบจุดทศนิยมเพื่อแสดง รหัสที่จะทำนั้นเป็นเรื่องเล็กน้อย แต่อัตราแถวของคุณนี้จะเพิ่มจำนวนมากของการประมวลผลค่าใช้จ่ายในแต่ละขั้นตอนการไหล - คุณอาจต้องการที่จะทำกระบวนการแปลงนี้บนเครื่องที่แตกต่างกันทางกายภาพจาก SQL Server

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

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

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

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

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

ดังนั้นหากคุณต้องการสอบถามข้อมูลทั้งหมดใน 1.2.3.4 เริ่มตั้งแต่วันที่ 27 มี.ค. เวลา 12.00 น. ถึงวันที่ 27 มี.ค. เวลา 12:01 น. คุณสามารถทำการสแกนแบบช่วงโดยระบุแถวเริ่มและหยุดที่ระบุ

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

กล่าวว่า:

... เราไม่ได้มองข้ามโซลูชันที่เป็นกรรมสิทธิ์สำหรับโครงการนี้

ฉันขอแนะนำให้พิจารณาฐานข้อมูล IBM Informix + TimeSeries datablade ตรงข้ามกับที่บางคนพูดว่า Informix ยังมีชีวิตอยู่และไปได้ดีมาก รุ่นล่าสุดออกวางจำหน่ายเมื่อเดือนที่แล้ว (มีนาคม / 2013 รุ่น 12.10)

TimeSeries เป็นเหมือน "ปลั๊กอิน" (ไม่มีค่าใช้จ่าย) สามารถจัดการกับสถานการณ์เช่นคุณได้
และคุณสามารถใช้ในการผลิตกับฐานข้อมูล Informix ฟรี ( รุ่น Innovator-C ) (นอกหลักสูตรเพียงเพื่อประเมินชิ้นส่วนทางเทคนิคเนื่องจากรุ่นฟรีมีทรัพยากร จำกัด จำนวนมาก)

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

ฉันไม่มีประสบการณ์ส่วนตัวกับ TimeSeriesดังนั้นฉันไม่สามารถตกลงได้ว่าจะเป็น "การแก้ปัญหา" เพียงแค่คำแนะนำในการประเมิน

ฉันสองคำแนะนำเพื่อดู Informix TimeSeries IBM วรรณคดีอ้างว่า TimeSeries สามารถจัดเก็บข้อมูลประเภทนี้ในวันที่ 1 / 5th ของพื้นที่และดำเนินการ 5 ครั้งเร็วเท่าตารางสัมพันธ์

สิทธิประโยชน์เพิ่มเติมจะเป็น Virtual Table Interface ที่สามารถทำให้ข้อมูล TimeSeries ปรากฏเหมือนตารางเชิงสัมพันธ์แบบดั้งเดิมกับผู้ใช้ (ทำให้การพัฒนาแอพพลิเคชั่นง่ายขึ้นในขณะที่ยังได้รับประโยชน์จาก TimeSeries) HA แบบธรรมดาที่ใช้โหนด HDR ซึ่งสนับสนุนข้อมูล TimeSeries ในเวอร์ชั่น 12.1 การรวมข้อมูล TimeSeries เข้ากับ Informix Warehouse Accelerator ที่สามารถใช้เร่งความเร็วรายงานคลังข้อมูลที่ซับซ้อนและความสามารถในการสร้างต้นแบบ TimeSeries solution ใน Informix โดยใช้ Informix Developer หรือ Innovator-C รุ่นฟรี