AZ
ну а чем конкретно вас hbase не устраивает?
Size: a a a
2020 February 20
EN
не хэш и тд..
EN
ну а чем конкретно вас hbase не устраивает?
я вчера попробовал в таблицу 170мл вставить еще 50млн и не отработало за 1.5ч
EN
где эта быстрота? не понимаю...
сейчас буду литературу изучать, может я супер тупой (не отрицаю), но блин...
когда таблица растет (и не такая уж и большая), то все становится как-то значительно медленее
сейчас буду литературу изучать, может я супер тупой (не отрицаю), но блин...
когда таблица растет (и не такая уж и большая), то все становится как-то значительно медленее
EN
допустим, не помню таких трабл в ElasticSearch...
AZ
10 тыс в секунду это очень медленно для 40 узлов, смотрите на дизайн ключа, на процесс вставки
AZ
кластер HDFS под hbase выделен, или там кто-то еще резвится?
EN
read orc, transform, write spark
AZ
так там аналитика также работает на этом кластере?
EN
кластер очень ненагруженный
есть мастер ноды, есть 40 дата нод.. всего 20++ТБ памяти, с дисками ок, сетка не загружена тоже
есть мастер ноды, есть 40 дата нод.. всего 20++ТБ памяти, с дисками ок, сетка не загружена тоже
EN
работает, что-то делают на хайвовских таблицах, но это реально понты..
AZ
тут дело не в нагрузке на сеть, дело в задержках дисков под hdfs, если вы много random write разбавляете каким-то количеством sequential read то все будет сильно хуже
AZ
я бы начал с того чтобы посмотреть на процесс вставки: сколько у вас экзекьюторов, какие они показатели дают, потом посмотреть на тот как hbase себя чувствует, идут ли какие компакции процессе вставки, таблица уже заспличена или идут сплиты, какая локальность, а потом смотрел на метрики hdfs
EN
окей, спасибо👍😊
AZ
если вам нужна высокая стабильная производительность hbase то лучше его разводить с аналитикой на отдельные кластера, в крайнем случае делать трюк со сторадж политикой, когда вся директория /hbase размещена на отдельных дисках
AZ
по моей памяти 2U dual socket машины класса DL380 (12 7200 RPM дисков) в 2011-2012 году спокойно принимала 15-20 тыс операций в секунду на каждый регион сервер
AZ
а вообще лучше ехать в клауд, как известно лучший hbase - это google bigtable
AS
я вчера попробовал в таблицу 170мл вставить еще 50млн и не отработало за 1.5ч
как вставляли, batch или по одной записи?
AZ
я предполагал что балк лоад им не подходит (например кластер в репликации, или какие-то другие причины)
AZ
в любом случае конкретный тормоз это не повод сразу менять СУБД)