Погледаћемо како Заббик ради са ТимесцалеДБ базом података као позадином. Показаћемо вам како да почнете од нуле и како да мигрирате са ПостгреСКЛ-а. Такође ћемо обезбедити упоредне тестове перформанси две конфигурације.
ХигхЛоад++ Сибир 2019. Томск Халл. 24. јун, 16:00. Тезе и . Следећа ХигхЛоад++ конференција биће одржана 6. и 7. априла 2020. године у Санкт Петербургу. Детаљи и карте .
Андреи Гусхцхин (у даљем тексту – АГ): – Ја сам ЗАББИКС инжењер техничке подршке (у даљем тексту „Заббик“), тренер. Радим у техничкој подршци више од 6 година и имао сам директно искуство са перформансама. Данас ћу говорити о перформансама које ТимесцалеДБ може да пружи у поређењу са редовним ПостгреСКЛ 10. Такође, неки уводни део о томе како функционише уопште.
Највећи изазови продуктивности: од прикупљања података до чишћења података
За почетак, постоје одређени изазови у погледу перформанси са којима се суочава сваки систем за праћење. Први изазов продуктивности је брзо прикупљање и обрада података.
Добар систем за праћење треба брзо, благовремено да прими све податке, да их обради према тригер изразима, односно да их обради према неким критеријумима (ово је различито у различитим системима) и да их сачува у бази података како би се ти подаци користили у будућност.
Други изазов перформанси је складиштење историје. Често складиштите у бази података и имајте брз и практичан приступ овим показатељима који су прикупљени током одређеног временског периода. Најважније је да је ове податке згодно добити, користити их у извештајима, графиконима, окидачима, у неким граничним вредностима, за упозорења итд.
Трећи изазов перформанси је брисање историје, односно када дођете до тачке у којој не морате да чувате детаљне метрике које су прикупљане током 5 година (чак и месеци или два месеца). Неки мрежни чворови су избрисани, или неки хостови, метрика више није потребна јер су већ застарела и више се не прикупљају. Све ово треба очистити како ваша база података не би постала превелика. Уопштено говорећи, брисање историје је најчешће озбиљан тест за складиште - често има веома снажан утицај на перформансе.
Како решити проблеме са кеширањем?
Сада ћу говорити конкретно о Заббик-у. У Заббик-у, први и други позив се решавају помоћу кеширања.
Прикупљање и обрада података - Користимо РАМ за чување свих ових података. Ови подаци ће сада бити детаљније размотрени.
Такође на страни базе података постоји кеширање за главне селекције - за графиконе и друге ствари.
Кеширање на страни самог Заббик сервера: имамо ЦонфигуратионЦацхе, ВалуеЦацхе, ХисториЦацхе, ТрендсЦацхе. Шта је то?
ЦонфигуратионЦацхе је главна кеш меморија у којој чувамо метрике, хостове, ставке података, покретаче; све што је потребно за обраду предобраде, прикупљање података, са којих хостова да прикупљате, са којом фреквенцијом. Све ово се чува у ЦонфигуратионЦацхе-у како не би одлазили у базу података и правили непотребне упите. Након што се сервер покрене, ажурирамо овај кеш (креирамо га) и периодично га ажурирамо (у зависности од подешавања конфигурације).
Кеширање у Заббик-у. Прикупљање података
Овде је дијаграм прилично велик:
Главни у шеми су ови колектори:
То су сами процеси склапања, разни „поллери“ који су одговорни за различите врсте склопова. Они прикупљају податке преко ицмп, ипми и разних протокола и све то преносе у претпроцесу.
ПреПроцессинг ХисториЦацхе
Такође, ако имамо израчунате елементе података (знају они који су упознати са Заббик-ом), односно израчунате елементе података агрегације, преузимамо их директно из ВалуеЦацхе-а. Касније ћу вам рећи како се попуњава. Сви ови сакупљачи користе ЦонфигуратионЦацхе да примају своје послове и затим их прослеђују на претходну обраду.
Претходна обрада такође користи ЦонфигуратионЦацхе за добијање корака претходне обраде и обрађује ове податке на различите начине. Почевши од верзије 4.2, преместили смо га на проки. Ово је веома згодно, јер је сама предобрада прилично тешка операција. А ако имате веома велики Заббик, са великим бројем елемената података и великом учесталошћу прикупљања, онда ово увелико поједностављује рад.
Сходно томе, након што смо на неки начин обрадили ове податке користећи претходну обраду, чувамо их у ХисториЦацхе-у како бисмо их даље обрађивали. Овим се прикупљање података завршава. Прелазимо на главни процес.
Рад синхронизатора историје
Главни процес у Заббик-у (пошто је монолитна архитектура) је Хистори синцер. Ово је главни процес који се посебно бави атомском обрадом сваког елемента података, односно сваке вредности:
- вредност долази (преузима је из ХисториЦацхе-а);
- проверава у Конфигурационом синхронизатору: да ли постоје окидачи за израчунавање - израчунава их;
ако постоји - креира догађаје, креира ескалацију ради креирања упозорења, ако је потребно према конфигурацији; - евидентира окидаче за накнадну обраду, агрегацију; ако агрегирате током последњег сата и тако даље, ВалуеЦацхе памти ову вредност како не би отишао у табелу историје; Дакле, ВалуеЦацхе се попуњава потребним подацима који су неопходни за израчунавање покретача, израчунатих елемената итд.;
- тада Синцер историје уписује све податке у базу података;
- база података их записује на диск – ту се процес обраде завршава.
База података. Кеширање
На страни базе података, када желите да видите графиконе или неке извештаје о догађајима, постоје разне кеш меморије. Али у овом извештају нећу говорити о њима.
За МиСКЛ постоји Иннодб_буффер_поол, и гомила различитих кеш меморија који се такође могу конфигурисати.
Али ово су главни:
- схаред_буфферс;
- ефективна_цацхе_сизе;
- схаред_поол.
За све базе података, рекао сам да постоје одређене кеш меморије које вам омогућавају да чувате у РАМ-у податке који су често потребни за упите. За то имају своје технологије.
О перформансама базе података
Сходно томе, постоји конкурентско окружење, односно Заббик сервер прикупља податке и евидентира их. Када се поново покрене, такође чита из историје да би попунио ВалуеЦацхе и тако даље. Овде можете имати скрипте и извештаје који користе Заббик АПИ, који је изграђен на веб интерфејсу. Заббик АПИ улази у базу података и прима потребне податке за добијање графикона, извештаја или неке врсте листе догађаја, недавних проблема.
Такође, веома популарно решење за визуелизацију је Графана, коју користе наши корисници. Може се директно пријавити и преко Заббик АПИ-ја и преко базе података. То такође ствара одређену конкуренцију за добијање података: потребно је финије, боље подешавање базе података да би се ускладила са брзим испоруком резултата и тестирањем.
Брисање историје. Заббик има кућну помоћницу
Трећи позив који се користи у Заббик-у је брисање историје помоћу Хоусекеепер-а. Хоусекеепер прати сва подешавања, односно наши елементи података показују колико дуго треба чувати (у данима), колико дуго треба чувати трендове и динамику промена.
Нисам говорио о ТрендЦацхе-у, који израчунавамо у ходу: подаци стигну, агрегирамо их за један сат (углавном су то бројеви за последњи сат), количина је просечна/минимална и снимамо је једном на сат у табела динамике промена („Трендови“) . „Хоусекеепер“ покреће и брише податке из базе података користећи редовне одабире, што није увек ефикасно.
Како разумети да је неефикасан? На графиконима перформанси интерних процеса можете видети следећу слику:
Ваш синхронизатор историје је стално заузет (црвени графикон). И „црвени“ графикон који иде на врх. Ово је „домаћица“ која се покреће и чека да база података избрише све редове које је специфицирала.
Узмимо неки ИД ставке: потребно је да избришете последњих 5 хиљада; наравно по индексима. Али обично је скуп података прилично велик – база података га и даље чита са диска и ставља у кеш меморију, а ово је веома скупа операција за базу података. У зависности од његове величине, то може довести до одређених проблема са перформансама.
Домаћицу можете онемогућити на једноставан начин - имамо познати веб интерфејс. Подешавања у општој администрацији (подешавања за „Домаћица“) онемогућавамо унутрашње одржавање за интерну историју и трендове. Сходно томе, Хоусекеепер више не контролише ово:
Шта можете следеће да урадите? Искључили сте га, графикони су вам се изравнали... Какви би проблеми могли настати у овом случају? Шта може помоћи?
Партиционисање (секционисање)
Обично је ово конфигурисано на другачији начин у свакој релационој бази података коју сам навео. МиСКЛ има сопствену технологију. Али генерално, они су веома слични када су у питању ПостгреСКЛ 10 и МиСКЛ. Наравно, постоји много интерних разлика у томе како се све то имплементира и како све то утиче на перформансе. Али генерално, стварање нове партиције често такође доводи до одређених проблема.
У зависности од вашег подешавања (колико података креирате у једном дану), обично постављају минимум - ово је 1 дан / серија, а за "трендове", динамику промена - 1 месец / нова серија. Ово се може променити ако имате веома велико подешавање.
Рецимо одмах о величини подешавања: до 5 хиљада нових вредности у секунди (тзв. нвпс) - ово ће се сматрати малим „подешавањем“. Просек - од 5 до 25 хиљада вредности у секунди. Све што је горе наведено су већ велике и веома велике инсталације које захтевају веома пажљиву конфигурацију базе података.
На веома великим инсталацијама, 1 дан можда није оптималан. Лично сам видео партиције на МиСКЛ-у од 40 гигабајта дневно (а можда их има и више). Ово је веома велика количина података, што може довести до неких проблема. Треба га смањити.
Зашто вам је потребна партиција?
Оно што Партиционисање пружа, мислим да сви знају, је партиционисање табеле. Често су то засебне датотеке на диску и захтеви за распон. Оптималније бира једну партицију ако је део нормалног партиционисања.
За Заббик се посебно користи по опсегу, по опсегу, односно користимо временску ознаку (регуларни број, време од почетка епохе). Одређујете почетак дана/крај дана, а ово је партиција. Сходно томе, ако тражите податке који су стари два дана, све се брже преузима из базе, јер је потребно учитати само један фајл у кеш и вратити га (уместо велике табеле).
Многе базе података такође убрзавају уметање (уметање у једну подређену табелу). За сада говорим апстрактно, али и ово је могуће. Подела често помаже.
Еластицсеарцх за НоСКЛ
Недавно, у верзији 3.4, имплементирали смо НоСКЛ решење. Додата могућност писања у Еластицсеарцх. Можете писати одређене врсте: ви бирате - или писати бројеве или неке знакове; имамо стринг текст, можете писати дневнике у Еластицсеарцх... Сходно томе, веб интерфејс ће такође приступити Еластицсеарцх-у. Ово функционише одлично у неким случајевима, али тренутно се може користити.
ТимесцалеДБ. Хипертаблес
За 4.4.2 обратили смо пажњу на једну ствар као што је ТимесцалеДБ. Шта је то? Ово је проширење за ПостгреСКЛ, то јест, има изворни ПостгреСКЛ интерфејс. Осим тога, ово проширење вам омогућава да радите много ефикасније са подацима временских серија и имате аутоматско партиционисање. Како то изгледа:
Ово је хипертабела - постоји такав концепт у Тимесцале-у. Ово је хипертабела коју креирате и садржи делове. Комадићи су партиције, ово су подређене табеле, ако се не варам. Заиста је ефикасан.
ТимесцалеДБ и ПостгреСКЛ
Као што уверавају произвођачи ТимесцалеДБ-а, они користе исправнији алгоритам за обраду упита, посебно уметања, што им омогућава да имају приближно константне перформансе са повећањем величине уметања скупа података. Односно, након 200 милиона редова Постгреса, уобичајени почиње веома да пада и губи перформансе буквално на нулу, док Тимесцале вам омогућава да убаците уметке што је могуће ефикасније са било којом количином података.
Како инсталирати ТимесцалеДБ? То је једноставно!
То је у документацији, описано је - можете га инсталирати из пакета за било који... Зависи од званичних Постгрес пакета. Може се саставити ручно. Десило се да сам морао да компајлирам за базу података.
На Заббик-у једноставно активирамо Ектентион. Мислим да они који су користили Ектентион у Постгресу... Једноставно активирате Ектентион, креирате га за Заббик базу података коју користите.
И последњи корак...
ТимесцалеДБ. Миграција историјских табела
Морате да направите хипертабелу. За ово постоји посебна функција - Креирај хипертабелу. У њему је први параметар табела која је потребна у овој бази података (за коју треба да направите хипертабелу).
Поље по коме се креира, и цхунк_тиме_интервал (ово је интервал комада (партиција које треба да се користи). 86 је један дан.
Параметар Миграте_дата: Ако уметнете на труе, ово ће мигрирати све тренутне податке у унапред креиране делове.
И сам сам користио миграте_дата – потребно је доста времена, у зависности од тога колико је велика ваша база података. Имао сам преко терабајта - било ми је потребно више од сат времена за стварање. У неким случајевима сам током тестирања обрисао историјске податке за текст (хистори_тект) и стринг (хистори_стр) да их не бих пренео – нису ми баш били занимљиви.
И вршимо последње ажурирање у нашем дб_ектентион: инсталирамо тимесцаледб тако да база података и, посебно, наш Заббик разумеју да постоји дб_ектентион. Он га активира и користи исправну синтаксу и упите бази података, користећи оне „карактеристике“ које су неопходне за ТимесцалеДБ.
Конфигурација сервера
Користио сам два сервера. Први сервер је прилично мала виртуелна машина, 20 процесора, 16 гигабајта РАМ-а. Конфигурисао сам Постгрес 10.8 на њему:
Оперативни систем је био Дебиан, систем датотека је био кфс. Направио сам минимална подешавања да користим ову конкретну базу података, минус оно што ће сам Заббик користити. На истој машини је био Заббик сервер, ПостгреСКЛ и агенти за учитавање.
Користио сам 50 активних агената који користе ЛоадаблеМодуле за брзо генерисање различитих резултата. Они су ти који су генерисали низове, бројеве и тако даље. Попунио сам базу података са доста података. У почетку је конфигурација садржала 5 хиљада елемената података по хосту, а отприлике сваки елемент података је садржао окидач - да би ово било право подешавање. Понекад вам је чак потребно више од једног окидача за употребу.
Регулисао сам интервал ажурирања и само оптерећење не само коришћењем 50 агената (додавањем више), већ и коришћењем динамичких елемената података и смањивањем интервала ажурирања на 4 секунде.
Тест перформансе. ПостгреСКЛ: 36 хиљада НВП-а
Прво покретање, прво подешавање које сам имао било је на чистом ПостреСКЛ 10 на овом хардверу (35 хиљада вредности у секунди). Генерално, као што видите на екрану, убацивање података траје делиће секунде – све је добро и брзо, ССД дискови (200 гигабајта). Једино што се 20 ГБ попуни прилично брзо.
У будућности ће бити доста таквих графикона. Ово је стандардна контролна табла перформанси Заббик сервера.
Први графикон је број вредности у секунди (плаво, горе лево), у овом случају 35 хиљада вредности. Ово (горе у средини) је учитавање процеса изградње, а ово (горе десно) је учитавање интерних процеса: синхронизатора историје и кућне помоћнице, који овде (доњи центар) раде већ неко време.
Овај графикон (доњи центар) приказује коришћење ВалуеЦацхе-а - колико ВалуеЦацхе погодака за окидаче (неколико хиљада вредности у секунди). Још један важан графикон је четврти (доле лево), који показује употребу ХисториЦацхе-а, о чему сам говорио, а који је бафер пре убацивања у базу података.
Тест перформансе. ПостгреСКЛ: 50 хиљада НВП-а
Затим сам повећао оптерећење на 50 хиљада вредности у секунди на истом хардверу. Када је учитао Хоусекеепер, 10 хиљада вредности је снимљено за 2-3 секунде са прорачуном. Шта је, у ствари, приказано на следећем снимку екрана:
„Домаћер“ већ почиње да омета рад, али генерално, оптерећење трапера за потапање историје је и даље на нивоу од 60% (трећи графикон, горе десно). ХисториЦацхе већ почиње да се пуни активно док је Хоусекеепер покренут (доле лево). Био је око пола гигабајта, пун 20%.
Тест перформансе. ПостгреСКЛ: 80 хиљада НВП-а
Затим сам повећао на 80 хиљада вредности у секунди:
Било је око 400 хиљада елемената података, 280 хиљада окидача. Уметак је, као што видите, у смислу оптерећења историјских потапача (било их је 30) већ био прилично висок. Затим сам повећао различите параметре: потапаче историје, кеш... На овом хардверу оптерећење на синкерима историје почело је да расте до максимума, скоро „на полици“ - сходно томе, ХисториЦацхе је отишао у веома велико оптерећење:
Све ово време сам пратио све системске параметре (како се користи процесор, РАМ) и открио да је искоришћеност диска максимална – постигао сам максимални капацитет овог диска на овом хардверу, на овој виртуелној машини. „Постгрес“ је прилично активно почео да избацује податке таквим интензитетом, а диск више није имао времена за писање, читање...
Узео сам други сервер који је већ имао 48 процесора и 128 гигабајта РАМ-а:
Такође сам га „подесио“ - инсталирао Хистори синцер (60 комада) и постигао прихватљиве перформансе. У ствари, нисмо „на полици“, али је то вероватно граница продуктивности, где је већ потребно нешто учинити.
Тест перформансе. ТимесцалеДБ: 80 хиљада НВП-а
Мој главни задатак је био да користим ТимесцалеДБ. Сваки графикон показује пад:
Ови пропусти су управо миграција података. Након тога, у Заббик серверу, профил учитавања хисторијских синкера, као што видите, доста се променио. Омогућава вам да убаците податке скоро 3 пута брже и користите мање ХисториЦацхе-а - сходно томе, подаци ће вам бити достављени на време. Опет, 80 хиљада вредности у секунди је прилично висока стопа (наравно, не за Иандек). Све у свему, ово је прилично велика поставка, са једним сервером.
ПостгреСКЛ тест перформанси: 120 хиљада НВП-а
Затим сам повећао вредност броја елемената података на пола милиона и добио израчунату вредност од 125 хиљада у секунди:
И добио сам ове графиконе:
У принципу, ово је радна поставка, може радити прилично дуго. Али пошто сам имао само диск од 1,5 терабајта, потрошио сам га за неколико дана. Најважније је да су у исто време креиране нове партиције на ТимесцалеДБ-у, а то је било потпуно непримећено за перформансе, што се не може рећи за МиСКЛ.
Обично се партиције креирају ноћу, јер то генерално блокира уметање и рад са табелама и може довести до деградације услуге. У овом случају то није случај! Главни задатак је био да се тестирају могућности ТимесцалеДБ-а. Резултат је била следећа цифра: 120 хиљада вредности у секунди.
Има и примера у заједници:
Особа је такође укључила ТимесцалеДБ и оптерећење при коришћењу ио.веигхт је пало на процесор; а употреба унутрашњих елемената процеса је такође смањена због укључивања ТимесцалеДБ-а. Штавише, ово су обични палачинки дискови, односно обична виртуелна машина на обичним дисковима (не ССД-овима)!
За нека мала подешавања која су ограничена перформансама диска, ТимесцалеДБ је, по мом мишљењу, веома добро решење. То ће вам омогућити да наставите са радом пре миграције на бржи хардвер за базу података.
Позивам вас све на наше догађаје: Конференција у Москви, Самит у Риги. Користите наше канале - Телеграм, форум, ИРЦ. Ако имате питања, дођите до нашег стола, можемо да разговарамо о свему.
Питања публике
Питање из публике (у даљем тексту - А): - Ако је ТимесцалеДБ тако једноставан за конфигурисање, и даје такво повећање перформанси, онда би можда ово требало користити као најбољу праксу за конфигурисање Заббик-а са Постгрес-ом? И да ли постоје неке замке и недостаци овог решења, или ипак, ако сам одлучио да направим Заббик за себе, лако могу да узмем Постгрес, одмах инсталирам Тимесцале, користим га и не размишљам о било каквим проблемима?
АГ: – Да, рекао бих да је ово добра препорука: одмах користите Постгрес са екстензијом ТимесцалеДБ. Као што сам већ рекао, много добрих критика, упркос чињеници да је ова „карактеристика“ експериментална. Али заправо тестови показују да је ово одлично решење (са ТимесцалеДБ) и мислим да ће се развијати! Пратимо како се ово проширење развија и по потреби ћемо уносити измене.
Чак и током развоја, ослањали смо се на једну од њихових добро познатих „карактеристики“: било је могуће радити са комадима мало другачије. Али онда су то прекинули у следећем издању и морали смо да престанемо да се ослањамо на овај код. Препоручио бих да користите ово решење на многим подешавањима. Ако користите МиСКЛ... За просечна подешавања, свако решење добро функционише.
И: – На последњим графиконима из заједнице био је графикон са „Домаћицом“:
Наставио је да ради. Шта домаћица ради са ТимесцалеДБ-ом?
АГ: – Сада не могу са сигурношћу да кажем – погледаћу код и рећи ћу вам детаљније. Користи ТимесцалеДБ упите не да избрише делове, већ да их некако агрегира. Још нисам спреман да одговорим на ово техничко питање. Више ћемо сазнати на штанду данас или сутра.
И: – Имам слично питање – о извођењу операције брисања у Тимесцале-у.
О (одговор из публике): – Када избришете податке из табеле, ако то радите преко делете, онда треба да прођете кроз табелу – обришите, очистите, обележите све за будући вакуум. У временској скали, пошто имате комаде, можете да испустите. Грубо говорећи, једноставно кажете датотеци која је у великим подацима: „Избриши!“
Тимесцале једноставно схвата да такав комад више не постоји. А пошто је интегрисан у планер упита, користи куке да ухвати ваше услове у селективним или другим операцијама и одмах схвата да овај комад више не постоји - „Нећу више ићи тамо!“ (подаци нису доступни). То је све! То јест, скенирање табеле је замењено брисањем бинарне датотеке, тако да је брзо.
И: – Већ смо се дотакли теме не-СКЛ. Колико сам разумео, Заббик заправо не треба да мења податке, а све ово је нешто попут дневника. Да ли је могуће користити специјализоване базе података које не могу да мењају своје податке, али у исто време много брже чувају, акумулирају и дистрибуирају – Цлицкхоусе, на пример, нешто налик Кафки?.. Кафка је такође лог! Да ли је могуће да их некако интегришемо?
АГ: - Може се извршити истовар. Од верзије 3.4 имамо одређену „карактеристику“: можете уписивати све историјске датотеке, догађаје, све остало у датотеке; а затим га пошаљи у било коју другу базу података користећи неки руковалац. У ствари, многи људи прерађују и пишу директно у базу података. У ходу, потапачи историје записују све ово у датотеке, ротирају ове датотеке и тако даље, а ви то можете пренети у Цлицкхоусе. Не могу да кажем о плановима, али ће се можда наставити даља подршка за НоСКЛ решења (као што је Цлицкхоусе).
И: – Генерално, испада да можете потпуно да се решите постгреса?
АГ: – Наравно, најтежи део у Заббик-у су историјске табеле, које стварају највише проблема и догађаја. У овом случају, ако не складиштите догађаје дуго времена и складиштите историју са трендовима у неком другом брзом складишту, онда генерално мислим да неће бити проблема.
И: – Можете ли да процените колико ће брже све радити ако пређете на Цлицкхоусе, на пример?
АГ: – Нисам га тестирао. Мислим да се барем исти бројеви могу постићи прилично једноставно, с обзиром да Цлицкхоусе има свој интерфејс, али не могу са сигурношћу да кажем. Боље је тестирати. Све зависи од конфигурације: колико хостова имате и тако даље. Убацивање је једно, али треба и да преузмете ове податке - Графана или нешто друго.
И: – Дакле, говоримо о равноправној борби, а не о великој предности ових брзих база података?
АГ: – Мислим да ће када се интегришемо бити прецизнијих тестова.
И: – Где је нестао стари добри РРД? Шта вас је навело да пређете на СКЛ базе података? У почетку, сви показатељи су прикупљени на РРД.
АГ: – Заббик је имао РРД, можда у веома древној верзији. Увек су постојале СКЛ базе података – класичан приступ. Класичан приступ је МиСКЛ, ПостгреСКЛ (постоје веома дуго). Скоро никада нисмо користили заједнички интерфејс за СКЛ и РРД базе података.
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом