"ссылки на сам Яндекс не считаются независимыми" вот это маразм дичайший. Какого хера ?

если яндекс это разработчик, где по их мнению должны размещаться ссылки?

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

субъективщина чистой воды

https://ru.wikipedia.org/wiki/MongoDB

в чем различие?

пусть в статье вики укажут ссылку на гитхаб с исходниками, мало ли

в чем различие?

Как минимум в Литература Кайл Бэнкер. MongoDB в действии = MongoDB in Action. — ДМК Пресс, 2014. — 394 с. — ISBN 978-5-97060-057-3. Kristina Chodorow. MongoDB: The Definitive Guide, 2nd Edition. — O'Reilly Media, Inc., 2013. — 432 с. — ISBN 978-1-4493-4468-9. David Hows, Peter Membrey, Eelco Plugge, Tim Hawkins. The Definitive Guide to MongoDB: A complete guide to dealing with Big Data using MongoDB, Third Edition. — Apress, 2015. — 376 с. — ISBN 978-1-4842-1183-0. Eelco Plugge, Peter Membrey, Tim Hawkins. The Definitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing. — Apress, 2010. — 327 с. — ISBN 1-4302-3051-7. Mithun Satheesh; Bruno Joseph D'mello; Jason Krol. Web Development with MongoDB and NodeJS - Second Edition. — Packt Publishing, 2015. — 300 с. — ISBN 978-1-78528-745-9. Steve Hoberman. Data Modeling for MongoDB. — Technics Publications, 2014. — 226 с. — ISBN 978-1-935504-70-2. Mitch Pirtle. MongoDB for Web Development. — Addison-Wesley Professional, 2011. — С. 360. — ISBN 9780321705334.

Плюс в примечаниях ещё есть

я ж говорю, добавить в примечение ссылки на гитхаб и на тот же habrahabr (там статей хуева туча)

я ж говорю, добавить в примечение ссылки на гитхаб и на тот же habrahabr (там статей хуева туча)

На хабре статьи от Яндекса, можно на бложик Cloudflare ссылки дать.

не только от яндекса

Тут статью в википедии собираются удалять https://ru.wikipedia.org/wiki/Википедия:К_удалению/15_августа_2018#ClickHouse

и абсолютно правильно собираются. Не понимаю вашего возмущения. Статья действительно незначима.

https://habr.com/post/322620/ https://habr.com/post/324846/ https://habr.com/company/oleg-bunin/blog/351308/ как минимум они не от яндекса

про монго статья гораздо более ёмкая и имеет хоть какой-то смысл.

Возмущение в том, что причины высосаны из пальца

А в статье о кликхаусе просто перевод документации (или копипаста, я не знаю). Имхо, я согласен с тем, что статья не значима в смысле википедии и ей там (в том варианте, в котором она сейчас лежит) не место

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

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

википедия не для этого придумана, не для знакомства с.

А для чего?

и для знакомства в том числе

ну сама по себе статья ничего нового по сравнению с документацией не превносит. Хотелось бы увидеть отдельным разделом упоминания, отдельным — список проектов, которые используют, отдельным — мнения о том, почему кликхаус хорош, почему плох, с кем его корректно сравнивать, с кем — нет. тогда это было бы да. А так — эту информацию любой интересующийся кх и так найдёт, а тому, кто не интересуется конкретно кх, это не будет полезно, мне кажется. хотя, как знать.

Ну мне кажется что статья быть дожна, как минимум потому что в статье про колоночные СУБД должны быть ссылки на статьи и по Vertica и по Clickhouse

Очевидно что каждый останется при своем мнении

Да, это верно. Статья быть должна, с этим я и не спорю. > ссылки на сам Яндекс не считаются независимыми. это хороший аргумент.

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

Не могу с вами согласиться)

так что не все так однозначно

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

у меня точно та же история.

Ну мне кажется что статья быть дожна, как минимум потому что в статье про колоночные СУБД должны быть ссылки на статьи и по Vertica и по Clickhouse

ну вертика там упоминалась а кх нет

и это мягко говоря странно

вот вот

и еще там упоминаются гуглячьи решения, которые вообще исключительно внутренние

что еще страннее

Ну так можно же сделать правку и упомянуть там кх! и это будет как раз уже аргументом: статья востребована и дополняет энциклопедию.

логично

Ну так можно же сделать правку и упомянуть там кх! и это будет как раз уже аргументом: статья востребована и дополняет энциклопедию.

ну это ж логиниться надо...

То есть надо не исправлять статью, чтобы её не удалили, а подумать, зачем она действительно нужна, и показать это остальным — что мы, вроде как, и поняли. А дальше уж тот, кому не лень, залогинится, может даже кто-нибудь из Яндекса найдёт время :)

Всем привет! Вчера на митапе в СПБ говорилось про табличную функцию odbc наряду с другими табличными функциями, но в документации по ней информации нет (а по другим есть). Где можно найти информацию?)

Всем привет! Вчера на митапе в СПБ говорилось про табличную функцию odbc наряду с другими табличными функциями, но в документации по ней информации нет (а по другим есть). Где можно найти информацию?)

odbc (odbc connect string, table)

https://github.com/yandex/ClickHouse/blob/508b0fbd346d489e1ebb4b448e72f236c8b07a92/dbms/src/TableFunctions/TableFunctionODBC.h#L11

Дальше описание имеется

Спасибо!

