Re: nosql - кто что использует

Очень надеюсь, что этот оффтоп не сильно раздражает общественность.
Если мешаем - скажите и мы уйдем в оффлайн.

2011/8/18 Nikolay Grebnev <nikolaygrebnev@gmail.com>:
> Алексей, а можно попросить поделиться с общественностью настройками?
> 2)  hbase/hadoop + настройки java машин (сколько вы им памяти даете)

Ящики у нас старые и мне не нравятся, сейчас работаем над новым
кластером. Железо, которое мне понравилось:
- 16-ядерные ксеоны какие-то (ядры полезны в жабе) :-)
- 24Gb RAM
- 4x2Tb SATA JBOD на регионсерверах и RAID1(2xSATA) на мастере так как
страшно потерять его.

Насчет настроек, вот просто не упорядоченный поток сознания:
- мастер-сервер по нашему опыту стоит отделить от кластера
регионсерверов, так выходит значительно проще тюнить все кругом,
потому как мастер ест память и запускать регионсервер рядом с ним -
это значит больше памяти нужно на мастер-ноду и, иногда, больше CPU.

- все таблицы СРАЗУ нужно делать с большим MAX_FILESIZE, 512М-2Gb,
одной из главных проблем в хбейсе для нас является потребление памяти
регионсерверами и это потребление прямо пропорционально количеству
регионов на них. Потому для больших таблиц приходится делать большие
регионы, но проблема в том, что он их не merge'их никогда, значит
регионы, которые были созданы до изменения настроек таблицы, остаются
мелкими. Как rule of thumb стараемся использовать следующую мысль: не
стоит делать больше 1000 регионов на регионсервер.

- hbase.regions.percheckin - это дело стоит увеличить до 2-3 десятков
если регионов дофига, сильно помогает в случае падения ящика
какого-нибудь или в случае рестарта кластера (оно контролирует как
быстро регионы будут назначаться на регионсервера)

- zookeeper.session.timeout - мы подняли до 180 сек, помогает с
длинными GC-паузами на серверах, которые раньше за минуту выпадали из
кластера. Кто-то может сказать "так таких пауз лучше избегать" и будет
прав, но в мелком кластере лучше переждать паузу чем устроить
ребелансинг тысяч гигабайтных блоков между серверами.

- hbase.client.keyvalue.maxsize выставили в -1, так как иначе оно
ограничивает размеры блобов каким-то смешным значением :-)

- если в кластер наливается куча данных (начальная загрузка и тп), то
намного быстрее делать это через создание HFile в hdfs и потом
подключения их в работающий hbase. Если же нужно лить через API, то
обязательно отключать WAL, сильно увеличивает скорость.

- насчет hadoop'а - обязательно нужен с поддержкой append, мы
используем CDH3, очень довольны.

> 1) сквидятина
> 3) Если не очень нагло - чем дергаете документы из hbase в сквидятину

У нас так:
users -> nginx -> haproxy -> squid -> rails -> hbase

То есть мы кешируем не документы, а готовые страницы с ними.

> Огромное спасибо :)
>
> 2011/8/18 Oleksiy Kovyrin <alexey@kovyrin.net>
>>
>> 2011/8/18 Max Lapshin <max.lapshin@gmail.com>:
>> > Почитай ещё коменты к моему посту:
>> > http://levgem.livejournal.com/360646.html
>> >
>> > там на тему твоего вопроса есть ответы.
>> >
>> > Леша: 69 мс на картинку -- это же очень много.
>>
>> А я там не картинки храню, а документы :-)
>> И достаю их оттуда чтобы закешировать в сквиде с hit ratio в 95%.
>> Потому мне не особо страшно.

--
Oleksiy Kovyrin
http://kovyrin.net/

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru