Здравствуйте, kaa.python, Вы писали:
KP>Интересно, спасибо! Да мне, в принципе, пофигу будет там SQL ли нет. У нас сквозные индексы (GUID) и если я смогу посчитать как угодно, выводы будут корректными.
Ну я это просто к тому, что не надо учить какой-то эзотерический язык запросов чтобы опрашивать их вьюхи. Для клиентов оно должно выглядить как обычная SQL БД.
Здравствуйте, kaa.python, Вы писали:
KP>Они себя зарекомендовали как полные профаны в вопросе обеспечения надежности и качества. Так как мы маленький стартап, то позволить себе ПО которое разработано подобной компанией просто не можем
Ой ладно, а у aws подобного в свое время не было? Как это оносится к ClickHouse?
Здравствуйте, Sharov, Вы писали:
S>Ой ладно, а у aws подобного в свое время не было? Как это оносится к ClickHouse?
Относится самым непосредственным образом. Если компания не может обеспечить адекватного уровня контроля качества даже для коммерческих продуктов (рекомендую внимательно посмотреть на тот инцидент что я привел, это просто детский сад), то пользоваться их открытыми продуктами не обеспеченными серьезной поддержкой сообщества в коммерческой разработке тем более опасно.
Здравствуйте, kaa.python, Вы писали:
KP>Относится самым непосредственным образом. Если компания не может обеспечить адекватного уровня контроля качества даже для коммерческих продуктов (рекомендую внимательно посмотреть на тот инцидент что я привел, это просто детский сад), то пользоваться их открытыми продуктами не обеспеченными серьезной поддержкой сообщества в коммерческой разработке тем более опасно.
Первый же комментарий по ссылке:
Ну случается. У маленьких случается, у больших случается. В облаках случается, на земле случается.
Если у чувака потерялись критичные данные, значит он неправильно оценил риски и пролюбил стратегию резервного копирования.
Яндексу минус. Чуваку минус.
В остальном ситуация вполне рядовая. Яндекс чуваку шоколадку должен адекватную — явно не с небоскреб размером.
И опять же, по каждому продукту надо смотреть индивидуально -- своя специфика, своя история, совершенно разные люди могут заниматься этими продуктами. К тому же CH в самом Яндексе используется, соотв. протестирован вдоль и поперек.
Здравствуйте, wildwind, Вы писали:
W>Пока только присоединюсь к уже озвученным советам посмотреть на другие СУБД, более заточенные под вашу нагрузку. W>Вот из свежего: https://umbra-db.com/
Это уж слишком свежо, чуть ли не вчера (буквально) анонсировано. Насколько я знаю, Нойманн создал Амбру после того, как продал свое предыдущее детище (HyPer), позаимствовав оттуда идеи.
Вообще, мужик обладает какой-то нечеловеческой продуктивностью, учитывая, что он декан магистратуры-аспирантуры в универе, читает несколько курсов, публикует 2-3 статьи в год на всяких SIGMOD и еще у него что-то типа 3-х детей. При этом в одиночку создает СУБД, которые затем покупают серьезные конторы типа Tableau и еще доплачивают ему как консалтеру потом. Я общался с парой его аспирантов, он реально кодит сам.
Здравствуйте, Sharov, Вы писали:
S>К тому же CH в самом Яндексе используется, соотв. протестирован вдоль и поперек.
Имел счастье радость испытать это "протестирован вдоль и поперек". Их слоган "КХ не тормозит" — истинная правда: при сбое в синхронизации узлов кластера 200000 записей он удалил буквально на глазах за какие-то секунды, только рот от удивления открыть успел.
Справедливости ради, сейчас это действительно продукт, которым можно пользоваться. Статистику считает вполне бодро, и тут он действительно хорош. Но обновлять его надо только при большой нужде. И копию данных лучше все-таки иметь.
Здравствуйте, kaa.python, Вы писали:
KP>Есть относительно большой объем данный по которому на лету (пользователь крутилки крутит) надо считать разную статистику, предварительно посчитать которую не представляется возможным — правила подсчета довольно гибкие. На данный момент все лежит в одной базе Postgres и занимает около 200Гб, из которых в активном подсчете участвуют около 100Гб почти сплошь являясь индексами. Растет объем довольно бодро и к концу года по моим прикидкам должно быть около 400-500Гб. KP>Система начинала было затыкаться, …
То есть, проблема, которую требуется сейчас решить — поскорее "считать разную статистику", правильно?
Вы разбирались с тем, откуда появляются "затыки"?
Просто ли это объём обрабатываемых данных или "помноженный" (грубо говоря) на частоту записей?
То есть, при тех же объёмах, но в режиме "рид онли" на сколько всё лучше? На сколько резво нужно в расчётах учитывать недавно добавленные данные?
Анализировали планы запросов, нельзя ли как-то оптимизировать индексы?
KP>Если же говорить про сами расчеты, то это различные суммы, минимум/среднее/максимум по группам, ну и само собой фильтрация входных данных для расчетов.
Все перечисленные метрики отлично поддаются пред-агрегации (другое дело медиана, например).
Выбираете нужные вам измерения (поля, по которым необходима группировка и фильтрация; в том числе время — дни/часы/минуты, смотря какая точность вам нужна) и подсчитываете метрики ("различные суммы, минимум/среднее/максимум"; для среднего нужен будет ещё и вес) по этим самым группам. С некой периодичностью пересчитываете их и добавляете новые строки. При построении отчёта досчитывыете эти пред-агрегаты.
Я немного не в курсе Postgres и не понял про массивы в данных. Можно пример?
Help will always be given at Hogwarts to those who ask for it.
я бы съехал с постгре,
если денег нет или религия не позволяет на greenplum (постгре перепиленый на колоночное хранение и аналитику)
если деньги есть на mssql columnstore
Здравствуйте, rm822, Вы писали:
R>я бы съехал с постгре,
Полностью съезжать не рационально, основная масса данных, кроме аналитики, отлично ложится на Postgre и на его особенности куча кода завязана.
R>если денег нет или религия не позволяет на greenplum (постгре перепиленый на колоночное хранение и аналитику) R>если деньги есть на mssql columnstore
Есть оба фактора не позволяющие использовать решения МС
За GreenPlum спасибо, как руки дойдут погляжу и на него и на ClickHouse, надо была наших данных тесты погонять.
Звучит как задача для time series database, постгрес для этого подходит плохо.
Хорошо полходят специализированные вещи вроде prometheus — но неочевидно, подойдут ли они вам
Здравствуйте, blp, Вы писали:
blp>Звучит как задача для time series database, постгрес для этого подходит плохо. blp>Хорошо полходят специализированные вещи вроде prometheus — но неочевидно, подойдут ли они вам
Я смотрю в сторону column-oriented (как по-русски это принято переводить?) баз данных, как одно из решений. Просто была надежда что кто-либо опытом поделится, про подводные камни расскажет. Пока что тесты показывают очень хороший прирост производительности при использовании секционирования
KP>А есть опыт с этой штукой? А то Я — это не та компания к которой есть безусловное доверие...
Есть опыт. Крутая штука. Для Ваших целей нужна именно колоночная аналитическая DB, и ни в коем случае не релляционная. Что касается CH-то это на текущий момент одна из лучших колоночных аналитических СУБД. У нас в CH сейчас имеется база порядка 800 TB данных. Подсчёт агреагатов на лету с применением фильтров, проходит в пределах десяти секунд если затрагиваются все данные. Доли секунды если отфильтровываются отдельные партиции. На диске всё это отлично жмётся, опять таки специфика колоночных DB. Вот только это не релляционная DB и тем, кто привык работать именно с релляционками, поначалу будет очень непривычно.
Здравствуйте, smeeld, Вы писали:
S> Вот только это не релляционная DB и тем, кто привык работать именно с релляционками, поначалу будет очень непривычно.
А можно пару примеров этой разницы? Насколько я понял, там почти стандартный SQL, да и база данных реляционная. Или речь не о ClickHouse, а о чем-то другом?
UPD. да, почитал обзор, вроде ограничения меня полностью устраивают.
KP>А можно пару примеров этой разницы? Насколько я понял, там почти стандартный SQL, да и база данных реляционная. Или речь не о ClickHouse, а о чем-то другом?
Там SQL-like, а не SQL. Исключительно чтоб привыкшим к SQL удобнее работать было, включая авторов. Но различий много, например совсем другие JOIN-ы. Собственно, вся релляционность CH именно этим и ограничивается, SQL-ем и и таблицами в которые данные вносятся строками и извлекаются строками. Но внутри это именно колоночная база, где каждая колонка в таблице-это как отдельная таблица DB. Значения в разных колонках и одинаковой позиции в строке таблицы связываются через метданные. Отсюда и подходы к организации данных. Желательно создавать широкие таблицы содержащие все нужные колонки и данные закидывать в таблицу как в лог, непрерывным потоком.
ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение, просто после копирования данных в экспериментальную базу еще и под Docker (2 Gb, 4 CPU). Теперь надо придумать как все это соединить в кучу с основной базой
Здравствуйте, kaa.python, Вы писали:
KP>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение
и всего-то? а сколько хайпу было
Здравствуйте, rm822, Вы писали:
R>Здравствуйте, kaa.python, Вы писали:
KP>>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение R>и всего-то? а сколько хайпу было
Насколько это "всего-то" пока сказать сложно. Ещё гора открытых вопросов, но данная опция, на первый взгляд выглядит как потенциальное решение.
Здравствуйте, kaa.python, Вы писали:
KP>>>ClickHouse впечатлил, спасибо всем его рекомендовавшим. Запросы без какой-либо оптимизации показывают десятикратное ускорение
чо тогда ClickHouse а не Prometheus?
