То что он более проработанный это к сожалению видимость. У него есть пара серьезных недостатковособенностей:
Параметры типа Write Performance/Query Perfromance сравниваются по заверениям авторов без учета разного железа и методик тестирования — то есть по фатку это профанация.
Для показателей bytes per point нет источника, например непонятно откуда у Dalmatiner'а 1, когда авторы базы об этом ничего не говорят, если из тестов то тогда см п. 1, цифры в этом блоке профанация так как еще и осознанно на разных сетах данных
Оценки типа Complexity, Functionality, Usability тоже даны примерно от балды по какой-то внутренней логике авторов, которая не очень то афишируется
Нет упоминаний ни в каком виде что у всего raik-based cross-dc кластеризация платная, что по мне, например важно.
Поэтому я бы честно говоря не советовал бы использовать эту таблицу как источник информации, из-за того что она не учитывает разницу тестовых методик все цифры в ней являются профанацией и по факту бесполезны (не говоря о том, что например для Whisper'а есть более быстрые реализации на Go, чем указанное в таблице, но автор по какой-то причине не хочет их учитывать).
В некоторых странах континентальной Европы можно взять ипотеку под ещё более смешные 1.3% с первым взносом в размере 3% от стоимости жилья. Так что 3% и 30% взнос это не так уж и интересно.
В принципе можно, вопрос с источниками данных. Для части строк в таблице были использованы источники вида «Эй, ты же автор? А сколько байт занимает точка у тебя?».
Там есть субъективные комментарии (последнее поле) которое ценны, но не факт что их Википедия примет. Наверное в перспективе можно, если придумать как таблицу оставить сортируемой и перенести все включая комментарии и заметки на полях.
Всегда надо отталкиваться от задач. Если Time-Series это именно то что вы хотите и вы их хотите за какое-то значимое время, то SQL совсем не годится. Хотя бы потому что авторы заббикса оценивают размер одной точки в 90 байт, а в современных базах получается какое-то такое распределение:
1. *SQL-based базы и прочие попытки притянуть за уши решение — 80+ байт на точку.
1. Cassandra-based без кастомного сжатия — около 14 байт на точку
2. Graphite'овый Whisper и прочие RRD-подобные — 8-12 байт на точку
3. Более современные базы со сжатием — 2-6 байт на точку
Везде будут свои недостатки и преимущества, выбирать надо исходя из задач. Но я бы в 2017 году начал бы выбор с вопроса «почему не Prometheus?»
Ниже freeseacher хорошо описал основные текущие. К этому можно добавить разве что следующее:
1. Кластеризация и HA только в платной версии (в бесплатной предлагается писать в две базы параллельно и дальше получить проблемы с синхронизацией данных и пр.). Притом что когда кластеризация была в OpenSource она не работала, поэтому нет оснований верить в нее и сейчас.
2. Апдейты как хождение по минному полю — не знаешь что оторвет сейчас в целом по всему их стеку. Можно посмотреть баги телеграфа, в InfluxDB в каждом апдейте сопоставимый бардак.
Непонятны причины выбора. Даже более того, с учётом длительной истории проблем с influxdb и платной кластеризации, я бы не стал его ставить в Production.
И наверное последний вопрос который пришел в голову — а вы считали сколько у вас байт занимает 1 точка сейчас и сколько было раньше? Тоже интересный показатель как по мне.
Еще хотелось бы уточнить про характер нагрузки. Насколько принято у вас держать dashboard'ы постоянно открытыми с автообновлением, например? Или мониторы в офисе и т.п.
То есть насколько сильный постоянная составляющая для запросов, а насколько часто приходят живые люди с их задачами?
Еще не сравнивали ли вы как меняется скорость запросов в случаи вашей базы и rrd в зависимости от разных time frame'ов и количества метрик и от количества одновременных пользователей? Например довольно частая проблема систем что у них разная зависимость времени выполнения работы от этих параметров. На 1 запросе по 100 метрик может победить одна система, а на 50 запросах в секунду по 1000 метрик в среднем — уже другая (а та которая победила в первом случаи вообще сложиться и откинуть копыта).
Так что, как перезапись — это действительно сработает. Но пользы от этого нет: что бы корректно это использовать надо где-то (где?) хранить еще и все сырые данные из которых при необходимости мы будем вычислять новый агрегат.
Да, такая проблема есть если у вас есть тенденция переписывать очень старые данные. В случаи с графитом стараются все таки иметь детальный архив размеров от 1 дня, отчасти чтобы позволить данным приходить с некоторой разумной задержкой. Я честно говоря слабо представляю себе use-case когда данные приходят с задержкой на 2-3 дня.
Обновляется 350к разных метрик? Или это интенсивное обновление нескольких метрик? Интересно сколько обновляется уникальных метрик, скажем, за 10 минут?
go-carbon естественно имеет некоторый in-memory кэш, в котором для каждой метрики копятся данные (с целью в том числе снизить рандомность записи). То есть в таком тесте это некоторое разумное количество записей в файл в секунду (мы у себя ограничиваем например 30к, что примерно соответствует 25% загрузке дисков наших). В целом 350к точек в секунду может быть и 350к разных метрик и это стабильная скорость при наличии достаточного количества памяти чтобы иметь кэш (я бы сказал 350к при наличии средненьких ССДшек можно получить при 16-32ГБ оперативной памяти под кэш, вероятно даже меньше). Естественно в жертву приносится некоторая надежность данных в случаи смерти железки (все что в кэше, но не на диске будет потеряно). Ноиз плюсов — при 128-256ГБ оперативной памяти оно может довольно спокойно жить на чем-то типа SAN на обычных дисках.
В случаи чтения, данные выбираются как с диска, так и из кэша.
Например, как я понял, carbonzipper позволяет на лету объединять результат одной метрики с разных серверов, где лежат ее реплики. Как решаются конфликты при объединении разных значений одной и той же ячейки?
На текущий момент считается что первая вернувшаяся и есть правильная.
Процесс «лечения» данных идет в фоне фактически набором скриптов — периодически процесс пробегает и сравнивает файлы.
Для миграции можно использовать buckytools, там проблема переноса данных на новую ноду довольно неплохо решена.
Справедливости ради, вы сделали некорректную оценку Graphite'а. Конкретнее:
1. У него изначально во всех доступных реализациях есть перезапись точек в прошлом (у вас стоит галочка что нету).
2. У него множество совместимых реализаций с немного отличающимися характеристиками, вы видимо посмотрели бегло на то что в гитхабе graphite-project, без попыток найти решения проблем. Например есть альтернативная реализация демона, осуществляющего запись — go-carbon, которая на одном среднем сервере не напрягаясь выдает 350 тысяч точек в секунду на запись. Кстати проект существует несколько лет уже.
3. Опять же альтернативные реализации стека реализуют и HA и позволяют масштабироваться (см carbonzipper). Проект в OpenSource'е и активно развивается года так с 2013-2014.
В целом интересно не только, сколько вы смогли записать, но и как вы читаете? Я имею в виду какого характера запросы, как много метрик и точек вы выбираете и т.п.
Спасибо за разъяснения. Маленькое замечание: P6000 — 3840 Cuda Cores, ближайший его аналог Nvidia Titan X — 3584 Cuda Cores. А так да, что у P5000, что у GTX 1080 — 2560 и производительность должна быть примерно такая же. Ну и да, забыл про ECC память.
+256 cuda cores, вдвое больше видеопамяти. Оптимизация драйверов. По слухам система охлаждения чуть другая и может работать в стойках без риска перегрева в отличии от игровых карт.
Не все Quadro одинаково полезны. В поколении на Паскалях, 1/2 только у Quadro GP100 на одноименном чипе. P6000 основана на чипе GP102 (как Nvidia Titan X), у чипов отличия в том что GP102 идет с GDDR5/5X и физически FP64 = 1/32 FP32.
Подтверждения этому можно найти в анонсах или полных спецификациях.
>>> Ну выставлять несколько ретеншенов это надо быть очень смелым или жестко следить за структурой метрик, потому что разные данные постагрегируются по разному, некоторые вообще нельзя постагрегировать и данные могут оказаться нерелевантными.
Ровно так и делаем. Где можно выставляем, меняем aggregation method'ы и т.п., есть некоторые правила даже (для ряда кластеров если у метрики постфикс _count то агрегируем как sum).
>>> Угу. Мы решили писать много, но хранить не долго. 80-100 к на сервер показывает много чего, тут уже смотря что за сервер.
А мы пишем много и храним долго. Графит используется как для мониторинга серверов, так и для приложений и какой-то странной бизнес-статистики. Плюс люди немного развращены тем, что в графит можно просто начать слать данные и потом ими никогда не пользоваться, или пользоваться раз в год чтобы посчитать какую-нибудь фигню для годового отчета.
>>> вот это не понял :) карбон линк это же часть go-carbon\carbon-cache демона, в то время как carbon_ch это алгоритм распределения метрик через рилей. То есть всё равно что приходит на карбон, если он сам реализовывает carbon-link то любой ридер (graphite-api, graphite-web) может его вычитать.
Его нужно переписывать, т.к. в graphite-web carbonlink тесно завязан на carbon_ch. Также как и во всех утилитах определение положения метрик идет исходя из того что все используют carbon_ch. Т.е. эту часть кода нужно соответственным образом переписывать. Ну и да, фронтэнд на python тоже уже является узким местом достаточно давно, поэтому для значительной части запросов мы используем carbonapi.
>>> есть такая штука carbon-ram, у них метрики хранятся в redix tree, работает быстро. Но чтобы правильно его реквестить надо понимать где мы храним сутки, а где всё остальное и делать математику исходя из этого.
Не смог с ходу найти проект. Если речь про carbonmem, то он быстрый, но требует некоторого допиливания под general purpose задачи (там оптимизация под запросы типа topk, что делает его не таким эффективным для запросов общего вида) и Вы правы, нужно реализовывать поддержку в carbonzipper. Вся проблема в том, что 24 часа данных будет занимать больше 1ТБ (из рассчета что 1 точка занимает 8 байт) и даже хорошие решения в такой ситуации могут не подойти без доработки, а доработка это время.
>>> Кстати, может будет интересно — недавно общался с ребятами, так они вообще за go-carbon поставили ceph и живут.
Да, в планах тоже есть желание потестировать различные варианты хранилок, но опять же в планах.
>>> Если коротко, то я генерил нагрузку самописной тулой
Понятно, ну я примерно также своими самописными тулзами делаю сейчас. А возможность прочитать эти данные потом не проверялась? На этом еще половина бэкэндов станет хуже чем виспер.
Ceres не полностью заброшен, но то что на graphite-project — как минимум раньше было абсолютно не юзабельно (merge ломал данные). Использовали форки, например: https://github.com/dkulikovsky/ceres, также есть еще новая реализация демона на Ди, но ее я уже не щупал: https://github.com/iain-buclaw-sociomantic/carbond (тоже слегка подзаброшена, но возможно и что человек просто не выкладывает свежие сырцы). В целом бэкэнд не очень интересный, т.к. дает лишь незначительное улучшение эффективности хранения данных и в общем-то незначительно быстрее, а перерабатывать carbonserver придется существенно.
Whisper из-за архитектуры подвержен write amplification'у если у тебя более чем 1 retention period, большой кэш смягчает I/O но ценой задержки доставки данных до диска. Плюс ко всему, в моем случаи место более критично чем I/O и даже CPU. Требование растет из желания людей хранить как можно больше данных как можно дольше. При этом предсказать сколько будет требоваться места можно, но периодически случаются накладки (немного неожиданные запуски или еще какая-нибудь команда осознает что в графит можно слать много данных и потом их читать оттуда). Поэтому и ребалансировка, к сожалению, не такой уж редкий процесс. На вскидку за последний год мне пришлось перебалансировать 3/4 графитных кластеров которые у нас есть и предстоит еще миграция на более подходящее железо, в которое, к сожалению, нельзя просто взять и переткнуть диски. Причины миграции простые — значительный кусок располагается на серверах от одного известного вендора, у которого есть неотключаемый рейд-контроллер, который банально уходит в себя каждые недели этак три. На масштабах порядка сотен серверов это выливается в среднем в 7 падений в неделю. А что касается объема данных, то речь идет о десятках, а то уже и сотнях (с учетом всей репликации) ТБ данных в графите. В общем у нас просто другой юзкейс и реально производительности 80-100k/s на сервер более чем достаточно, а ее показывает и carbon-cache.
Что касается про полуручную работу и допиливание. carbon_ch (пользуясь терминологией из carbon-c-relay) дает очень плохое распределение метрик, но позволяет использовать «из коробки» все тулзы и carbon-link. Притом проблема настолько большая, что разница в нагрузке между carbon_ch и jump_fnv1a хэшами составляет порядка 20%. Т.е. в какой-то момент на одном из серверов кластера место закончилось, а на другом еще 200ГБ свободно. Соответственно отказываясь от carbon_ch приходится отказываться от даже потенциальной возможности реализации carbon-link и доступа к кэшу. Притом решить проблему с кэшом в целом не многим проще, чем прикрутить отдельный in-memory сторадж на, допустим, последние сутки данных. Подводя итог, любой из этих наборов утилит не очень работоспособен из коробки в моем случаи, нужно доделывать или переделывать какие-то куски. В любом случаи готового «из коробки» механизма, который бы полечил упавший сервер, смигрировал бы данные и т.п. отсутствует, нужна какая-то дополнительная работа, которая вполне вероятна сопоставима с миграцией данных.
Про Бэкэнды — увы, я не знаю ничего лучше на текущий момент. Собственно говоря я дискуссию то и затеял, чтобы узнать вдруг ком-то что-то интересное встречалось. Так у меня в планах посмотреть на RiakTS, BTrDB и еще парочку бэкэндов.
И к слову, а чем в своих тестах Вы генерировали нагрузку, если не секрет? И в целом, если можно, чуть поподробнее про методику тестирования хотелось бы услышать.
недостатковособенностей:Поэтому я бы честно говоря не советовал бы использовать эту таблицу как источник информации, из-за того что она не учитывает разницу тестовых методик все цифры в ней являются профанацией и по факту бесполезны (не говоря о том, что например для Whisper'а есть более быстрые реализации на Go, чем указанное в таблице, но автор по какой-то причине не хочет их учитывать).
В некоторых странах континентальной Европы можно взять ипотеку под ещё более смешные 1.3% с первым взносом в размере 3% от стоимости жилья. Так что 3% и 30% взнос это не так уж и интересно.
1. *SQL-based базы и прочие попытки притянуть за уши решение — 80+ байт на точку.
1. Cassandra-based без кастомного сжатия — около 14 байт на точку
2. Graphite'овый Whisper и прочие RRD-подобные — 8-12 байт на точку
3. Более современные базы со сжатием — 2-6 байт на точку
Везде будут свои недостатки и преимущества, выбирать надо исходя из задач. Но я бы в 2017 году начал бы выбор с вопроса «почему не Prometheus?»
1. Кластеризация и HA только в платной версии (в бесплатной предлагается писать в две базы параллельно и дальше получить проблемы с синхронизацией данных и пр.). Притом что когда кластеризация была в OpenSource она не работала, поэтому нет оснований верить в нее и сейчас.
2. Апдейты как хождение по минному полю — не знаешь что оторвет сейчас в целом по всему их стеку. Можно посмотреть баги телеграфа, в InfluxDB в каждом апдейте сопоставимый бардак.
Непонятны причины выбора. Даже более того, с учётом длительной истории проблем с influxdb и платной кластеризации, я бы не стал его ставить в Production.
Жаль конечно что не изучали детально чтение.
И наверное последний вопрос который пришел в голову — а вы считали сколько у вас байт занимает 1 точка сейчас и сколько было раньше? Тоже интересный показатель как по мне.
Еще хотелось бы уточнить про характер нагрузки. Насколько принято у вас держать dashboard'ы постоянно открытыми с автообновлением, например? Или мониторы в офисе и т.п.
То есть насколько сильный постоянная составляющая для запросов, а насколько часто приходят живые люди с их задачами?
Еще не сравнивали ли вы как меняется скорость запросов в случаи вашей базы и rrd в зависимости от разных time frame'ов и количества метрик и от количества одновременных пользователей? Например довольно частая проблема систем что у них разная зависимость времени выполнения работы от этих параметров. На 1 запросе по 100 метрик может победить одна система, а на 50 запросах в секунду по 1000 метрик в среднем — уже другая (а та которая победила в первом случаи вообще сложиться и откинуть копыта).
Да, такая проблема есть если у вас есть тенденция переписывать очень старые данные. В случаи с графитом стараются все таки иметь детальный архив размеров от 1 дня, отчасти чтобы позволить данным приходить с некоторой разумной задержкой. Я честно говоря слабо представляю себе use-case когда данные приходят с задержкой на 2-3 дня.
go-carbon естественно имеет некоторый in-memory кэш, в котором для каждой метрики копятся данные (с целью в том числе снизить рандомность записи). То есть в таком тесте это некоторое разумное количество записей в файл в секунду (мы у себя ограничиваем например 30к, что примерно соответствует 25% загрузке дисков наших). В целом 350к точек в секунду может быть и 350к разных метрик и это стабильная скорость при наличии достаточного количества памяти чтобы иметь кэш (я бы сказал 350к при наличии средненьких ССДшек можно получить при 16-32ГБ оперативной памяти под кэш, вероятно даже меньше). Естественно в жертву приносится некоторая надежность данных в случаи смерти железки (все что в кэше, но не на диске будет потеряно). Ноиз плюсов — при 128-256ГБ оперативной памяти оно может довольно спокойно жить на чем-то типа SAN на обычных дисках.
В случаи чтения, данные выбираются как с диска, так и из кэша.
На текущий момент считается что первая вернувшаяся и есть правильная.
Процесс «лечения» данных идет в фоне фактически набором скриптов — периодически процесс пробегает и сравнивает файлы.
Для миграции можно использовать buckytools, там проблема переноса данных на новую ноду довольно неплохо решена.
1. У него изначально во всех доступных реализациях есть перезапись точек в прошлом (у вас стоит галочка что нету).
2. У него множество совместимых реализаций с немного отличающимися характеристиками, вы видимо посмотрели бегло на то что в гитхабе graphite-project, без попыток найти решения проблем. Например есть альтернативная реализация демона, осуществляющего запись — go-carbon, которая на одном среднем сервере не напрягаясь выдает 350 тысяч точек в секунду на запись. Кстати проект существует несколько лет уже.
3. Опять же альтернативные реализации стека реализуют и HA и позволяют масштабироваться (см carbonzipper). Проект в OpenSource'е и активно развивается года так с 2013-2014.
В целом интересно не только, сколько вы смогли записать, но и как вы читаете? Я имею в виду какого характера запросы, как много метрик и точек вы выбираете и т.п.
+256 cuda cores, вдвое больше видеопамяти. Оптимизация драйверов. По слухам система охлаждения чуть другая и может работать в стойках без риска перегрева в отличии от игровых карт.
Не все Quadro одинаково полезны. В поколении на Паскалях, 1/2 только у Quadro GP100 на одноименном чипе. P6000 основана на чипе GP102 (как Nvidia Titan X), у чипов отличия в том что GP102 идет с GDDR5/5X и физически FP64 = 1/32 FP32.
Подтверждения этому можно найти в анонсах или полных спецификациях.
Спасибо!
Ровно так и делаем. Где можно выставляем, меняем aggregation method'ы и т.п., есть некоторые правила даже (для ряда кластеров если у метрики постфикс _count то агрегируем как sum).
>>> Угу. Мы решили писать много, но хранить не долго. 80-100 к на сервер показывает много чего, тут уже смотря что за сервер.
А мы пишем много и храним долго. Графит используется как для мониторинга серверов, так и для приложений и какой-то странной бизнес-статистики. Плюс люди немного развращены тем, что в графит можно просто начать слать данные и потом ими никогда не пользоваться, или пользоваться раз в год чтобы посчитать какую-нибудь фигню для годового отчета.
>>> вот это не понял :) карбон линк это же часть go-carbon\carbon-cache демона, в то время как carbon_ch это алгоритм распределения метрик через рилей. То есть всё равно что приходит на карбон, если он сам реализовывает carbon-link то любой ридер (graphite-api, graphite-web) может его вычитать.
Его нужно переписывать, т.к. в graphite-web carbonlink тесно завязан на carbon_ch. Также как и во всех утилитах определение положения метрик идет исходя из того что все используют carbon_ch. Т.е. эту часть кода нужно соответственным образом переписывать. Ну и да, фронтэнд на python тоже уже является узким местом достаточно давно, поэтому для значительной части запросов мы используем carbonapi.
>>> есть такая штука carbon-ram, у них метрики хранятся в redix tree, работает быстро. Но чтобы правильно его реквестить надо понимать где мы храним сутки, а где всё остальное и делать математику исходя из этого.
Не смог с ходу найти проект. Если речь про carbonmem, то он быстрый, но требует некоторого допиливания под general purpose задачи (там оптимизация под запросы типа topk, что делает его не таким эффективным для запросов общего вида) и Вы правы, нужно реализовывать поддержку в carbonzipper. Вся проблема в том, что 24 часа данных будет занимать больше 1ТБ (из рассчета что 1 точка занимает 8 байт) и даже хорошие решения в такой ситуации могут не подойти без доработки, а доработка это время.
>>> Кстати, может будет интересно — недавно общался с ребятами, так они вообще за go-carbon поставили ceph и живут.
Да, в планах тоже есть желание потестировать различные варианты хранилок, но опять же в планах.
>>> Если коротко, то я генерил нагрузку самописной тулой
Понятно, ну я примерно также своими самописными тулзами делаю сейчас. А возможность прочитать эти данные потом не проверялась? На этом еще половина бэкэндов станет хуже чем виспер.
Whisper из-за архитектуры подвержен write amplification'у если у тебя более чем 1 retention period, большой кэш смягчает I/O но ценой задержки доставки данных до диска. Плюс ко всему, в моем случаи место более критично чем I/O и даже CPU. Требование растет из желания людей хранить как можно больше данных как можно дольше. При этом предсказать сколько будет требоваться места можно, но периодически случаются накладки (немного неожиданные запуски или еще какая-нибудь команда осознает что в графит можно слать много данных и потом их читать оттуда). Поэтому и ребалансировка, к сожалению, не такой уж редкий процесс. На вскидку за последний год мне пришлось перебалансировать 3/4 графитных кластеров которые у нас есть и предстоит еще миграция на более подходящее железо, в которое, к сожалению, нельзя просто взять и переткнуть диски. Причины миграции простые — значительный кусок располагается на серверах от одного известного вендора, у которого есть неотключаемый рейд-контроллер, который банально уходит в себя каждые недели этак три. На масштабах порядка сотен серверов это выливается в среднем в 7 падений в неделю. А что касается объема данных, то речь идет о десятках, а то уже и сотнях (с учетом всей репликации) ТБ данных в графите. В общем у нас просто другой юзкейс и реально производительности 80-100k/s на сервер более чем достаточно, а ее показывает и carbon-cache.
Что касается про полуручную работу и допиливание. carbon_ch (пользуясь терминологией из carbon-c-relay) дает очень плохое распределение метрик, но позволяет использовать «из коробки» все тулзы и carbon-link. Притом проблема настолько большая, что разница в нагрузке между carbon_ch и jump_fnv1a хэшами составляет порядка 20%. Т.е. в какой-то момент на одном из серверов кластера место закончилось, а на другом еще 200ГБ свободно. Соответственно отказываясь от carbon_ch приходится отказываться от даже потенциальной возможности реализации carbon-link и доступа к кэшу. Притом решить проблему с кэшом в целом не многим проще, чем прикрутить отдельный in-memory сторадж на, допустим, последние сутки данных. Подводя итог, любой из этих наборов утилит не очень работоспособен из коробки в моем случаи, нужно доделывать или переделывать какие-то куски. В любом случаи готового «из коробки» механизма, который бы полечил упавший сервер, смигрировал бы данные и т.п. отсутствует, нужна какая-то дополнительная работа, которая вполне вероятна сопоставима с миграцией данных.
Про Бэкэнды — увы, я не знаю ничего лучше на текущий момент. Собственно говоря я дискуссию то и затеял, чтобы узнать вдруг ком-то что-то интересное встречалось. Так у меня в планах посмотреть на RiakTS, BTrDB и еще парочку бэкэндов.
И к слову, а чем в своих тестах Вы генерировали нагрузку, если не секрет? И в целом, если можно, чуть поподробнее про методику тестирования хотелось бы услышать.