@clickhouse_ru

« Назад

Страница 98 из 723

Далее »

Dmitrii

24.03.2017
21:47:07

исходная БД — PostgreSQL. Там все разложено по таблицам

Вот теперь думаю как это вообще можно реализовать, и поможет ли мне тут такой вот трюк с колоночной базой.

Первая идея мая была завести кучку таблиц в Pg, чтобы туда писать "факты" а потом пересекать и фильтровать.

Но идея бредовая т.к. не масштабируется совсем.

Google

Roman

24.03.2017
21:48:42

Стоп :)

Dmitrii

24.03.2017
21:48:44

Да и Pg с его MVCC помрет

Стою )

Roman

24.03.2017
21:48:59

Что у вас есть 'факт'?

Dmitrii

24.03.2017
21:50:05

Допустим, это может быть "тип контракта", "сколько часов я могу работать в этом месяце", "сколько часов осталось", "сколько денег я заработал", "как далеко я от соседасейчас нахожусь" и так далее

Таких штук может быть неограниченое кол-во

Roman

24.03.2017
21:50:23

Это не факты

Факты это информация непосредственно связанная с регистрируемым событием

Dmitrii

24.03.2017
21:51:10

Ну у меня событий как таковых нет

Есть только информация о пользователе, его состояние на момент времени t

И все вот эти значения надо взять и сравнить

Roman

24.03.2017
21:51:50

Событие у вас - это изменение состояния пользователе

Dmitrii

24.03.2017
21:51:56

Выбрать X пользователей а потом отсортировать

Google

Roman

24.03.2017
21:52:56

Так все-таки какие у вас события?

Изменение состояния пользователя? Его действие какое-то?

Dmitrii

24.03.2017
21:53:36

Ну у меня нет ни "кликов" ничего такого

Roman

24.03.2017
21:53:51

Я не про клики же

Dmitrii

24.03.2017
21:53:56

Просто есть очень большое кол-во атрибутов по которым надо сделать фильтр а потом rank

Roman

24.03.2017
21:53:57

Выше написал

Dmitrii

24.03.2017
21:54:23

Измений тоже нету. Есть только "срезы" пользователей по критериям

Но не все пользователи из каждого среза в конечном счете "подойдут"

Каждый срез может быть получен из разных источников по разным критериям.

Roman

24.03.2017
21:56:14

Измений тоже нету. Есть только "срезы" пользователей по критериям

Событий нет, изменений нет... ничего у вас в базе не происходит? так что же вы там нарезаете тогда? Сколько у вас всего строк во всех таблицах?

Dmitrii

24.03.2017
21:56:41

Сейчас система на стадии проектирования. Ищется оптимальное решение под задачу

Просто представьте себе 1М пользователей.

И у каждого куча всяких настроек и сосояний

Roman

24.03.2017
21:57:48

Поэтому тема с обычным SQL запросом в принципе не рабочая

Резюмируя -- я так и не понял ваш контекст :( Но если вы уверены, что SQL вам не подходит, то вряд ли подойдет ClickHouse, тк в нем как раз используется SQL.

Dmitrii

24.03.2017
21:58:00

Теперь представьте, что оно лежит в Pg. И вот на момент времени t был запущен запрос, который выбрал 50к человек. Потом еще один — выбрал 200к

Да, но почему я собственно подумал про кликхауз потому что у меня есть много атрибутов — сразу вспомнил про колоночные базы

И у меня будет много записи в базу (а Pg это не переваривает особо)

Roman

24.03.2017
21:59:46

Да, но почему я собственно подумал про кликхауз потому что у меня есть много атрибутов — сразу вспомнил про колоночные базы

Ну тут ведь вопрос не в данных, а в том что вы с ними делаете :)

Данные можно хоть в CSV на диске держать :)

Dmitrii

24.03.2017
22:00:24

В итоге мне конечно надо получить отсортированый сет пользователей, по куче условий с определенной сортировкой

Google

Dmitrii

24.03.2017
22:00:45

Но это нереально сделать на одном инстансе обычной базы

Она загнется рано или поздно

Roman

24.03.2017
22:01:21

