Comments 20
А PostgreSQL не сложнее поддерживать, чем Elastic? Перед разработкой решения на PostgreSQL каким образом принималось решение о хранилище?
Elastic стал продвигаться примерно с 12 го года, мы же первую версию логов делали в начале 12 — го. Делали как прототип, а потом оказалось, что с него не так то просто слезть, когда у тебя уже все налажено и работает. У нас используется GrayLog2 для сбора логов с nginx, так что мы можем примерно сравнивать его и нашу систему.
Т.е. фактически, вы рассказываете про свою систему и совершенно не факт, что оно удобнее/производительнее/дешевле, чем Elastic. Просто у вас так «исторически сложилось».
Мне кажется интереснее было бы сравнить ваше решение и какие-то другие, а не просто почитать про «исторически сложившееся».
Мне кажется интереснее было бы сравнить ваше решение и какие-то другие, а не просто почитать про «исторически сложившееся».
Мне кажется интереснее было бы сравнить ваше решение и какие-то другие, а не просто почитать про «исторически сложившееся».
Почему не интересно?
К примеру на HL++ был доклад о БД в VK.com, как они взяли и переписали с нуля свою старую самописную БД на новую, узкоспециализированную и заточенную только под них. У них это свои исторические костыли, но тем не менее очень интересные и было любопытно послушать как они это делали.
Так и тут, пусть своя система, возможно не такая быстрая и не такая компактная как могло бы быть, но она работает и работает на Pg, что тоже показатель, причем очень неплохой в пользу PostgreSQL. Вроде написали, что были попытки уйти на ClickHouse и Elastic, но не получилось, не срослось, это тоже показатель.
С Elastic нам все понравилось, он тратит меньше IOPs на запись, несколько побыстрее отдает ответ, но как написано в статье, не устроило, что он выигрыш по месту хранения дал маленький. Это основная причина почему мы на него пока стремимся перейти.
Ошибся в сообщении, последнюю строку надо читать как: «Это основная причина почему мы на него пока НЕ стремимся перейти».
Забавно это выходит. Работает быстрее, диски грузит меньше. Но из-за того что 32Тб текста это в любом случае 32Тб текста — оно «нинужно».
P.S. вобщем-то понятно почем декстопный СБИС рассыпается при любом удобном случае. Там видать с БД тоже работали как захочется а не как надо)
P.S. вобщем-то понятно почем декстопный СБИС рассыпается при любом удобном случае. Там видать с БД тоже работали как захочется а не как надо)
Там конечно не 32 Тб текста. 32Тб это данные + индексы. Индексы это где-то 50%. Т.е. на данные 16Тб. Из них текст составляет около 40% от других данных, т.е. на него тратится < 8Тб. Без текста трассировка была бы бесполезна, поиск по части текста довольно распространенное явление.
Насчет удобства в сравнении с другими системами — наша очевидно удобнее в плане интерфейса чем GrayLog2. Имею счастье пользоваться обеими.И наша существенно сильнее заточена на нашу специфику.
Что мешает использовать свой интерфейс?
Отсутствие серьезного выигрыша по месту хранения, устроило бы >50%. На самом деле мы еще не оставили до конца опыты с ClickHouse, но с ним мы все-таки несколько в тупике.
Я вот не понимаю за счет какой магии вы хотите выиграть 50% от объема. Пишите тогда в файлики на zfs с дедупликацией, вдруг сработает.
Кликхаус вы поднимали через ZooKeeper или так же пытались делать независимые базы как в описываемом примере с постгресом?
И что мешало создать индекс, который включает больше колонок? Почему это не помогло?
И что мешало создать индекс, который включает больше колонок? Почему это не помогло?
Нет, ClickHouse не подымали через ZooKeper. Сначала сделали кластер из двух узлов, потом отдельно к каждому узлу обращались. Вариант с кластером был медленнее.
А почему должен помочь индекс включающий больше колонок?
Если мне нужно выбрать по датевремени и названию запроса, или по датевремени и названию сервиса, то очевидно тут разные индексы нужны. Ибо в этом случае индекс из трех колонок:
сервис, название запроса, дата время
будет точно работать неэффективно для запросов обоих видов.
А почему должен помочь индекс включающий больше колонок?
Если мне нужно выбрать по датевремени и названию запроса, или по датевремени и названию сервиса, то очевидно тут разные индексы нужны. Ибо в этом случае индекс из трех колонок:
сервис, название запроса, дата время
будет точно работать неэффективно для запросов обоих видов.
Sign up to leave a comment.
Опыт построения логов на Postgres