добрый день! А можно где-то увидеть презентации по вчерашнему митапу в Питере?

добрый день! А можно где-то увидеть презентации по вчерашнему митапу в Питере?

Я полагаю, что Алексей чуть позде выложит все и напишет

Спасибо

Вообще рано или поздно все презентации выкладываются тут https://github.com/yandex/clickhouse-presentations

Поправил статью на википедии, думаю теперь должно быть ок. Почитайте / поправьте если что-то плохо получилось, или очепятки какие-то. https://ru.wikipedia.org/wiki/ClickHouse

Всем привет! Гружу данные в clickhouse из CSV. В данных есть ip-адрес в виде строки. Могу ли я в инсерте сделать IPv4StringToNum?

и правильно ли я понимаю, что ip-адрес лучше хранить в UInt?

Всем привет! Гружу данные в clickhouse из CSV. В данных есть ip-адрес в виде строки. Могу ли я в инсерте сделать IPv4StringToNum?

Нет, но можете через временную таблицу перегнать.

Понял, спасибо

и правильно ли я понимаю, что ip-адрес лучше хранить в UInt?

Мы и IPv4 и v6 храним в одном поле, поэтому нам, например, для этого нужен FixedString(16)

Т.е. вы их не перегоняете в UInt, а прямо со строкой работаете?

Не мерили ли разницу с UInt?

Т.е. вы их не перегоняете в UInt, а прямо со строкой работаете?

нет, они лежат в бинарном виде

uint64+uint64 же

ну да, логично)

если в КХ нет встроенного бинарного типа мы используем FixedString для более компактного представления некоторых типов

Поправил статью на википедии, думаю теперь должно быть ок. Почитайте / поправьте если что-то плохо получилось, или очепятки какие-то. https://ru.wikipedia.org/wiki/ClickHouse

?

https://github.com/roistat/go-clickhouse вот тут люди похоже на уровне библиотеки превращают ip в num

Добрый день. Скажите пожалуйста, процесс репликации проходит через Zookeeper'ы, или ClickHouse ноды прямиком общаються друг к другу ?

Вот например я сделал Альтер

Как информация об этом накатывается на другие сервера ClickHouse ?

Информация о том что сервер проделал Альтер передается в Zookeeper, там все таблицы должны привезтись к такому же виду в Zookeeper, после чего другие ClickHouse сервера подтягивают изменения с Zookeeper, верно ?

Информация о том что сервер проделал Альтер передается в Zookeeper, там все таблицы должны привезтись к такому же виду в Zookeeper, после чего другие ClickHouse сервера подтягивают изменения с Zookeeper, верно ?

Там задачи в ZK для серверов в кластере ставятся и они их выполняют

То есть то что я выше написал правильно ?

То есть то что я выше написал правильно ?

Да, для репликации ведется лог и который пишется в ZK (не данные) и все сервера этот лог "проигрывают", напрямую они не общяются между собой, единственное обращение - это стягивание кусков по http

".... единственное обращение - это стягивание кусков по http...." Каких кусков ? самих данных ?

".... единственное обращение - это стягивание кусков по http...." Каких кусков ? самих данных ?

Да, данные в КХ кранятся кусками

То есть репликация идет не только через Zookeeker. Она сначала выполняется на Zookeeper, а потом данные передаются не посредственно между серверами

То есть репликация идет не только через Zookeeker. Она сначала выполняется на Zookeeper, а потом данные передаются не посредственно между серверами

Нет, там все примерно так: данные пишутся на диск, в ZK добавляется запись о новом куске в таблице, сервера видят что куска у них нет и скачивают его (упрощенно).

сырые данные по сайтам лучше собирать в разные базы и потом методом кластер стотроить общий отчет? или лучше все в одну базу пушить?

сырые данные по сайтам лучше собирать в разные базы и потом методом кластер стотроить общий отчет? или лучше все в одну базу пушить?

Пишите все в одну таблицу

Нет, там все примерно так: данные пишутся на диск, в ZK добавляется запись о новом куске в таблице, сервера видят что куска у них нет и скачивают его (упрощенно).

А теперь понятно) спасибо ! ?

А почему select toUInt64(111111) from table format JSON возвращает "1111111"

Кто нибудь сталкивался с таким?

потому что uint64

потому что uint64

В смысле? Почему интовое поле и без принудительного привидения возвращает стринг

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

потому что format JSON, не?

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

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

либо поменялся тип, либо поменялся output_format_json_quote_64bit_integers

либо поменялся тип, либо поменялся output_format_json_quote_64bit_integers

output_format_json_quote_64bit_integers │ 1

По всей видимости...

либо поменялся тип, либо поменялся output_format_json_quote_64bit_integers

Исправил, спасибо

Добрый день, есть возможность как нибудь ускорить WHERE t IN (SELECT ...), если известно, что возвращаемое во вложенном SELECT множество сортировано ?

Добрый день, есть возможность как нибудь ускорить WHERE t IN (SELECT ...), если известно, что возвращаемое во вложенном SELECT множество сортировано ?

Убедится что t в индексе и убедиться что у вас не сильно старая версия и она использует ПК для IN

Убедится что t в индексе и убедиться что у вас не сильно старая версия и она использует ПК для IN

У нас t - это tuple(test_id, tun_id), и оба они ПК: ORDER BY (test_id, id) и в таблице внутреннего SELECT, и во внешней таблице тоже. Можно ещё что-то сделать для того, чтобы ускорить эту часть запроса?