Она загнется рано или поздно

Почему?

Как задачу регистрации/учета данных решить вы знаете? Ну нормализацию и все такое умеете? Значит, класть в базу данные вы сможете.

Dmitrii

24.03.2017
22:02:36

Подход с JOIN блокирует меня для шардирования данных, а это одно из условий для аритектуры проекта

Roman

24.03.2017
22:03:03

Подход с JOIN блокирует меня для шардирования данных, а это одно из условий для аритектуры проекта

Шардирование для 1М строк? Зачем?

Dmitrii

24.03.2017
22:03:04

Там данные одного города вообще не относятся к данным другого грубо говоря

Потому что проект должен работать и в US и в EU

И падение базы не должно затрагивать все регионы

Roman

24.03.2017
22:04:27

В общем, если вы сложите в Clickhouse данные по 1М*М клиентов с 1000 атрибутов, то все у вас будет ОК.

Но Clickhouse база не для первичного учета.

Dmitrii

24.03.2017
22:05:36

Ну у меня основная база это Pg так и останется

Просто есть определенный функционал — cost estimator он имеет достаточно сложную логику

И в общем случае при падении CH как бы пофигу

Roman

24.03.2017
22:07:15

Ну у меня основная база это Pg так и останется

При копировании данных в КХ вам нужно будет сделать денормализацию -- свести все к небольшому кол-ву мега-таблиц (лучше к одной), окруженной десятками и сотнями таблиц атрибутов (см ключевое слово 'словарь' в длке по КХ)

Просто есть определенный функционал — cost estimator он имеет достаточно сложную логику

Я кажется начал понимать ваш контекст. КХ вам может помочь, но при условии денормализации данных.

Dmitry

24.03.2017
22:09:14

Попробуйте для этой задачи ElasticSearch

Dmitrii

24.03.2017
22:09:55

Что то даже не думал в эту сторону

Roman

24.03.2017
22:10:19

Да, ES по контексту подходит!!

Dmitry

24.03.2017
22:10:25

Посмотрите. Он довольно хорошо себя зарекомендовал как раз под такие задачи

Google

Dmitry

24.03.2017
22:10:44

И объем в 1млн строк - это ерунда для него, даже с 1000 атрибутами

Dmitrii

24.03.2017
22:12:26

Спасибо. Буду исследовать вопрос. Задача не тривиальная стоит ?

Alexey

24.03.2017
23:57:25

Добрый день всем. Сейчас данные льются в mongodb, решили прикрутить КХ для расширенной аналитики. Протестировали, все здорово. И встал вопрос - а нужна ли теперь в проекте mongodb. Проблема в чем: пользователям нужно забирать собранные данные. В монге завели автоинкрементное поле и на основе его забираем свежие данные порциями. Особенность входных данных в том, что дата/время этих данных может быть в прошлом. Мы решили добавить в КХ колонку (processedTime Int64), которая хранит дату обработки данных в миллисекундах. И на основе этой колонки можно отдавать пользователю свежие данные. Что посоветуете? Можно ли ставить один КХ на бэкенд, если будет одновременно сидеть 100/200/500 пользователей с короткими запросами типа: SELECT field1, field2, field2 FROM table WHERE date > '2017-03-23' AND userId = 123 AND processedTime > 546545454 ORDER BY processedTime DESC LIMIT n,20 И такими: SELECT field1,reportDate, count() as total FROM table WHERE date > '2017-03-01' AND userId = 123 GROUP BY field1, reportDate HAVING total > 10 ORDER BY total DESC

Если первичный ключ - (userId, date), а количество таких запросов в секунду меньше сотен, то должно быть нормально.

Magistr

25.03.2017
04:26:17

Просто есть определенный функционал — cost estimator он имеет достаточно сложную логику

hbase может быть ? если скорость ответа неважна

Igor

25.03.2017
11:29:12

to tabix users, чтобы не оффтопить в этом чате о новых билдах и фичах - буду писать в твиттер https://twitter.com/tabix_io

Pavel

25.03.2017
11:32:19

зафолавил

Square

25.03.2017
12:00:11

