Как альтернатива это интересное решение, но потребовало бы дополнительного времени на стабилизацию и готовность предоставить как стабильный сервис. Это один из вариантов дальнейшего развития нашего кластера и мы доберемся до его аналитики.
Такой вариант не рассматривался. Это связано с нашей организацией работы с конфигурацией виртуалок. Для поддержки такого вида инсталляции нужно было переделать ansible-роль, и поддерживать ее отдельно. Это привело бы к отличиям этой инсталляции от других, а работать с ней может коллега из другой команды.
Виртуализация сейчас не доставляет проблем, это компромиссное и промежуточное решение, в перспективе пары лет, думаю, мы уйдем от нее.
По памяти у нас стоят ограничения в самом ClickHouse, как дополнительный этап отлова не оптимальных запросов на раннем этапе.
1.2 Tб сырых данных, на одну ноду/шард приходится ~4Тб SSD.
Храним по-разному, есть потоки данных которые хранятся постоянно и данные просто дописываются, есть с ограниченным временем жизни от пары недель и больше. Пока соблюдается баланс по тому за какой период могут быть нужны данные, но это тоже все обсуждаемо и изменяемо, появится потребность хранить дольше, начнем хранить дольше. Для каких-то данных используется репликация, есть данные, где она не нужна. В этом кстати есть своя сложность и гибкость одновременно, кластер можно настроить именно так как нам нужно, но для этого нужно потратить какое-то время на изучение документации.
Про размещение на HDD я с Вами полностью согласен. Прошлая инсталляция как раз и жила на HDD с SSD кешем и там были замечены странности и влияние на другие виртуалки. Пришлось добавлять лимиты по IOps, что конечно сыграло не в лучшую сторону для ClickHouse. С SSD были опасения, что можем упереться, но пошли на этот шаг, на данный момент эффекта не заметили. У нас есть понимание как можно расширить кластер, увеличить ему ресурсов и в дальнейшем переехать на отдельные инстансы. Скорее сейчас ловим какие-то другие проблемы из-за увеличения объема данных и количества запросов, но вот в SSD пока не упираемся.
Мы хотели использовать отдельные инстансы ClickHouse, но на тот момент у нас в наличии не было необходимого количества серверов и мы смогли бы реализовать только круговую репликацию, что нас не устраивало. В обозримом будущем мы планируем переехать на отдельные инстансы ClickHouse. Из-за этого ограничения мы как раз и пытались уместить все на существующем железе. Контейнеры не рассматривали изначально, для подготовки стабильного решения с их использованием, потребовалась бы дополнительное время на аналитику, к сожалению которого у нас не было. Мы уперлись в ограничения прошлой инсталляции кластера и нужно было быстрее переезжать в новый.
Как альтернатива это интересное решение, но потребовало бы дополнительного времени на стабилизацию и готовность предоставить как стабильный сервис. Это один из вариантов дальнейшего развития нашего кластера и мы доберемся до его аналитики.
Да, не так понял вопрос…
Такой вариант не рассматривался. Это связано с нашей организацией работы с конфигурацией виртуалок. Для поддержки такого вида инсталляции нужно было переделать ansible-роль, и поддерживать ее отдельно. Это привело бы к отличиям этой инсталляции от других, а работать с ней может коллега из другой команды.
Виртуализация сейчас не доставляет проблем, это компромиссное и промежуточное решение, в перспективе пары лет, думаю, мы уйдем от нее.
По памяти у нас стоят ограничения в самом ClickHouse, как дополнительный этап отлова не оптимальных запросов на раннем этапе.
1.2 Tб сырых данных, на одну ноду/шард приходится ~4Тб SSD.
Храним по-разному, есть потоки данных которые хранятся постоянно и данные просто дописываются, есть с ограниченным временем жизни от пары недель и больше. Пока соблюдается баланс по тому за какой период могут быть нужны данные, но это тоже все обсуждаемо и изменяемо, появится потребность хранить дольше, начнем хранить дольше. Для каких-то данных используется репликация, есть данные, где она не нужна. В этом кстати есть своя сложность и гибкость одновременно, кластер можно настроить именно так как нам нужно, но для этого нужно потратить какое-то время на изучение документации.
Про размещение на HDD я с Вами полностью согласен. Прошлая инсталляция как раз и жила на HDD с SSD кешем и там были замечены странности и влияние на другие виртуалки. Пришлось добавлять лимиты по IOps, что конечно сыграло не в лучшую сторону для ClickHouse. С SSD были опасения, что можем упереться, но пошли на этот шаг, на данный момент эффекта не заметили. У нас есть понимание как можно расширить кластер, увеличить ему ресурсов и в дальнейшем переехать на отдельные инстансы. Скорее сейчас ловим какие-то другие проблемы из-за увеличения объема данных и количества запросов, но вот в SSD пока не упираемся.
Мы хотели использовать отдельные инстансы ClickHouse, но на тот момент у нас в наличии не было необходимого количества серверов и мы смогли бы реализовать только круговую репликацию, что нас не устраивало. В обозримом будущем мы планируем переехать на отдельные инстансы ClickHouse. Из-за этого ограничения мы как раз и пытались уместить все на существующем железе.
Контейнеры не рассматривали изначально, для подготовки стабильного решения с их использованием, потребовалась бы дополнительное время на аналитику, к сожалению которого у нас не было. Мы уперлись в ограничения прошлой инсталляции кластера и нужно было быстрее переезжать в новый.