Ого, а расскажешь? Интересно даже юз кейсы послушать

В обмен на юзкейсы Тарантула в яндексе :)

все используют CH много где %)

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

мы скоро про наш юз кейс будем рассказывать в Мадриде, https://indico.dns-oarc.net/event/26/session/5/contribution/21

А вот правда ребят, есть у кого то кейсы использования CH не для аналитики кликов/посещений/access логов ?

ну вот выше, DNS :)

ага, вот смотрю. Интересно)

А вот правда ребят, есть у кого то кейсы использования CH не для аналитики кликов/посещений/access логов ?

Тинькофф вроде че-то платежное там хранил

О, Денис. Добро пожаловать :)

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

Тинькофф вроде че-то платежное там хранил

Да видел я их пост на хабре про выбор хранилища. На середине просто закрыл страницу)

Виктор, спасибо! Я просто слышал, что используется.

Я пробовал у нас, не пошло :)

У вас это в метрике?

Да.

Нужен был нормальный k-v, быстрый, отказоустойчивый и распределённый

С распределннотью пока проблема

Остальное все есть

Redis :)

Да, поэтому и отложили. У нас данных многовато.

Но появилось внутреннее хорошее решение

мы тоже потенциально рассатривали тарантул, но не пошло, выбрали редиску

Редис не отказоустойчив

Но появилось внутреннее хорошее решение

Какое?

Redis распределённый? Это с каких пор?

Ну и отказоустойчивость нет же

Не распределеный

Да

Появился мощный k-v на основе внутреннего mapreduce. Быстрый и очень масштабируемый.

тем не менее под задачи подошел ваше ок)

Появился мощный k-v на основе внутреннего mapreduce. Быстрый и очень масштабируемый.

Пока закрытый?

Увидимся, расскажу :)

Да

Давай :)

Закрытый, потому что на внутренние потроха сильно завязан?

По сути да. Это часть YT, нашего mapreduce решения.

По сути да. Это часть YT, нашего mapreduce решения.

Вы его используйте как буфер для данных, что ещё в клик не ушли?

Для разных целей. Вебвизор, например, чистый k-v.

Хотим пользовательскую историю также там обновлять, пока не сделали.

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

А что в качестве буфера?

Кстати недавно был доклад, где рассказывали про YT: https://events.yandex.ru/lib/talks/4103/

В качестве буфера кастомный код.

Почему он не часть клика?

Сложный вопрос :)

YT вообще говоря более сложная и большая система.

я вот ною в тикетах и прошу сделать батчер :)

ибо под каждый проект каждый городит свой батчер, это надоедает

Правильно ноешь :)

Батчер нужен.

А вот правда ребят, есть у кого то кейсы использования CH не для аналитики кликов/посещений/access логов ?

Я пытаюсь собирать всякую статистику по нашему графиту

ибо под каждый проект каждый городит свой батчер, это надоедает

Можем тарантул сделать таким батчером

слишком сложный и большой

я себе это вижу как реализацию в либе https://github.com/artpaul/clickhouse-cpp/issues/11

по крайне мере в С++ все возможности для этого есть

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

Или кликхаус принципиально не используется с разделением на горячие и холодные данные?

Владимир, шикарный вопрос.

И он как раз к теме батчера

я могу рассказать, какой кейс у меня лично

О, давайте!)

я коплю в CH трафик и за последние 10 минут он мне нужен горячий, а все прочее - пока диски не кончатся.

Есть возможность использовать батчинг очень простым способом: - открыть соединение, отправить запрос INSERT и начать отправлять данные. Далее, каждый раз, когда приходит следующая строчка, сразу же отправлять её туда же. По достижению порога на число строк или прошедшего времени, завершать отправку данных.

сейчас 10 минут хранятся в приложении, внутренний буфер и дополнительно отправляются в буфер таблицу в кликхаусе

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

НО очень хочется в обоих случаях делать запрос к CH, просто горячие данные держать в оперативке, а-ля буфер таблице, но быстрой, сейчас буфер довольн омедленный особенно если вставляешь данные поштучно туда...

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

НО очень хочется в обоих случаях делать запрос к CH, просто горячие данные держать в оперативке, а-ля буфер таблице, но быстрой, сейчас буфер довольн омедленный особенно если вставляешь данные поштучно туда...

Вы прямо описываете структуру приложения на kdb :)

kdb?

kx.com / база kdb, язык q

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

Есть инстанс in-memory, который принимает огромный поток текущих данных, ну и быстро отдает запросы по нему, и есть инстанс, который читает предыдущие дни с диска. В конце дня память сбрасывается на диск.

это очень похоже на linux write pack

ой, write back :)

пока есть оперативка / не сработал таймер все в памяти, кончилась - пишем на диск

Есть инстанс in-memory, который принимает огромный поток текущих данных, ну и быстро отдает запросы по нему, и есть инстанс, который читает предыдущие дни с диска. В конце дня память сбрасывается на диск.

Вот я поэтому и подумал про тарантул в качестве буфера.

это еще один формат схемы, вот в чем еще проблема

я бы с радостью работал в формате CH с обоими стораджами

Это верно

Лучше единый sql поверх обоих хранилищ

именно так

сейчас с одним я говорю на capnp, с другим на CH SQL ;)

А если ещё сделать автоинтеграцию с QlikView, то все интерпрайзы кипятком бы писали от этого

А если ещё сделать автоинтеграцию с QlikView, то все интерпрайзы кипятком бы писали от этого

Tableau?

Вот я поэтому и подумал про тарантул в качестве буфера.

А нельзя это осуществить в пределах одного CH? Memory есть, а в конце дня скидывать mem во что-то дисковое?

У QlickView свой формат данных на диске и свой инмемори движок, там некуда внешнее хранилище вкорячивать.

У QlickView свой формат данных на диске и свой инмемори движок, там некуда внешнее хранилище вкорячивать.

Но можно в его файлы писать. Формат отреверсить не проблема.

А нельзя это осуществить в пределах одного CH? Memory есть, а в конце дня скидывать mem во что-то дисковое?

Можно. Надо только кода написать чуть чуть.

На самом деле поставить Tarantool буфером перед КХ очень здравая идея, так можно и row-based security добавить и всякие enterprise-аутентификации.

Но по нему не будет sql

Но можно в его файлы писать. Формат отреверсить не проблема.

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

А нельзя это осуществить в пределах одного CH? Memory есть, а в конце дня скидывать mem во что-то дисковое?

Без лога потеряешь данные за один день в случаи падения сервера

всем привет

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

Да, но тогда экономия на диске знатная. Нет промежуточного хранения

Без лога потеряешь данные за один день в случаи падения сервера

Ну тут уже дело техники - можно и в память и в какой-то буфер на диск.

Да, но тогда экономия на диске знатная. Нет промежуточного хранения

Tarantool -- как виртуальный сторадж файлов Клика?