to tabix users, чтобы не оффтопить в этом чате о новых билдах и фичах - буду писать в твиттер https://twitter.com/tabix_io

Тогда уж в телеге канал бы

Dig

25.03.2017
13:17:07

Если первичный ключ - (userId, date), а количество таких запросов в секунду меньше сотен, то должно быть нормально.

Спасибо, будем пробовать.

Renat

25.03.2017
19:21:04

2017.03.25 18:40:11.787286 [ 2 ] <Error> default.events_sid (Data): Considering to remove broken part /opt/clickhouse//data/default/events_sid/20170322_20170325_11895754_11895754_0 because it's impossible to repair. 2017.03.25 18:40:12.279264 [ 1 ] <Error> Application: DB::Exception: Cannot create table from metadata file /opt/clickhouse/metadata/default//events_sid.sql, error: DB::Exception: Suspiciously many (54) broken parts to remove., stack trace: Какие могут быть причины? как с этим бороться, если нет репликации?

Veniamin

25.03.2017
19:32:46

Привет, а это нормально https://github.com/yandex/ClickHouse/issues/629 ?

prll

25.03.2017
19:33:59

нет, а старые версии работали ?

Veniamin

25.03.2017
19:35:07

нет, а старые версии работали ?

Я только поставил, stable ветка из репы

prll

25.03.2017
19:38:24

можно попробовать собрать из исходников

Veniamin

25.03.2017
19:44:26

можно попробовать собрать из исходников

Лучше пакетом

Vitaliy

25.03.2017
19:47:05

Привет, а это нормально https://github.com/yandex/ClickHouse/issues/629 ?

Нет. А конфиги вы не меняли? Таблички создавли? До этого еще человек жаловался, но пока не получилось нигде воспроизвести.

prll

25.03.2017
19:47:07

если падает - надо проводить расследование

Veniamin

25.03.2017
19:47:34

Нет. А конфиги вы не меняли? Таблички создавли? До этого еще человек жаловался, но пока не получилось нигде воспроизвести.

apt-get install clickhouse-base-server clickhouse-client Больше ничего не делал вообще

Alexey

25.03.2017
19:47:51

Ответ: https://github.com/yandex/ClickHouse/issues/629#issuecomment-289235004

Veniamin

25.03.2017
19:50:24

Ответ: https://github.com/yandex/ClickHouse/issues/629#issuecomment-289235004

Спасибо, понял.

prll

25.03.2017
19:53:38

при перезапуске сервиса clickhouse-server ругань есть про процессор ?

Google

Veniamin

25.03.2017
19:56:00

при перезапуске сервиса clickhouse-server ругань есть про процессор ?

Неа, не было.

Я уже запустил на FreeBSD

prll

25.03.2017
19:56:48

с портов или самосбор ?

Veniamin

25.03.2017
19:57:03

с портов или самосбор ?

С портов

prll

25.03.2017
19:57:16

заработало-запустилось?

Veniamin

25.03.2017
19:57:17

Сейчас багу отпишу, уже вижу что не работает

заработало-запустилось?

Запустилось, смог в консольку зайти, но пока ничего не пробовал

Aleksey

25.03.2017
21:06:51

Привет! Подскажите, пожалуйста, насколько это критично: Not executing log entry for part 20160601_20160630_464_1663_7 because its size (1.66 GiB) is greater than current maximum (4.23 MiB).

Alexey

25.03.2017
21:07:27

Это штатная работа сервера.

Aleksey

25.03.2017
21:08:44

А, т.е. репликация жива, отлично, спасибо

Alexey

25.03.2017
21:09:57

Суть сообщения: При выполнении фоновых слияний, сервер балансирует их работу: если уже выполняется достаточно много слияний, то в данный момент времени можно назначить только достаточно короткие слияния.

Aleksey

25.03.2017
21:10:40

Понял, большое спасибо!

f1yegor

25.03.2017
21:59:10

Who has not yet voted for ClickHouse support in Tableau?! Please do it here https://community.tableau.com/ideas/6454 It is necessary to have at least two hundred upvotes to come into Tableau Dev Team's plans.