VO
Size: a a a
2020 December 21
DP
понятно, идея действительно так себе
Am
а то у коллег появилась дурная идея туда кликхаусовские базы сунуть
Выглядит как «мы ни зуя не знаем поэтому давайте положим кх в цеф потому что читать что такое кх лень»
ВН
это ты про запись на ec сказал? а если там чтение?
Ну чтение не имеет этого прикола с readmodifywrite, но как кликхаус себя чувствует в цефе - тут хз. Ну так, умеренно жопно по идее, если просто с хардами сравнить
VO
Выглядит как «мы ни зуя не знаем поэтому давайте положим кх в цеф потому что читать что такое кх лень»
э, почему?
VO
Ну чтение не имеет этого прикола с readmodifywrite, но как кликхаус себя чувствует в цефе - тут хз. Ну так, умеренно жопно по идее, если просто с хардами сравнить
ну раза в четыре тормознее будет?
Am
э, почему?
Потому что кх сам по себе охуенно масштабируется. Или ты думаешь яндекс метрика на одном серваке жила когда они это проектировали
VO
латенси будет не 14мс, а под 40мс?
VO
Потому что кх сам по себе охуенно масштабируется. Или ты думаешь яндекс метрика на одном серваке жила когда они это проектировали
а. не начем им масштабироваться.
Am
Наверно на то эм на чем они цеф собирать собрались
VO
а в цефе типа места больше чем на тех серваках (или виртуалках) что у них есть
VO
цеф уже есть
VO
кторый под s3
VO
вот у них родилась идея сделать там пул под rbd
ВН
ну раза в четыре тормознее будет?
Да как бы... как мерить, с чтением на хардах вроде обычно не так всё плохо по сравнению с просто хардом, если метаданные в памяти
Am
Ну вот отпилить от цефа необходимое количество нод это будет более рационально и эфективно в разрезе кх
ВН
Ну т.е. у меня в тестах вроде даже более-менее близкие к самому харду показатели на чтение по иопсам
VO
Ну вот отпилить от цефа необходимое количество нод это будет более рационально и эфективно в разрезе кх
чё-чё-чё? на цефе ноды по 30 hdd. больно жирно отпиливать
ВН
В параллель собственно даже получше
VO
т.е. зависит от потока записи, получается. может и не так ужасно и даже юзабельно.