วิธีการจัดเก็บ 3 ล้านบันทึกในรูปแบบค่าคีย์?

เราต้องจัดเก็บข้อมูลพื้นฐานประมาณ 3 ล้านผลิตภัณฑ์ ขณะนี้ข้อมูลเป็น CSV ขนาด 180 mb ซึ่งได้รับการอัปเดตรายไตรมาส

จะมีข้อความค้นหาประมาณ 30,000 ต่อวัน แต่ข้อความค้นหาเป็นเพียงการจัดเก็บค่าคีย์ที่ง่ายมาก เราต้องการค้นหา ID ผลิตภัณฑ์และแสดงข้อมูลที่เหลือ (ซึ่งทั้งหมดจะอยู่ในบันทึกเดียว)

สิ่งนี้มีไว้สำหรับเว็บดังนั้นประสิทธิภาพที่รวดเร็วจึงเป็นสิ่งสำคัญ

เราควรใช้ MySQL แม้ว่าเราไม่ต้องการฐานข้อมูลเชิงสัมพันธ์ เราควรสร้างไฟล์ html แบบคงที่ 3 ล้านไฟล์ทุกไตรมาสหรือไม่ เราควรจัดเก็บ CSV หนึ่งบรรทัดสำหรับแต่ละผลิตภัณฑ์ในบางสิ่งเช่น Amazon S3 หรือ Rackspace Cloud Files หรือไม่ วิธีที่ดีที่สุดในการทำเช่นนี้คืออะไร?

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

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

ไม่ว่าคุณจะทำอะไรอย่าสร้างไฟล์สามล้านไฟล์ เราได้เห็นคำถามจำนวนหนึ่งที่นี่เป็นผลมาจากปัญหาที่ไฟล์จำนวนมากสร้างขึ้น

คุณสามารถใช้ชนิดคีย์ - ค่าเฉพาะของฐานข้อมูล NoSQL ซึ่งได้รับการปรับให้เหมาะกับงานประเภทนี้ มองไปที่:

• Redis - Redis เป็นโอเพ่นซอร์สที่เก็บคีย์ - ค่าขั้นสูง มันมักจะเรียกว่าเซิร์ฟเวอร์โครงสร้างข้อมูลเนื่องจากคีย์สามารถมีสตริงแฮชรายการชุดและชุดเรียง
• MemcacheDB - MemcacheDB เป็นระบบการจัดเก็บคีย์ - ค่าแบบกระจายที่ออกแบบมาเพื่อคงอยู่
• อื่น ๆ (หนึ่งในรายการดังกล่าวสามารถพบได้ที่นี่: http://nosql-database.org/ )

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

และตอนนี้สำหรับบางสิ่งที่แตกต่างอย่างสิ้นเชิง:

ได้รับ:

• ผลิตภัณฑ์ 180MB / 3M = 62 ไบต์ / ผลิตภัณฑ์โดยเฉลี่ย
• 30,000 ข้อความค้นหาต่อวัน = 0.34 ข้อความค้นหาต่อวินาที
• อัปเดตรายไตรมาส = ข้อมูลคงที่เป็นหลัก

นอกโซลูชันกล่อง:

ดัมพ์แต่ละผลิตภัณฑ์เป็นระเบียนทรัพยากร TXT และเก็บไว้ใน DNS เช่น:

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

ประโยชน์ที่ได้รับ:

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

สาเหตุที่อาจเป็นความคิดที่ไม่ดี:

• คุณต้องค้นหาข้อมูล (DNS คือการค้นหาคีย์ / ค่าอย่างหมดจด)
• คุณต้องซ่อนข้อมูล (DNS ไม่มีความลับ)

MySQL กับ MyISAM และดัชนีที่ดีบางฟังดูสมบูรณ์แบบสำหรับเรื่องนี้ มีตัวเลือกอื่น ๆ อีกมากมาย แต่ MySQL มีการสนับสนุนอย่างกว้างขวาง (ถ้าไม่ใช่ระดับสากล) ในเว็บโฮสต์เชิงพาณิชย์ ทั้งนี้ขึ้นอยู่กับความเร็วที่คุณต้องการmemcached อาจมีค่าดูแต่โดยไม่ทราบขนาดของคู่คีย์ / ค่าแต่ละคู่การจัดเก็บ 3 ล้านหน่วยในหน่วยความจำอาจเป็นความคิดที่เลวร้ายยิ่งกว่าไฟล์ CSV 180Mb (โอ้เดี๋ยวก่อน ไฟล์ CSV ขนาด 180 เมกะไบต์ดังนั้นเราจึงรู้ว่าไฟล์ใหญ่แค่ไหนพวกเขาจะต้องเป็นคู่ที่ค่อนข้างเล็กดังนั้น memcached อาจจะดีกว่า)

คุณไม่ต้องการไฟล์ HTML แบบคงที่ 3 ล้านไฟล์ซึ่งจะทำให้ระบบไฟล์ของคุณไม่ดี CSV แบบบรรทัดเดียวแม้แต่ใน S3 จะมีปัญหาเดียวกัน ไม่มีใครต้องการไฟล์ 3 ล้านไฟล์ในโฟลเดอร์

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

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

คุณตั้งค่าสถานะคำถามของคุณเป็น amazon S3

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

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

โมเดลข้อมูล SDB คล้ายกับสเปรดชีต

ดูที่นี่สำหรับข้อมูลเพิ่มเติมเกี่ยวกับมัน: http://aws.amazon.com/simpledb/ และรูปแบบข้อมูล: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

แม้ว่าข้อมูล 180mb สามารถจัดการได้อย่างง่ายดายโดยฐานข้อมูลเชิงสัมพันธ์ใด ๆ ฉันขอแนะนำ MongoDB ( http://www.mongodb.org/) เหนือ MySQL, Redis, MemcacheDB และร้านค้าคีย์ - ค่าที่ง่ายกว่าหรือฐานข้อมูลเชิงสัมพันธ์ เหตุผลก็คือสำหรับปัญหาประเภทนี้ MongoDB เป็นระบบที่เร็วที่สุดและใช้งานง่ายที่สุดช่วยให้การอัปเดตแบบไดนามิกที่เร็วและไม่มีข้อ จำกัด สคีมาดังนั้นเอกสารของคุณอาจมีรูปแบบที่แตกต่างกันหากคุณต้องการ ฉันอยู่ที่งานนำเสนอจาก Guardian.co.uk เมื่อวันก่อนและพวกเขาได้ทำการตัดสินใจเชิงนโยบายที่จะห้ามฐานข้อมูลเชิงสัมพันธ์ทั้งหมดและใช้ MongoDB อย่างเต็มที่เพื่อให้บริการข่าวของพวกเขา คุณสามารถรับรู้ได้ว่าเว็บไซต์ของพวกเขารวดเร็วแค่ไหนและออนไลน์ตั้งแต่ปี 1995 (หนังสือพิมพ์ออนไลน์ที่เก่าแก่ที่สุดในสหราชอาณาจักร) พวกเขาได้ผ่านคอขวดทุกประเภทในอดีตเพราะฐานข้อมูลเชิงสัมพันธ์ สำหรับ 180mb นั้น MongoDB จะให้บริการทุกอย่างจากในหน่วยความจำดังนั้นเวลาในการโหลด sub-ms น่าจะเป็นกรณีนี้

จะมีข้อความค้นหาประมาณ 30,000 ต่อวัน แต่ข้อความค้นหาเป็นเพียงการจัดเก็บค่าคีย์ที่ง่ายมาก เราต้องการค้นหา ID ผลิตภัณฑ์และแสดงข้อมูลที่เหลือ (ซึ่งทั้งหมดจะอยู่ในบันทึกเดียว)

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

ฉันกล้าพูดอะไรก็ได้ที่จะทำได้ดี การโหลดของคุณคือ 30,000 คิวรี / วันหมายความว่า (สมมติว่าโหลดของคุณคงที่ตลอดทั้งวัน) คุณมีคิวรีเดียวทุก ๆ 20 วินาที นั่นไม่เลวร้ายเกินไป

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

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

คนอื่น ๆ ได้ชี้ให้เห็นสองตัวเลือกที่สำคัญของคุณ MySQL หรือฐานข้อมูล noSQL

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

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

เกี่ยวกับประสิทธิภาพ: ก่อนหน้านี้ฉันเคยทำงานกับ บริษัท อีคอมเมิร์ซซึ่งเว็บไซต์ได้รับข้อมูลจากเซิร์ฟเวอร์ MySQL มาเป็นเวลานาน เซิร์ฟเวอร์นี้มี RAM 2GB, ฐานข้อมูลโดยรวมอยู่ที่ประมาณ ขนาด 5GB และต่ำกว่าการโหลดบนเซิร์ฟเวอร์จัดการหลายพันแบบสอบถามต่อวินาที ใช่เราได้เพิ่มประสิทธิภาพการสืบค้นจำนวนมาก แต่สิ่งนี้ทำได้จริง