اسان ڏسنداسين ته زبڪس ڪيئن ڪم ڪري ٿو TimescaleDB ڊيٽابيس سان پس منظر جي طور تي. اسان توهان کي ڏيکارينداسين ته ڪيئن شروع کان شروع ڪجي ۽ ڪيئن لڏپلاڻ ڪجي PostgreSQL کان. اسان پڻ مهيا ڪنداسين تقابلي ڪارڪردگي ٽيسٽ ٻن ترتيبن جي.
هاء لوڊ++ سائبيريا 2019. ٽامسڪ هال. 24 جون، 16:00. ٿيسز ۽ . ايندڙ HighLoad++ ڪانفرنس 6 ۽ 7 اپريل 2020 تي سينٽ پيٽرسبرگ ۾ ٿيندي. تفصيل ۽ ٽڪيٽون .
آندري گوشچين (هتي - AG): - مان ھڪڙو ZABBIX ٽيڪنيڪل سپورٽ انجنيئر آھيان (ھاڻي بعد ۾ "Zabbix" جو حوالو ڏنو ويو آھي)، ھڪڙو ٽرينر. مان ٽيڪنيڪل سپورٽ ۾ 6 سالن کان وڌيڪ ڪم ڪري رهيو آهيان ۽ ڪارڪردگي سان سڌو تجربو ڪيو آهي. اڄ آئون ان ڪارڪردگي جي باري ۾ ڳالهائيندس جيڪا TimescaleDB مهيا ڪري سگهي ٿي جڏهن باقاعده PostgreSQL 10 جي مقابلي ۾. انهي سان گڏ، ڪجهه تعارفي حصو انهي بابت ته اهو ڪيئن ڪم ڪري ٿو عام طور تي.
مٿين پيداواري چئلينج: ڊيٽا گڏ ڪرڻ کان ڊيٽا صاف ڪرڻ تائين
شروع ڪرڻ سان، ڪجھ ڪارڪردگي چئلينج آھن جيڪي ھر نگراني سسٽم کي منهن ڏئي ٿو. پهريون پيداواري چئلينج ڊيٽا گڏ ڪرڻ ۽ پروسيسنگ جلدي آهي.
هڪ سٺي مانيٽرنگ سسٽم کي گهرجي ته جلدي، بروقت سمورو ڊيٽا وصول ڪري، ان کي ٽرگر ايڪسپريسشن جي مطابق پروسيس ڪري، يعني ان کي ڪجهه معيارن مطابق پروسيس ڪري (اهو مختلف سسٽم ۾ مختلف آهي) ۽ ان کي ڊيٽابيس ۾ محفوظ ڪرڻ لاءِ ان ڊيٽا کي استعمال ڪرڻ لاءِ. مستقبل
ٻيو ڪارڪردگي چئلينج تاريخ اسٽوريج آهي. ڊيٽابيس ۾ ذخيرو ڪريو اڪثر ۽ انهن ميٽرڪ تائين تڪڙو ۽ آسان رسائي حاصل ڪريو جيڪي وقت جي هڪ عرصي دوران گڏ ڪيا ويا. سڀ کان اهم شيء اها آهي ته هي ڊيٽا حاصل ڪرڻ لاء آسان آهي، ان کي رپورٽن ۾ استعمال ڪريو، گرافس، ٽارگيٽ، ڪجهه حدن جي قيمتن ۾، خبردارين لاء، وغيره.
ٽيون ڪارڪردگي چئلينج تاريخ کي صاف ڪرڻ آهي، اهو آهي، جڏهن توهان ان نقطي تي پهچي ويندا آهيو جتي توهان کي ڪنهن به تفصيلي ميٽرڪ کي ذخيرو ڪرڻ جي ضرورت ناهي جيڪا 5 سالن کان وٺي گڏ ڪئي وئي آهي (مهينن يا ٻن مهينن کان به). ڪجھ نيٽ ورڪ نوڊس ڊهي ويا، يا ڪجھ ھوسٽ، ميٽرڪس جي ھاڻي ضرورت ناھي ڇو ته اھي اڳي ئي پراڻا آھن ۽ ھاڻي گڏ نه ڪيا ويا آھن. اهو سڀ ڪجهه صاف ڪرڻ جي ضرورت آهي ته جيئن توهان جو ڊيٽابيس تمام وڏو نه ٿئي. عام طور تي، تاريخ کي صاف ڪرڻ اڪثر ڪري اسٽوريج لاء هڪ سنگين امتحان آهي - اهو اڪثر ڪري ڪارڪردگي تي تمام گهڻو اثر آهي.
ڪيشنگ مسئلا ڪيئن حل ڪجي؟
مان هاڻي خاص طور تي زيبڪس بابت ڳالهائيندس. Zabbix ۾، پهرين ۽ سيڪنڊ ڪالون ڪيشنگ استعمال ڪندي حل ڪيا ويا آهن.
ڊيٽا گڏ ڪرڻ ۽ پروسيسنگ - اسان هن سڀني ڊيٽا کي ذخيرو ڪرڻ لاء رام استعمال ڪندا آهيون. اهي ڊيٽا هاڻي وڌيڪ تفصيل سان بحث ڪيو ويندو.
انهي سان گڏ ڊيٽابيس جي پاسي تي مکيه چونڊ لاء ڪجهه ڪيشنگ آهي - گرافس ۽ ٻين شين لاء.
پاڻ Zabbix سرور جي پاسي تي ڪيشنگ: اسان وٽ آهي ConfigurationCache، ValueCache، HistoryCache، TrendsCache. هي ڇا آهي؟
ConfigurationCache مکيه ڪيش آهي جنهن ۾ اسان ميٽرڪ، ميزبان، ڊيٽا شيون، ٽرگرز کي ذخيرو ڪندا آهيون. سڀڪنھن شيء کي توھان کي پروسيسنگ جي پروسيسنگ جي ضرورت آھي، ڊيٽا گڏ ڪرڻ، ڪھڙي ميزباني کان گڏ ڪرڻ، ڪھڙي فريڪوئنسي سان. اهو سڀ ڪجهه ConfigurationCache ۾ محفوظ ڪيو ويو آهي ته جيئن ڊيٽابيس ڏانهن نه وڃو ۽ غير ضروري سوالن کي ٺاهي. سرور شروع ٿيڻ کان پوء، اسان هن ڪيش کي تازه ڪاري ڪريون ٿا (ان کي ٺاهيو) ۽ ان کي وقتي طور تي اپڊيٽ ڪيو (منحصر ترتيب جي سيٽنگن تي).
Zabbix ۾ ڪيشنگ. ڊيٽا گڏ ڪرڻ
هتي ڊراگرام تمام وڏو آهي:
اسڪيم ۾ مکيه اھي آھن جمع ڪندڙ:
اهي خود اسيمبليءَ جا عمل آهن، مختلف ”پولرز“ جيڪي مختلف قسم جي اسيمبلين جا ذميوار هوندا آهن. اهي icmp، ipmi، ۽ مختلف پروٽوڪول ذريعي ڊيٽا گڏ ڪن ٿا ۽ ان کي سڀني کي پري پروسيسنگ ڏانهن منتقل ڪن ٿا.
اڳي پروسيسنگ تاريخ ڪيچ
انهي سان گڏ، جيڪڏهن اسان وٽ ڊيٽا عنصرن جو ڳڻپ ڪيو آهي (جيڪي Zabbix کان واقف آهن ڄاڻن ٿا)، اهو آهي، حساب ڪيل، مجموعي ڊيٽا عناصر، اسان انهن کي سڌو سنئون ValueCache مان وٺون ٿا. مان توهان کي ٻڌايان ٿو ته اهو ڪيئن ڀريو ويو آهي بعد ۾. اهي سڀئي جمع ڪندڙ ConfigurationCache استعمال ڪن ٿا پنهنجون نوڪريون حاصل ڪرڻ لاءِ ۽ پوءِ انهن کي پري پروسيسنگ ڏانهن منتقل ڪن ٿا.
پري پروسيسنگ پڻ استعمال ڪري ٿو ConfigurationCache اڳي پروسيسنگ مرحلن کي حاصل ڪرڻ لاءِ ۽ هن ڊيٽا کي مختلف طريقن سان پروسيس ڪري ٿو. ورجن 4.2 کان شروع ڪندي، اسان ان کي پراڪسي ڏانھن منتقل ڪيو آھي. اهو تمام آسان آهي، ڇاڪاڻ ته اڳ پروسيسنگ پاڻ هڪ بلڪه ڏکيو آپريشن آهي. ۽ جيڪڏهن توهان وٽ هڪ تمام وڏو زيبڪس آهي، وڏي تعداد ۾ ڊيٽا عناصر ۽ هڪ اعلي گڏ ڪرڻ جي تعدد سان، پوء اهو ڪم کي تمام آسان بڻائي ٿو.
ان مطابق، اسان هن ڊيٽا کي ڪنهن طريقي سان پروسيس ڪرڻ کان پوءِ پري پروسيسنگ استعمال ڪندي، اسان ان کي اڳتي پروسيس ڪرڻ لاءِ HistoryCache ۾ محفوظ ڪريون ٿا. هي ڊيٽا گڏ ڪرڻ جو نتيجو آهي. اسان مکيه عمل ڏانهن وڃو.
تاريخ جي هم وقت سازي جو ڪم
Zabbix ۾ مکيه عمل (جيئن ته اهو هڪ monolithic فن تعمير آهي) تاريخ هم وقت سازي آهي. اهو بنيادي عمل آهي جيڪو خاص طور تي هر ڊيٽا عنصر جي ايٽمي پروسيسنگ سان تعلق رکي ٿو، اهو آهي، هر قيمت:
- قدر اچي ٿو (اهو ان کي HistoryCache کان وٺي ٿو)؛
- چيڪ ڪنفيگريشن جي هم وقت سازي ۾: ڇا ڪي ڳڻپ لاءِ ڪي محرڪ آھن - انھن کي ڳڻائي ٿو؛
جيڪڏهن اتي آهي - واقعا پيدا ڪري ٿو، خبرداري پيدا ڪرڻ لاءِ واڌارو پيدا ڪري ٿو، جيڪڏهن ضروري هجي ته ترتيب جي مطابق؛ - ايندڙ پروسيسنگ لاءِ رڪارڊ ٽرگرز، گڏ ڪرڻ؛ جيڪڏهن توهان گذريل ڪلاڪ وغيره تي مجموعي طور تي، هي قيمت ValueCache طرفان ياد رکي ويندي آهي ته جيئن تاريخ جي ٽيبل تي نه وڃو؛ اهڙيء طرح، ValueCache ضروري ڊيٽا سان ڀريو ويو آهي جيڪو ڳڻڻ لاء ضروري آهي ٽريگرز، ڳڻپيوڪر عناصر، وغيره.
- پوء تاريخ جي هم وقت سازي سڀني ڊيٽا کي ڊيٽابيس ۾ لکي ٿو؛
- ڊيٽابيس انهن کي ڊسڪ تي لکي ٿو - هي اهو آهي جتي پروسيسنگ جو عمل ختم ٿئي ٿو.
ڊيٽابيس. ڪيشنگ
ڊيٽابيس جي پاسي تي، جڏهن توهان گراف ڏسڻ چاهيو ٿا يا واقعن تي ڪجهه رپورٽون، اتي مختلف ڪيش آهن. پر هن رپورٽ ۾ مان انهن بابت نه ڳالهائيندس.
MySQL لاءِ هتي آهي Innodb_buffer_pool، ۽ مختلف ڪيش جو هڪ گروپ جيڪو پڻ ترتيب ڏئي سگهجي ٿو.
پر اهي مکيه آهن:
- حصيداري_بفرز؛
- موثر_ڪيش_سائز؛
- حصيداري_پول.
سڀني ڊيٽابيسن لاءِ، مون چيو ته ڪي ڪيش آهن جيڪي توهان کي رام ۾ ذخيرو ڪرڻ جي اجازت ڏين ٿيون ڊيٽا جيڪا اڪثر سوالن لاءِ گهربل هوندي آهي. ان لاءِ انهن وٽ پنهنجون ٽيڪنالاجيون آهن.
ڊيٽابيس جي ڪارڪردگي بابت
انهي جي مطابق، هڪ مقابلي واري ماحول آهي، اهو آهي، زيبڪس سرور ڊيٽا گڏ ڪري ٿو ۽ ان کي رڪارڊ ڪري ٿو. جڏهن ٻيهر شروع ڪيو ويو، اهو پڻ تاريخ مان پڙهي ٿو ValueCache ۽ انهي کي ڀرڻ لاءِ. هتي توهان وٽ اسڪرپٽ ۽ رپورٽون آهن جيڪي استعمال ڪن ٿيون Zabbix API، جيڪو ويب انٽرفيس تي ٺهيل آهي. Zabbix API ڊيٽابيس ۾ داخل ٿئي ٿو ۽ گرافس، رپورٽون، يا واقعن جي ڪجهه قسم جي فهرست حاصل ڪرڻ لاء ضروري ڊيٽا حاصل ڪري ٿو، تازو مسئلا.
پڻ هڪ تمام مشهور بصري حل آهي گرافانا، جيڪو اسان جا صارف استعمال ڪندا آهن. Zabbix API ۽ ڊيٽابيس ذريعي سڌو سنئون لاگ ان ٿيڻ جي قابل. اهو پڻ ڊيٽا حاصل ڪرڻ لاءِ هڪ خاص مقابلو پيدا ڪري ٿو: نتيجن ۽ ٽيسٽ جي تيز ترسيل سان عمل ڪرڻ لاءِ ڊيٽابيس جي هڪ بهتر ، بهتر ٽيوننگ جي ضرورت آهي.
تاريخ کي صاف ڪرڻ. زيبڪس وٽ هائوس ڪيپر آهي
ٽيون ڪال جيڪو زبڪس ۾ استعمال ڪيو ويو آهي هائوس ڪيپر استعمال ڪندي تاريخ کي صاف ڪري رهيو آهي. گهر سنڀاليندڙ سڀني سيٽنگن جي پيروي ڪري ٿو، اهو آهي، اسان جي ڊيٽا عناصر ظاهر ڪن ٿا ته ڪيترو وقت اسٽوريج (ڏينهن ۾)، ڪيتري وقت تائين اسٽوري رجحانات، ۽ تبديلين جي متحرڪ.
مون TrendCache جي باري ۾ نه ڳالهايو، جيڪو اسان پرواز تي ڳڻپ ڪريون ٿا: ڊيٽا اچي ٿي، اسان ان کي هڪ ڪلاڪ لاءِ گڏ ڪريون ٿا (اڪثر ڪري اهي انگ آخري ڪلاڪ لاءِ آهن)، رقم اوسط/ گھٽ ۾ گھٽ آهي ۽ اسان ان کي هڪ ڪلاڪ ۾ هڪ ڀيرو رڪارڊ ڪريون ٿا. تبديلين جي متحرڪ جي جدول ("رجحان"). "هائوس ڪيپر" شروع ٿئي ٿو ۽ ڊيٽابيس مان ڊيٽا کي حذف ڪري ٿو باقاعده چونڊون استعمال ڪندي، جيڪو هميشه اثرائتو ناهي.
ڪيئن سمجھڻ لاء ته اهو غير موثر آهي؟ توھان ھيٺ ڏنل تصوير ڏسي سگھو ٿا اندروني عملن جي ڪارڪردگي گراف تي.
توهان جي تاريخ جي هم وقت سازي مسلسل مصروف آهي (لال گراف). ۽ "ڳاڙهو" گراف جيڪو مٿي تي وڃي ٿو. هي هڪ "هائوسڪيپر" آهي جيڪو شروع ٿئي ٿو ۽ ڊيٽابيس جي انتظار ۾ آهي ته سڀني قطارن کي حذف ڪرڻ لاءِ جيڪي هن بيان ڪيون آهن.
اچو ته ڪجھ آئٽم ID وٺون: توھان کي ختم ڪرڻ جي ضرورت آھي آخري 5 ھزار؛ يقينا، انگن اکرن ذريعي. پر عام طور تي ڊيٽا سيٽ تمام وڏو آهي - ڊيٽابيس اڃا تائين ان کي ڊسڪ مان پڙهي ٿو ۽ ان کي ڪيش ۾ وجهي ٿو، ۽ اهو ڊيٽابيس لاء تمام قيمتي آپريشن آهي. ان جي سائيز تي مدار رکندي، اهو ٿي سگهي ٿو ڪجهه ڪارڪردگي جي مسئلن کي.
توھان آسان طريقي سان گھر جي سنڀاليندڙ کي غير فعال ڪري سگھو ٿا - اسان وٽ ھڪڙو واقف ويب انٽرفيس آھي. ايڊمنسٽريشن جنرل ۾ سيٽنگون (جي سيٽنگون ”هاؤس ڪيپر“ لاءِ) اسان اندروني تاريخ ۽ رجحانن لاءِ اندروني گھر جي سنڀال کي بند ڪريون ٿا. ان جي مطابق، گهر سنڀاليندڙ هاڻي هن تي ڪنٽرول نه ڪندو آهي:
توهان اڳتي ڇا ڪري سگهو ٿا؟ توهان ان کي بند ڪيو، توهان جا گراف برابر ٿي ويا آهن... هن معاملي ۾ وڌيڪ مسئلا پيدا ٿي سگهن ٿا؟ ڇا مدد ڪري سگهي ٿو؟
ورهاڱي (سيڪشن)
عام طور تي هي ترتيب ڏنل آهي مختلف طريقي سان هر تعلقي ڊيٽابيس تي جيڪو مون درج ڪيو آهي. MySQL جي پنهنجي ٽيڪنالاجي آهي. پر مجموعي طور تي اهي تمام گهڻا آهن جڏهن اهو اچي ٿو PostgreSQL 10 ۽ MySQL. يقينن، ڪيترا ئي اندروني اختلاف آهن ته اهو سڀ ڪيئن لاڳو ٿئي ٿو ۽ اهو سڀ ڪجهه ڪارڪردگي کي ڪيئن متاثر ڪري ٿو. پر عام طور تي، نئين ورهاڱي جي پيدائش اڪثر ڪري ڪجهه مسئلن جي ڪري ٿي.
توهان جي سيٽ اپ تي منحصر آهي (توهان هڪ ڏينهن ۾ ڪيترو ڊيٽا ٺاهي رهيا آهيو)، اهي عام طور تي گهٽ ۾ گهٽ مقرر ڪن ٿا - اهو 1 ڏينهن / بيچ آهي، ۽ "رجحان" لاء، تبديلين جي متحرڪ - 1 مهينو / نئين بيچ. اھو تبديل ٿي سگھي ٿو جيڪڏھن توھان وٽ ھڪڙو وڏو سيٽ اپ آھي.
اچو ته سيٽ اپ جي سائيز بابت فوري طور تي چوندا آهن: في سيڪنڊ 5 هزار نيون ويلز تائين (نام نهاد nvps) - اهو هڪ ننڍڙو "سيٽ اپ" سمجهيو ويندو. سراسري - في سيڪنڊ کان 5 کان 25 هزار قدر. مٿيون سڀ شيون اڳ ۾ ئي وڏيون ۽ تمام وڏيون تنصيب آهن جيڪي ڊيٽابيس جي تمام محتاط ترتيب جي ضرورت هونديون آهن.
تمام وڏي تنصيب تي، 1 ڏينهن بهتر نه ٿي سگھي. مون ذاتي طور تي MySQL تي 40 گيگا بائيٽ في ڏينهن جا حصا ڏٺا آهن (۽ ٿي سگهي ٿو وڌيڪ). هي ڊيٽا جو هڪ تمام وڏو مقدار آهي، جيڪو ڪجهه مسئلا پيدا ڪري سگهي ٿو. ان کي گهٽائڻ جي ضرورت آهي.
توهان کي ورهاڱي جي ضرورت ڇو آهي؟
ڇا ورهاڱي مهيا ڪري ٿو، منهنجو خيال آهي ته هرڪو ڄاڻي ٿو، ٽيبل ورهاڱي آهي. گهڻو ڪري اهي ڊسڪ ۽ اسپان جي درخواستن تي الڳ فائلون آهن. اهو هڪ ورهاڱي کي وڌيڪ بهتر طور تي چونڊيندو آهي جيڪڏهن اهو عام ورهاڱي جو حصو آهي.
Zabbix لاء، خاص طور تي، اهو استعمال ڪيو ويندو آهي رينج طرفان، حد جي لحاظ سان، اهو آهي، اسان هڪ ٽائم اسٽيمپ استعمال ڪندا آهيون (هڪ باقاعده نمبر، وقت جي شروعات کان وٺي). توھان بيان ڪريو ڏينھن جي شروعات/ڏينھن جي پڇاڙي، ۽ اھو آھي ورهاڱو. ان مطابق، جيڪڏهن توهان ڊيٽا لاء پڇي رهيا آهيو ته ٻه ڏينهن پراڻي آهي، هر شيء کي ڊيٽابيس مان تيزيء سان حاصل ڪيو ويندو آهي، ڇو ته توهان کي صرف هڪ فائل کي ڪيش ۾ لوڊ ڪرڻ ۽ ان کي واپس ڪرڻ جي ضرورت آهي (بجائي وڏي ٽيبل جي).
ڪيترائي ڊيٽابيس پڻ داخل ڪرڻ کي تيز ڪن ٿا (هڪ ٻار جي ٽيبل ۾ داخل ڪرڻ). مان هن وقت لاءِ خلاصو ڳالهائي رهيو آهيان، پر اهو پڻ ممڪن آهي. تقسيم اڪثر ڪري مدد ڪري ٿي.
NoSQL لاءِ لچڪدار ڳولها
تازو، 3.4 ۾، اسان هڪ NoSQL حل لاڳو ڪيو. Elasticsearch ۾ لکڻ جي صلاحيت شامل ڪئي وئي. توھان ڪجھھ قسم لکي سگھو ٿا: توھان چونڊيو - يا ته لکو نمبر يا ڪجھ نشانيون؛ اسان وٽ اسٽرنگ ٽيڪسٽ آھي، توھان لاگ لکي سگھوٿا Elasticsearch تي... ان مطابق، ويب انٽرفيس به Elasticsearch تائين پھچندو. اهو ڪجهه ڪيسن ۾ عظيم ڪم ڪري ٿو، پر هن وقت اهو استعمال ڪري سگهجي ٿو.
ٽائيم اسڪيل ڊي بي. هائپر ٽيبل
4.4.2 لاءِ اسان هڪ شيءِ تي ڌيان ڏنو جهڙوڪ TimescaleDB. هي ڇا آهي؟ هي PostgreSQL لاءِ هڪ واڌارو آهي، اهو آهي، اهو هڪ ڏيهي PostgreSQL انٽرفيس آهي. ان سان گڏ، هي واڌارو توهان کي ٽائيم سيريز ڊيٽا سان تمام گهڻو ڪم ڪرڻ جي اجازت ڏئي ٿو ۽ خودڪار ورهاڱي سان. اهو ڇا ڏسڻ ۾ اچي ٿو:
هي هائپر ٽيبل آهي - ٽائم اسڪيل ۾ اهڙو تصور آهي. هي هڪ هائپر ٽيبل آهي جيڪو توهان ٺاهيندا آهيو، ۽ ان ۾ ٽڪر شامل آهن. ٽڪڙا ورهاڱي وارا آهن، اهي ٻار ٽيبل آهن، جيڪڏهن مان غلط نه آهيان. اهو واقعي اثرائتو آهي.
TimescaleDB ۽ PostgreSQL
جيئن ته TimescaleDB ٺاهيندڙن کي يقين ڏياريو، اهي پروسيسنگ سوالن لاء هڪ وڌيڪ صحيح الورورٿم استعمال ڪندا آهن، خاص طور تي داخلن ۾، جيڪو انهن کي ڊيٽا سيٽ داخل ڪرڻ جي وڌندڙ سائيز سان لڳ ڀڳ مسلسل ڪارڪردگي جي اجازت ڏئي ٿو. اهو آهي، پوسٽ گريس جي 200 ملين قطارن کان پوء، معمولي هڪ تمام گهڻو ساڙڻ شروع ٿئي ٿو ۽ ڪارڪردگي لفظي طور تي صفر تائين وڃائي ٿو، جڏهن ته ٽائم اسڪيل توهان کي ڊيٽا جي ڪنهن به مقدار سان ممڪن طور تي موثر طور تي داخل ڪرڻ جي اجازت ڏئي ٿو.
TimescaleDB کي ڪيئن انسٽال ڪجي؟ اهو سادو آهي!
اهو دستاويزن ۾ آهي، اهو بيان ڪيو ويو آهي - توهان ان کي انسٽال ڪري سگهو ٿا ڪنهن به پيڪيجز مان... اهو منحصر آهي سرڪاري پوسٽ گريس پيڪيجز تي. هٿ سان گڏ ڪري سگهجي ٿو. اهو ائين ٿيو ته مون کي ڊيٽابيس لاءِ گڏ ڪرڻو پيو.
Zabbix تي اسان صرف Extention کي چالو ڪندا آهيون. منهنجو خيال آهي ته اهي جيڪي پوسٽ گريس ۾ Extention استعمال ڪندا آهن... توهان صرف Extention کي ايڪٽيويٽ ڪريو، ان کي Zabbix ڊيٽابيس لاءِ ٺاهيو جيڪو توهان استعمال ڪري رهيا آهيو.
۽ آخري قدم ...
ٽائيم اسڪيل ڊي بي. تاريخ جي جدولن جي لڏپلاڻ
توهان کي هڪ هائپر ٽيبل ٺاهڻ جي ضرورت آهي. هن لاء هڪ خاص فنڪشن آهي - هائپر ٽيبل ٺاهيو. ان ۾، پهريون پيٽرولر ٽيبل آهي جيڪو هن ڊيٽابيس ۾ گهربل آهي (جنهن لاء توهان کي هائپر ٽيبل ٺاهڻ جي ضرورت آهي).
فيلڊ جنهن جي ذريعي ٺاهيو وڃي ٿو، ۽ chunk_time_interval (هي chunks جو وقفو آهي (جنهن کي استعمال ڪرڻ جي ضرورت آهي). 86 هڪ ڏينهن آهي.
Migrate_data parameter: جيڪڏھن توھان داخل ڪريو سچ ۾، پوء اھو سڀ موجوده ڊيٽا کي اڳ ۾ ٺاھيل حصن ڏانھن منتقل ڪندو.
مون پاڻ استعمال ڪيو آهي migrate_data - اهو ڪافي وقت وٺندو آهي، ان تي منحصر آهي ته توهان جو ڊيٽابيس ڪيترو وڏو آهي. مون وٽ هڪ ٽيرا بائيٽ کان وڌيڪ هئي - ان کي ٺاهڻ ۾ هڪ ڪلاڪ کان وڌيڪ وقت ورتو. ڪجهه حالتن ۾، جاچ دوران، مون ٽيڪسٽ (history_text) ۽ اسٽرنگ (history_str) لاءِ تاريخي ڊيٽا حذف ڪري ڇڏيا ته جيئن انهن کي منتقل نه ڪيو وڃي - اهي واقعي مون لاءِ دلچسپ نه هئا.
۽ اسان پنهنجي db_extention ۾ آخري تازه ڪاري ڪريون ٿا: اسان انسٽال ڪريون ٿا timescaledb ته جيئن ڊيٽابيس ۽ خاص طور تي، اسان جو زيبڪس سمجهي ته اتي db_extention آهي. هو ان کي چالو ڪري ٿو ۽ ڊيٽابيس ۾ صحيح نحو ۽ سوالن کي استعمال ڪري ٿو، انهن "فيچرز" کي استعمال ڪندي جيڪي TimescaleDB لاءِ ضروري آهن.
سرور جي ترتيب
مون ٻه سرور استعمال ڪيا. پهريون سرور هڪ تمام ننڍڙي ورچوئل مشين، 20 پروسيسر، 16 گيگا بائيٽ ريم آهي. مون ان تي پوسٽ گريس 10.8 ترتيب ڏني:
آپريٽنگ سسٽم ڊيبين هو، فائيل سسٽم xfs هو. مون هن خاص ڊيٽابيس کي استعمال ڪرڻ لاءِ گهٽ ۾ گهٽ سيٽنگون ڪيون، مائنس جيڪو زبڪس پاڻ استعمال ڪندو. ساڳي مشين تي ھڪڙو Zabbix سرور، PostgreSQL ۽ لوڊ ايجنٽ ھو.
مون 50 فعال ايجنٽ استعمال ڪيا آھن جيڪي LoadableModule استعمال ڪن ٿا جلدي مختلف نتيجا پيدا ڪرڻ لاءِ. اھي اھي آھن جن ٺاھيا تار، انگ، وغيره. مون ڊيٽابيس کي تمام گھڻي ڊيٽا سان ڀريو. شروعات ۾، ٺاھ جوڙ ۾ 5 ھزار ڊيٽا عناصر في ھوسٽ تي مشتمل ھو، ۽ لڳ ڀڳ ھر ڊيٽا عنصر ۾ ھڪ ٽرگر ھو - انھيءَ لاءِ ھڪ حقيقي سيٽ اپ ٿيڻ لاءِ. ڪڏهن ڪڏهن توهان کي استعمال ڪرڻ لاء هڪ کان وڌيڪ ٽرڪ جي ضرورت هوندي آهي.
مون اپڊيٽ وقفو ۽ لوڊ پاڻ کي منظم ڪيو نه صرف 50 ايجنٽ استعمال ڪندي (وڌيڪ شامل ڪرڻ)، پر پڻ استعمال ڪندي متحرڪ ڊيٽا عناصر ۽ اپڊيٽ جي وقفي کي 4 سيڪنڊن تائين گھٽائڻ.
ڪارڪردگي ٽيسٽ. PostgreSQL: 36 هزار NVPs
پهرين لانچ، پهرين سيٽ اپ مون وٽ هئي خالص پوسٽري ايس ايس ايل 10 هن هارڊويئر تي (في سيڪنڊ 35 هزار قيمتون). عام طور تي، جيئن توهان اسڪرين تي ڏسي سگهو ٿا، ڊيٽا داخل ڪرڻ هڪ سيڪنڊ جو حصو وٺندو آهي - هر شيء سٺو ۽ تيز آهي، ايس ايس ڊي ڊرائيو (200 گيگا بائيٽ). رڳو اها ڳالهه آهي ته 20 GB تمام جلدي ڀري ٿو.
مستقبل ۾ اهڙا ڪيترائي گراف هوندا. هي هڪ معياري زيبڪس سرور ڪارڪردگي ڊيش بورڊ آهي.
پهريون گراف في سيڪنڊ جي قيمتن جو تعداد آهي (نيرو، مٿي کاٻي پاسي)، هن صورت ۾ 35 هزار قدر. هي (مٿين مرڪز) تعميراتي عملن جي لوڊشيڊنگ آهي، ۽ هي (مٿي ساڄي) اندروني عملن جي لوڊشيڊنگ آهي: تاريخ جي هم وقت سازي ۽ هائوس ڪيپر، جيڪو هتي (هيٺيان مرڪز) ڪافي عرصي کان هلي رهيو آهي.
هي گراف (هيٺيان مرڪز) ڏيکاري ٿو ValueCache استعمال - ڪيترا ValueCache ٽاريندڙن لاءِ (ڪيترن هزار قيمتون في سيڪنڊ). ٻيو اهم گراف چوٿون هڪ آهي (هيٺيان کاٻي پاسي)، جيڪو ڏيکاري ٿو HistoryCache جو استعمال، جنهن بابت مون ڳالهايو، جيڪو ڊيٽابيس ۾ داخل ڪرڻ کان اڳ هڪ بفر آهي.
ڪارڪردگي ٽيسٽ. PostgreSQL: 50 هزار NVPs
اڳيون، مون ساڳئي هارڊويئر تي 50 هزار ويلز في سيڪنڊ تائين لوڊ وڌايو. جڏهن هائوس ڪيپر طرفان لوڊ ڪيو ويو، حساب سان 10-2 سيڪنڊن ۾ 3 هزار ويلز رڪارڊ ڪيا ويا. ڇا، حقيقت ۾، هيٺ ڏنل اسڪرين شاٽ ۾ ڏيکاريل آهي:
”هائوس ڪيپر“ اڳ ۾ ئي ڪم ۾ مداخلت ڪرڻ شروع ڪري چڪو آهي، پر عام طور تي، تاريخ جي سڪائڻ وارن تي بار اڃا 60 سيڪڙو جي سطح تي آهي (ٽيون گراف، مٿي ساڄي). تاريخ ڪيچ اڳ ۾ ئي فعال طور تي ڀرڻ شروع ٿئي ٿو جڏهن هائوس ڪيپر هلائي رهيو آهي (هيٺ کاٻي پاسي). اهو اٽڪل اڌ گيگا بائيٽ هو، 20 سيڪڙو پورو.
ڪارڪردگي ٽيسٽ. PostgreSQL: 80 هزار NVPs
ان کان پوء مون ان کي وڌايو 80 هزار قدر في سيڪنڊ تائين:
اهو لڳ ڀڳ 400 هزار ڊيٽا عناصر، 280 هزار ٽارگيٽ هئا. داخل ڪريو، جيئن توهان ڏسي سگهو ٿا، تاريخ جي ٻوٽن جي لوڊ جي لحاظ کان (انهن مان 30 هئا) اڳ ۾ ئي تمام گهڻو هو. ان کان پوء مون مختلف پيرا ميٽرز کي وڌايو: History sinkers، cache... هن هارڊويئر تي، تاريخ sinkers تي لوڊ وڌ ۾ وڌ وڌڻ شروع ڪيو، تقريبا "شيلف تي" - ان جي مطابق، HistoryCache تمام گهڻو لوڊ ٿي ويو:
هن سڄي وقت مون سڀني سسٽم جي پيٽرولن جي نگراني ڪئي (ڪيئن پروسيسر استعمال ڪيو ويندو آهي، ريم) ۽ دريافت ڪيو ته ڊسڪ جو استعمال وڌ ۾ وڌ هو - مون هن هارڊويئر تي، هن ورچوئل مشين تي هن ڊسڪ جي وڌ ۾ وڌ گنجائش حاصل ڪئي. "پوسٽ گريس" ايتري شدت سان ڊيٽا کي ڪافي طور تي ڊمپ ڪرڻ شروع ڪيو، ۽ ڊسڪ کي هاڻي لکڻ، پڙهڻ جو وقت نه هو ...
مون هڪ ٻيو سرور ورتو جنهن ۾ اڳ ۾ ئي 48 پروسيسر ۽ 128 گيگا بائيٽ ريم هئا:
مون ان کي پڻ "ٽيون" ڪيو - تاريخ جي هم وقت ساز (60 ٽڪرا) نصب ڪيو ۽ قابل قبول ڪارڪردگي حاصل ڪئي. حقيقت ۾، اسان "شيلف تي" نه آهيون، پر اهو شايد پيداوار جي حد آهي، جتي ان بابت ڪجهه ڪرڻ ضروري آهي.
ڪارڪردگي ٽيسٽ. ٽائم اسڪيل ڊي بي: 80 هزار NVPs
منهنجو مکيه ڪم استعمال ڪرڻ هو TimescaleDB. هر گراف هڪ ڊپ ڏيکاري ٿو:
اهي ناڪاميون صحيح طور تي ڊيٽا لڏپلاڻ آهن. ان کان پوء، زببڪس سرور ۾، تاريخ sinkers جي لوڊشيڊنگ پروفائل، جيئن توهان ڏسي سگهو ٿا، تمام گهڻو تبديل ٿي چڪو آهي. اهو توهان کي ڊيٽا داخل ڪرڻ جي اجازت ڏئي ٿو تقريباً 3 ڀيرا تيز ۽ گهٽ استعمال ڪريو HistoryCache - مطابق، توهان وٽ ڊيٽا وقت تي پهچائي ويندي. ٻيهر، 80 هزار قدر في سيڪنڊ هڪ انتهائي تيز شرح آهي (يقينا، Yandex لاء نه). مجموعي طور تي اھو ھڪڙو وڏو سيٽ اپ آھي، ھڪڙي سرور سان.
PostgreSQL ڪارڪردگي ٽيسٽ: 120 هزار NVPs
اڳيون، مون ڊيٽا عناصر جي تعداد جي قيمت اڌ ملين تائين وڌايو ۽ 125 هزار في سيڪنڊ جي حساب سان قيمت حاصل ڪئي:
۽ مون کي اهي گراف مليا:
اصول ۾، هي هڪ ڪم ڪندڙ سيٽ اپ آهي، اهو ڪافي وقت تائين ڪم ڪري سگهي ٿو. پر جيئن ته مون وٽ صرف هڪ 1,5 ٽيرا بائيٽ ڊسڪ هئي، مون ان کي ڪجهه ڏينهن ۾ استعمال ڪيو. سڀ کان اهم ڳالهه اها آهي ته ساڳئي وقت نئين پارٽيشنز TimescaleDB تي ٺاهيا ويا، ۽ اهو ڪارڪردگي لاء مڪمل طور تي اڻڄاتل هو، جيڪو MySQL بابت نٿو چئي سگهجي.
عام طور تي، ورهاڱي رات ۾ ٺاهيا ويا آهن، ڇاڪاڻ ته اهو عام طور تي داخل ٿيڻ ۽ ٽيبل سان ڪم ڪرڻ کي روڪي ٿو ۽ خدمت جي خراب ٿيڻ جي ڪري سگھي ٿو. هن معاملي ۾ اهو معاملو ناهي! مکيه ڪم هو TimescaleDB جي صلاحيتن کي جانچڻ. نتيجو هيٺ ڏنل انگ اکر هو: في سيڪنڊ 120 هزار قدر.
ڪميونٽي ۾ پڻ مثال آهن:
ان شخص به TimescaleDB آن ڪيو ۽ io.weight استعمال ڪرڻ تي لوڊ پروسيسر تي گھٽجي ويو؛ ۽ TimescaleDB جي شموليت جي ڪري اندروني پروسيس عناصر جو استعمال پڻ گھٽجي ويو آهي. ان کان علاوه، اهي عام پينڪڪس ڊسڪ آهن، اهو آهي، هڪ عام ورچوئل مشين عام ڊسڪ تي (نه SSDs)!
ڪجهه ننڍڙن سيٽ اپن لاءِ جيڪي محدود آهن ڊسڪ ڪارڪردگي، TimescaleDB، منهنجي راءِ ۾، هڪ تمام سٺو حل آهي. اهو توهان کي ڊيٽابيس لاءِ تيز هارڊويئر ڏانهن لڏڻ کان اڳ ڪم جاري رکڻ جي اجازت ڏيندو.
مان توهان سڀني کي دعوت ڏيان ٿو اسان جي واقعن ۾: ماسڪو ۾ ڪانفرنس، ريگا ۾ اجلاس. اسان جا چينل استعمال ڪريو - ٽيليگرام، فورم، IRC. جيڪڏهن توهان وٽ ڪو سوال آهي، اسان جي ڊيسڪ تي اچو، اسان هر شي بابت ڳالهائي سگهون ٿا.
سامعين جا سوال
سامعين کان سوال (هتي - A): - جيڪڏهن TimescaleDB ترتيب ڏيڻ تمام آسان آهي، ۽ اهو اهڙي ڪارڪردگي واڌارو ڏئي ٿو، ته پوء شايد اهو استعمال ڪيو وڃي پوسٽ گريس سان زيبڪس کي ترتيب ڏيڻ لاء بهترين مشق؟ ۽ ڇا ھن حل جا ڪي نقص ۽ نقصان آھن، يا سڀ کان پوءِ، جيڪڏھن مون پنھنجي لاءِ زيبڪس ٺاهڻ جو فيصلو ڪيو، ته مان آساني سان Postgres وٺي سگھان ٿو، اتي ئي ٽائم اسڪيل انسٽال ڪري، ان کي استعمال ڪري سگھان ٿو ۽ ڪنھن به مسئلي جي باري ۾ نه سوچيان؟
AG: - ها، مان چوان ٿو ته هي هڪ سٺي سفارش آهي: استعمال ڪريو Postgres فوري طور تي TimescaleDB واڌ سان. جيئن ته مون اڳ ۾ ئي چيو آهي، تمام سٺو جائزو، حقيقت اها آهي ته هي "خصوصيت" تجرباتي آهي. پر اصل ۾ ٽيسٽ ڏيکاري ٿو ته اهو هڪ بهترين حل آهي (TimescaleDB سان) ۽ مان سمجهان ٿو ته اهو ترقي ڪندو! اسان نگراني ڪري رهيا آهيون ته هي توسيع ڪيئن ترقي ڪري ٿي ۽ ضرورت مطابق تبديليون آڻينداسين.
جيتوڻيڪ ترقي جي دوران، اسان انهن مان هڪ مشهور "خصوصيت" تي ڀروسو ڪيو: اهو ممڪن آهي ته ڪم سان گڏ ڪم ڪرڻ ٿورو مختلف. پر پوءِ اھي ان کي ڪٽي ڇڏيا ايندڙ رليز ۾، ۽ اسان کي ھن ڪوڊ تي ڀروسو ڪرڻ بند ڪرڻو پيو. مان هن حل کي ڪيترن ئي سيٽ اپ تي استعمال ڪرڻ جي صلاح ڏيندس. جيڪڏھن توھان استعمال ڪريو MySQL... سراسري سيٽ اپ لاءِ، ڪو به حل سٺو ڪم ڪري ٿو.
ج: - ڪميونٽي جي آخري گرافس تي، "هائوس ڪيپر" سان گڏ هڪ گراف هو:
هن ڪم جاري رکيو. TimescaleDB سان هائوس ڪيپر ڇا ڪندو آهي؟
AG: - ھاڻي مان پڪ سان نٿو چئي سگھان - مان ڪوڊ کي ڏسندس ۽ توھان کي وڌيڪ تفصيل سان ٻڌايان ٿو. اهو استعمال ڪري ٿو TimescaleDB سوالن کي ختم ڪرڻ لاءِ نه، پر ڪنهن نه ڪنهن طرح انهن کي گڏ ڪرڻ لاءِ. مان اڃان تائين هن ٽيڪنيڪل سوال جو جواب ڏيڻ لاءِ تيار ناهيان. اڄ يا سڀاڻي اسٽينڊ تي وڌيڪ معلوم ڪنداسين.
ج: - مون وٽ ھڪڙو ساڳيو سوال آھي - ٽائم اسڪيل ۾ حذف ٿيل آپريشن جي ڪارڪردگي بابت.
A (شاعرن کان جواب): - جڏهن توهان ڪنهن ٽيبل مان ڊيٽا کي حذف ڪريو ٿا، جيڪڏهن توهان حذف ذريعي ڪندا آهيو، ته پوء توهان کي ٽيبل ذريعي وڃڻ جي ضرورت آهي - حذف ڪريو، صاف ڪريو، هر شيء کي مستقبل جي خلا لاء نشان لڳايو. ٽائم اسڪيل ۾، جيئن توهان وٽ ٽڪرا آهن، توهان ڇڏي سگهو ٿا. عام طور تي ڳالهائڻ، توهان صرف فائل کي ٻڌايو ته وڏي ڊيٽا ۾ آهي: "خارج ڪريو!"
ٽائم اسڪيل صرف سمجھي ٿو ته اهڙو ٽڪرو هاڻي موجود ناهي. ۽ جيئن ته اهو سوال جي منصوبه بندي ۾ ضم ٿي ويو آهي، اهو توهان جي حالتن کي چونڊڻ يا ٻين عملن ۾ پڪڙڻ لاء ٿلهو استعمال ڪري ٿو ۽ فوري طور تي سمجهي ٿو ته اهو حصو هاڻي موجود ناهي - "مان هاڻي اتي نه ويندس!" (ڊيٽا دستياب ناهي). اهو ئي سڀ ڪجهه آهي! اهو آهي، هڪ ٽيبل اسڪين هڪ بائنري فائل کي ختم ڪرڻ سان تبديل ڪيو ويو آهي، تنهنڪري اهو تيز آهي.
ج: - اسان اڳ ۾ ئي غير SQL جي موضوع تي رابطو ڪيو آهي. جيستائين مان سمجهان ٿو، زيبڪس کي حقيقت ۾ ڊيٽا کي تبديل ڪرڻ جي ضرورت ناهي، ۽ اهو سڀ ڪجهه هڪ لاگ وانگر آهي. ڇا خاص ڊيٽابيس استعمال ڪرڻ ممڪن آھي جيڪي پنھنجي ڊيٽا کي تبديل نه ڪري سگھن، پر ساڳئي وقت محفوظ، گڏ ڪرڻ ۽ ورهائڻ تمام تيز - ڪلڪ ھاؤس، مثال طور، ڪافڪا جھڙو ڪا شيءِ؟... ڪافڪا پڻ ھڪڙو لاگ آھي! ڇا اهو ممڪن آهي ته ڪنهن به طريقي سان انهن کي ضم ڪرڻ لاء؟
AG: - Unloading ڪري سگهجي ٿو. اسان وٽ نسخو 3.4 کان هڪ خاص ”خصوصيت“ آهي: توهان سڀ تاريخي فائلون، واقعا، ٻيو سڀ ڪجهه فائلن ۾ لکي سگهو ٿا. ۽ پوءِ ان کي موڪليو ڪنهن ٻئي ڊيٽابيس ڏانهن ڪجهه هينڊلر استعمال ڪندي. حقيقت ۾، ڪيترائي ماڻهو ٻيهر ڪم ڪن ٿا ۽ سڌو سنئون ڊيٽابيس ڏانهن لکن ٿا. اڏام تي، تاريخ sinkers هي سڀ فائلن ۾ لکندا آهن، انهن فائلن کي گھمايو، وغيره، ۽ توهان هن کي ڪلڪ هائوس ڏانهن منتقل ڪري سگهو ٿا. مان منصوبن بابت نٿو چئي سگهان، پر شايد NoSQL حلن لاءِ وڌيڪ مدد (جهڙوڪ ڪلڪ هائوس) جاري رهندي.
ج: - عام طور تي، اهو ظاهر ٿئي ٿو ته توهان مڪمل طور تي پوسٽ گريس مان نجات حاصل ڪري سگهو ٿا؟
AG: - يقينا، زيبڪس ۾ سڀ کان ڏکيو حصو تاريخي جدولن جو آهي، جيڪي سڀ کان وڌيڪ مسئلا ۽ واقعا پيدا ڪن ٿا. انهي حالت ۾، جيڪڏهن توهان ڊگهي وقت تائين واقعن کي ذخيرو نٿا ڪريو ۽ تاريخ کي رجحانات سان گڏ ڪنهن ٻئي تيز اسٽوريج ۾ ذخيرو ڪريو، پوء عام طور تي، مان سمجهان ٿو، ڪو مسئلو ناهي.
ج: - ڇا توھان اندازو لڳائي سگھوٿا ته ھر شيءِ ڪيتري تيزيءَ سان ڪم ڪندي جيڪڏھن توھان ڪلڪ ڪيو ھاؤس ڏانھن، مثال طور؟
AG: - مون ان جي آزمائش نه ڪئي آهي. مان سمجهان ٿو ته گهٽ ۾ گهٽ ساڳيو نمبر حاصل ڪري سگهجي ٿو بلڪل آسان، ڏنو ته ڪلڪ هائوس جو پنهنجو انٽرفيس آهي، پر مان پڪ سان نٿو چئي سگهان. اهو امتحان ڏيڻ بهتر آهي. اهو سڀ ڪجهه منحصر آهي ترتيب تي: توهان وٽ ڪيترا ميزبان آهن، وغيره. داخل ڪرڻ ھڪڙي شيء آھي، پر توھان کي ھن ڊيٽا کي ٻيهر حاصل ڪرڻ جي ضرورت آھي - گرافانا يا ٻيو ڪجھ.
ج: - تنهنڪري اسان هڪ برابر جنگ بابت ڳالهائي رهيا آهيون، ۽ نه انهن تيز ڊيٽابيس جي وڏي فائدي بابت؟
AG: - مان سمجهان ٿو جڏهن اسان ضم ٿينداسين، اتي وڌيڪ صحيح ٽيسٽون هونديون.
ج: - سٺو پراڻو آر آر ڊي ڪيڏانهن ويو؟ ڇا توهان کي SQL ڊيٽابيس ۾ تبديل ڪيو؟ شروعات ۾، آر آر ڊي تي سڀئي ميٽرڪ گڏ ڪيا ويا.
AG: - زيبڪس وٽ RRD هو، شايد هڪ تمام قديم نسخي ۾. اتي هميشه SQL ڊيٽابيس ٿي چڪا آهن - هڪ کلاسک انداز. کلاسک طريقو آهي MySQL، PostgreSQL (اهي هڪ ڊگهي وقت تائين موجود آهن). اسان تقريبن SQL ۽ RRD ڊيٽابيس لاءِ عام انٽرفيس استعمال نه ڪيو آهي.
ڪجھ اشتهار 🙂
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com