Спасибо за доклад. Мне показалось, что представленный подход пересекается с методом R, описанным Cary Millsap в книге «Optimizing Oracle Performance», «Mastering Oracle Trace Data» и др., и описывает интересные варианты его практического применения.
Добрый день, я хотел бы получить консультацию по следующему вопросу
Перед нами стоит задача построения отказостойчивой и масштабируемой системы хранения данных от системы обнаружения инцидентов. Система производит постоянный мониторинг большого кол-ва точек и в случае обнаружения инцидента заносит информацию по нему в хранилище. У инцидентов примерно следующие х-ки:
— Каждый инцидент привязан к определенному клиенту и характеризуется помимо времени обнаружения небольшим кол-вом целочисленных аттрибутов;
— Среднее кол-во инцидентов, собираемых в рамках одной итерации проверки системы мониторинга, составляет на текущий момент порядка 30 млн (эта величина может быть увеличена в разы при добавлении новых типов инцидентов или увеличении кол-ва точек, для которых производится мониторинг). За сутки система мониторинга может проводить несколько итераций проверки;
— Кол-во клиентов, для которых собирается статистика по инцидентам, порядка 50 тыс. Распределение кол-ва инцидентов по клиентам очень неравномерное (но есть возможность сделать грубый прогноз по ожидаемому порядку кол-ва инцидентов для каждого нового клиента).
Операции с данными:
OLTP (кол-во конкурентных запросов к данным невелико, до 100 запросов в секунду, запись до 5-10 тыс. транзакций в секунду):
— Вывод данных по собранным инцидентам с детализацией по каждому конкретному инциденту для каждого конкретного клиента. Вывод общих данных по всем клиентам не требуется, достаточно только данных по конкретному клиенту. Вывод данных нужен как по всем типам инцидентов, так и по конкретному типу. Сортировка по времени и по одному из целочисленных полей.
— Данные делятся на горячие (зафиксированные за последние сутки-двое), холодные (до года) и архивные. Информация по всем типам должна храниться в полном объеме. Время доступа к горячим и холодным данным должно быть одинаково быстрым, к архивным — быстрый доступ к аггрегированным данным;
— Выборка аггрегированных по временным промежуткам данным по разным типам инцидентов для конкретного клиента. Для построения временных графиков кол-ва инцидентов с шагом сутки, неделя, месяц.
OLAP (достаточно редко, как правило к конференциям или пресс-релизами):
— Подсчет аггрегированных (по различным временным интервалам) данных по всем клиентам в разрезе типов инцидентов, гео-привязки клиентов и пр. за промежуток вплоть до 1-2 лет.
Как это иногда бывает, на начальном этапе не планировалось хранить большое кол-во данных (на тот момент было до 5 млн. записей и динамика роста этого кол-ва была невелика), и хранение осуществлялось в одной таблице в MySQL. Т.к. инциденты обычно являются достаточно продолжительными по времени, в базе хранились не результаты каждой проверки системы мониторинга, а инциденты с полями 'время первого обнаружения', 'время последнего обнаружения'. На каждой итерации проверки поле 'время последнего обнаружения' обновлялось текущим временем проверки. Это позволило ограничить рост данных в таблице на порядок ценой некоторого усложнения выборок и гибкости при изменении определенных изменениях логики приложения.
Тем не менее, за последний год кол-во данных выросло до 900 млн. записей. В текущей реализации мы сделали партицирование таблицы по разным типам инцидентов, чтобы ограничить объемы обрабатываемых данных при выборках с фильтрацией по типам инцидентов. С текущими объемами данных данное решение укладывается на выборках данных в допустимое время, но есть пока несущественные проблемы с обновлением данных, которое может иногда затягиваться по времени.
В связи с постоянным ростом объема хранимых данных в настоящий момент я провожу исследование по выбору оптимального хранилища данных для нашего случая. В кандидатах сейчас следующие решения:
1. Развитие схемы хранения в реляционной базе с возможным добавлением шардинга по клиентам и партицирования по горячим/холодным/архивным данным. Здесь есть некоторые сложности с равномерным размазыванием клиентов по шардам, но при использовании виртуальных шардов можно реализовать такую кластеризацию клиентов по шардам, при которой кол-во данных в рамках шарда будет +- равномерным. Кроме того, усложнится логика приложения, адаптированная для работы с шардингом (что упрощается, если вводить прослойку вида MySQL Fabric или собственные решения на базе mysqlnd в случае PHP). Плюсы: отлаженная технология, много инструментов и юзкейсов;
2. Использование специализированных хранилищ временных рядов (хороший обзор дал Макс Лапшин levgem.livejournal.com/460103.html). У нас есть положительный опыт продолжительного использования influxdb, правда на значительно меньшем объеме данных (несколько десятков млн. точек). Другой кандидат — решение на базе Elliptics.
В данном случае есть проблема, вызванная тем, что данные системы хранения требуют хранения каждой точки проверки, а не пары 'время первого обнаружения', 'время последнего обнаружения' (можно правда обойти усложнением логики, но ценой возможных ограничений функционала хранилища), что в нашем случае увеличивает кол-во хранимых данных с 900 млн. до 5-10 млрд. точек. Плюсы (в случае influxdb): возможность автоматической пред-аггрегации данных (downsampling), шардирование и партицирование (настраиваемые движки хранения), фан и что-то новое. Недостатки: новые технологии, мало инструментов.
3. Использование колоночных БД (например, HP Vertica или InfiniDB). В данном случае можно добиться хороших показателей сжатия данных и производительности аггрегированных выборок, но есть некоторые сомнения в эффективности этих решений в OLTP режиме, учитывая их заточенность под OLAP.
В связи с этим я хотел бы просить совета по следующим вопросам:
— Зная ваш богатый опыт использования перечисленных мной технологий, на какие подводные камни стоит обратить внимание в первую очередь при оценке систем хранения того или иного типа;
— Можете ли вы со своей стороны на основе своего опыта дать рекомендации по выбору того или иного решения, возможно расширить список решений для оценки;
— Для оценки/выбора того или иного решения мы будем проводить объемное тестирование (Volume testing) каждого из них на объемах данных вплоть до тех, которые планируем достичь через год-два, а также тестирование на отказоустойчивость. Какие сценарии тестирования стоит предусмотреть и на какие метрики при тестировании на ваш взгляд стоит обратить пристальное внимание.
Мы использовали похожую идею для формы обратной связи на одном из своих проектов. Помимо текста пользователь может приложить «скриншот» экрана, на котором у него возникла проблема, затемнить или наоборот выделить отдельные части экрана. Работает почти год, очень довольны эффективностью подобного решения. При разработке смотрели в сторону jsfeedback и html2canvas, на основе которой он сделан. Но качество кода и функционал jsfeedback из коробки не понравился, и мы реализовали собственное решение на базе html2canvas.
У нас в компании DrWeb используется пару лет. До этого нод был. На самом деле достаточно нормально работает, тормозов нет. Ну если только очень редко, что не проблема. Особенно в сравнении с нодом, который на каждом шагу говорит, что быстрый, а на самом деле… В остальном — мне показалось, что консоль управления очень удобная. Ну для наших админов — точно. Что касается детекта — вообще лучший.
Перед нами стоит задача построения отказостойчивой и масштабируемой системы хранения данных от системы обнаружения инцидентов. Система производит постоянный мониторинг большого кол-ва точек и в случае обнаружения инцидента заносит информацию по нему в хранилище. У инцидентов примерно следующие х-ки:
— Каждый инцидент привязан к определенному клиенту и характеризуется помимо времени обнаружения небольшим кол-вом целочисленных аттрибутов;
— Среднее кол-во инцидентов, собираемых в рамках одной итерации проверки системы мониторинга, составляет на текущий момент порядка 30 млн (эта величина может быть увеличена в разы при добавлении новых типов инцидентов или увеличении кол-ва точек, для которых производится мониторинг). За сутки система мониторинга может проводить несколько итераций проверки;
— Кол-во клиентов, для которых собирается статистика по инцидентам, порядка 50 тыс. Распределение кол-ва инцидентов по клиентам очень неравномерное (но есть возможность сделать грубый прогноз по ожидаемому порядку кол-ва инцидентов для каждого нового клиента).
Операции с данными:
OLTP (кол-во конкурентных запросов к данным невелико, до 100 запросов в секунду, запись до 5-10 тыс. транзакций в секунду):
— Вывод данных по собранным инцидентам с детализацией по каждому конкретному инциденту для каждого конкретного клиента. Вывод общих данных по всем клиентам не требуется, достаточно только данных по конкретному клиенту. Вывод данных нужен как по всем типам инцидентов, так и по конкретному типу. Сортировка по времени и по одному из целочисленных полей.
— Данные делятся на горячие (зафиксированные за последние сутки-двое), холодные (до года) и архивные. Информация по всем типам должна храниться в полном объеме. Время доступа к горячим и холодным данным должно быть одинаково быстрым, к архивным — быстрый доступ к аггрегированным данным;
— Выборка аггрегированных по временным промежуткам данным по разным типам инцидентов для конкретного клиента. Для построения временных графиков кол-ва инцидентов с шагом сутки, неделя, месяц.
OLAP (достаточно редко, как правило к конференциям или пресс-релизами):
— Подсчет аггрегированных (по различным временным интервалам) данных по всем клиентам в разрезе типов инцидентов, гео-привязки клиентов и пр. за промежуток вплоть до 1-2 лет.
Как это иногда бывает, на начальном этапе не планировалось хранить большое кол-во данных (на тот момент было до 5 млн. записей и динамика роста этого кол-ва была невелика), и хранение осуществлялось в одной таблице в MySQL. Т.к. инциденты обычно являются достаточно продолжительными по времени, в базе хранились не результаты каждой проверки системы мониторинга, а инциденты с полями 'время первого обнаружения', 'время последнего обнаружения'. На каждой итерации проверки поле 'время последнего обнаружения' обновлялось текущим временем проверки. Это позволило ограничить рост данных в таблице на порядок ценой некоторого усложнения выборок и гибкости при изменении определенных изменениях логики приложения.
Тем не менее, за последний год кол-во данных выросло до 900 млн. записей. В текущей реализации мы сделали партицирование таблицы по разным типам инцидентов, чтобы ограничить объемы обрабатываемых данных при выборках с фильтрацией по типам инцидентов. С текущими объемами данных данное решение укладывается на выборках данных в допустимое время, но есть пока несущественные проблемы с обновлением данных, которое может иногда затягиваться по времени.
В связи с постоянным ростом объема хранимых данных в настоящий момент я провожу исследование по выбору оптимального хранилища данных для нашего случая. В кандидатах сейчас следующие решения:
1. Развитие схемы хранения в реляционной базе с возможным добавлением шардинга по клиентам и партицирования по горячим/холодным/архивным данным. Здесь есть некоторые сложности с равномерным размазыванием клиентов по шардам, но при использовании виртуальных шардов можно реализовать такую кластеризацию клиентов по шардам, при которой кол-во данных в рамках шарда будет +- равномерным. Кроме того, усложнится логика приложения, адаптированная для работы с шардингом (что упрощается, если вводить прослойку вида MySQL Fabric или собственные решения на базе mysqlnd в случае PHP). Плюсы: отлаженная технология, много инструментов и юзкейсов;
2. Использование специализированных хранилищ временных рядов (хороший обзор дал Макс Лапшин levgem.livejournal.com/460103.html). У нас есть положительный опыт продолжительного использования influxdb, правда на значительно меньшем объеме данных (несколько десятков млн. точек). Другой кандидат — решение на базе Elliptics.
В данном случае есть проблема, вызванная тем, что данные системы хранения требуют хранения каждой точки проверки, а не пары 'время первого обнаружения', 'время последнего обнаружения' (можно правда обойти усложнением логики, но ценой возможных ограничений функционала хранилища), что в нашем случае увеличивает кол-во хранимых данных с 900 млн. до 5-10 млрд. точек. Плюсы (в случае influxdb): возможность автоматической пред-аггрегации данных (downsampling), шардирование и партицирование (настраиваемые движки хранения), фан и что-то новое. Недостатки: новые технологии, мало инструментов.
3. Использование колоночных БД (например, HP Vertica или InfiniDB). В данном случае можно добиться хороших показателей сжатия данных и производительности аггрегированных выборок, но есть некоторые сомнения в эффективности этих решений в OLTP режиме, учитывая их заточенность под OLAP.
В связи с этим я хотел бы просить совета по следующим вопросам:
— Зная ваш богатый опыт использования перечисленных мной технологий, на какие подводные камни стоит обратить внимание в первую очередь при оценке систем хранения того или иного типа;
— Можете ли вы со своей стороны на основе своего опыта дать рекомендации по выбору того или иного решения, возможно расширить список решений для оценки;
— Для оценки/выбора того или иного решения мы будем проводить объемное тестирование (Volume testing) каждого из них на объемах данных вплоть до тех, которые планируем достичь через год-два, а также тестирование на отказоустойчивость. Какие сценарии тестирования стоит предусмотреть и на какие метрики при тестировании на ваш взгляд стоит обратить пристальное внимание.
У нас в компании DrWeb используется пару лет. До этого нод был. На самом деле достаточно нормально работает, тормозов нет. Ну если только очень редко, что не проблема. Особенно в сравнении с нодом, который на каждом шагу говорит, что быстрый, а на самом деле… В остальном — мне показалось, что консоль управления очень удобная. Ну для наших админов — точно. Что касается детекта — вообще лучший.
Они вчера вот новую линейку продуктов выпустили — news.drweb.com/show/?i=999&c=5&p=0
Всем бы такие времена))
По вашему мнению лучше, если все летает, но вирусы в системе и локалке роем) Мол ничего не знаем, не наше дело?
Антивирус — не только картинка в системном трее) Но и защита. Для меня, во всяком случае, именно это важно.