HBase
 sql >> база данни >  >> NoSQL >> HBase

HBase:5 съвета за работа с ниска памет EC2

Когато работите на EC2, често не можете да спечелите, когато става въпрос за типове инстанции. Един от по-рентабилните налични типове е c1.xlarge. Той има достатъчно CPU, за да се справи с уплътненията, прилично количество диск и високо мрежово I/O. Въпреки това, ние открихме, че относително ниската памет от 7 GB на c1.xlarge често води до проблеми със стабилността в силно едновременни HBase клъстери. Въпреки че има и други по-скъпи опции, този урок за HBase ще ви помогне да извлечете максимума от вашите c1.xlarge RegionServers.

1. Намалете броя на регионите на RegionServerа

В идеалния случай трябва да имате по-малко от 100 региона на RegionServer . Memstore е разделен за използване от всички активни региони и всеки регион добавя (по подразбиране) 2MB памет за MSLAB. Намаляването на това число ще помогне на нещата да вървят гладко, а не само от гледна точка на паметта.

2. Откраднете памет от други услуги

Определено не трябва да изпълнявате TaskTracker с вашия RegionServer на тези типове екземпляри, но най-вероятно използвате локален DataNode. Типичната конфигурация изисква 1 GB памет за DataNode, но открихме, че не се нуждаете от толкова много в много случаи. Проверете показателите си, преди да пуснете това, но бяхме напълно безопасни намаляхме купчина DataNode до 400 MB . Този хубав 624MB парче ще помогне на HBase да стигне малко по-далеч.

3. Настройте или деактивирайте MSLABа

Ако след кражба на памет и изрязване на региони все още имате проблеми, можете да отидете още по-далеч. Както споменах, функцията MSLAB добавя по подразбиране 2MB добавена памет за всеки регион. Можете да настройте този буфер с hbase.hregion.memstore.mslab.chunksize . Колкото по-ниско отидете, толкова по-малко е ефективен, но и по-малко памет. Деактивирайте го напълно с hbase.hregion.memstore.mslab.enabled .

4. Бъдете агресивни по отношение на кеширането и пакетиранетота

Кеширане (Scan#setCaching(int) ) и пакетиране (Scan#setBatch(int) ) са чудесни за ограничаване на ефекта на мрежовата латентност при големи сканирания. За съжаление те също изискват повече памет както от страна на клиента, така и от страна на сървъра. Имайте предвид компромисът със скоростта, но насладете се на малко повече стабилност, като ги настроите , колкото е необходимо до стойност 1.

RegionServer също трябва да има достатъчно памет, за да обработва всичките ви едновременни записи. Ако групирате записите или изпращате няколко много големи стойности на клетки, вероятно ще се сблъскате с OutOfMemoryExceptions. Намалете групирането и тук или по друг начин намерете начин да свиете размера на стойностите на клетките си.

5. Контролирайте натоварването от Hadoopа

Ако изпълнявате задачи на hadoop срещу вашите HBase данни, по същество изпълнявате много големи сканирания. В задача на HBase MapReduce всеки регион става картограф. Ако имате повече от 1 регион на RegionServer, има вероятност няколко картографа да сканират един и същ RegionServer едновременно в някакъв момент. Всяко от тези сканирания отнема ресурси от памет, диск и процесор и когато се натрупват няколко, това може да причини известна болка.

Намаляване на hbase.regionserver.handler.count ще помогне за ограничаване на броя на активните връзки, заемащи памет, но все пак може да имате проблем, ако всички манипулатори обработват големи сканирания в цял регион. Използвайки нашето разширение на TableInputFormat, можете лесно да контролирате колко едновременни картографи работят срещу един RegionServer , осигуряващо по-предвидимо използване на паметта.

Ако пишете в HBase от редуктор, ще искате да контролирате и разделянето на дялове там. Това се реализира лесно с помощта на Partitioner на Hadoop интерфейс, с HBaseAdmin на HBase интерфейс, предоставящ региона на регионални съпоставяния.

Изпълнението на HBase при ниска памет е трудно, но не и невъзможно

С тези съвети в ръка би трябвало да сте на път да оцелеете при операции във вашата среда с ниска памет. Може да е разочароващо да се бориш за всеки мегабайт памет в ерата на изключително евтина и бърза RAM. Но следвайте тези съвети и вашият финансов директор ще ви благодари, че се възползвате максимално от този рентабилен тип екземпляр. За тези с малко повече финансова свобода, ще проучим влиянието на новите типове екземпляри I2 на Amazon в бъдеща публикация . Така че бъдете на линия!

Тази статия първоначално се появи на dev.hubspot.com


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Индексиране на имейл с помощта на Cloudera Search и HBase

  2. Концепции за разработка на приложения за оперативна база данни на Cloudera

  3. Как да:Включете библиотеки на трети страни във вашата задача MapReduce

  4. Какво е InputSplit в Hadoop MapReduce?

  5. Тестване на производителността на HBase с помощта на YCSB