У нас есть и однонодовая система, «кушающая „1 миллиард записей в день, и системы с большим количеством серверов. Они решают разные задачи. По нашим оценкам, на одном сервере или ноде кластера можно “комфортно» хранить до 5TB сырых данных (то есть примерно 500-1000GB на дисковой системе). Естественно, если все правильно настроить в первую очередь с точки зрения физического дизайна проекций. Для дисковой системы мы используем RAID5 или RAID10 на SATA или SAS дисках. SSD не дает выигрыша, Вертика не делает random I/O.
Я думаю, что для вас лучший способ поприсутствовать — это выступить со своим докладом. Например, про использование Вертики в риалтайм, или про риалтайм аналитику вообще. Мы, кстати, тоже недавно начали такой проект, после того как предыдущая попытка на Кассандре (с использованием идей Twitter Rainbird) была частично успешной.
У нас много нулей, поэтому чистые цифры как правило, удавалось всегда упаковать, и выигрыша за счет использования группировок не было. Но если у Вас данные сильно вариативные — то да, наверное.
Давайте дружить, конечно. «Мы организовали» — это кто? У меня давно сидит в голове мысль, что у нас не хватает хорошего консалтинга по системам больших данных. Типа как Percona делает для MySQL.
Вопрос не совсем корректен. Что Вы понимаете под словом «обрабатывает»? Запрос к таблице из 5 миллиардов записей может занимать 5-10 секунд и меньше, но это зависит от запроса и дизайна проекций в первую очередь, а от конфигурации кластера во вторую.
Молодцы. Я вчера опять делал доклад на HighLoad, и интерес к Вертике был больше, чем в прошлом году. Много вопросов, в том числе и от тех, кто уже ее использует.
И статья тоже хорошая и подробная. Пара незначительных комментариев.
1. Памяти много не бывает, но Вертика ее расходует достаточно экономно, по сути только на WOS, на hash joins и на hashed group by. Если удается тяжелые запросы «перевести» на piplined group by и merge join — то ура, память расходуется минимально. При использовании очень сложных запросов так, конечно, никогда не получится, но всякие BI-средства обычно генерируют довольно простые запросы на стар-схему.
2. Группировка колонок — это палка о двух концах. С одной стороны — да, колонки вместе читаются как фрагмент строки, а с другой — на группированных колонках не работают енкодинги. У нас получилось, что выгодней держать колонки все же отдельно, выигрыш за счет меньшего размера на диске перевешивает преимущество чтения нескольких колонок «разом».
С Хадупом Вертику можно сравнивать, но сравнение будет не совсем корректно, потому что это системы разного предназначения. Для тех задач, для которых Вертика проектировалась (типичный OLAP), Хадуп потребует в 10 раз больше серверов. Но точно так же есть класс задач, где Хадуп будет эффективнее Вертики.
Честно говоря, не уверен. Надо бы у них спросить. На сайте есть только новость годичной давности, где да, объявлено, что 3 ноды. Но с другой стороны, 3 ноды абсолютно бесполезны. По нашему опыту это мертвая инсталляция, так поиграться только, как с кластером обращаться. Накладные расходы на сеть между нодами и дополнительное склеивание данных на ноде-инициаторе сводят на нет преимущество кластера. Более-менее нормальная производительность начинается от пяти нодов. А вот однонодовая Вертика с быстрыми дисками — это очень неплохой вариант, и мы его вовсю используем для задач среднего объема. Если хочется дешево и сердито получить возможность гонять запросы на данных до терабайта — это очень неплохой вариант.
Роман, прошу прощения за критику, но мне 'либоОбаНеВСвоёмУмеЛибоОбаВСвоёмУме' и 'обеНеМогутБытьНеВСвоёмУме' кажутся очень неестественными, несмотря на «естественность» языка. Если уж использовать DSL, то делать это максимально естественно. А то ни рыба, ни мясо. Я поленился (время отнимает), хотя можно было. А вот решение на Лиспе, где получился почти естественный язык, хоть и со скобками, мне очень понравилось именно по этой причине.
Но вот что понравилось в Вашем решении — это 'варианты душевного состояния'. Какой-то метафизикой от них веет :) И проблема останова.
Мы не пробовали, но из того, что я знаю про HBASE, есть несколько существенных ограничений:
— не поддерживается SQL (эмуляции типа Hive — это слезы)
— трудно, если вообще возможно, получить приемлимую производительность для «простых» запросов, которые должны выполняться быстрее секунды
Кроме того, на момент принятия решения HBase не была доступна, и была очень сырой. Она и сейчас еще сырая.
Надеюсь, что на следующем митапе кто-нибудь сделает доклад и на счет Hadoop. Мы рассказывали только о своем опыте. Технологий сейчас много, и как еще Кузьма Прутков говорил: «нельзя объять необъятное». Особенно по-одиночке. Вместе можно. Поэтому мы призываем к формированию открытого коллективного опыта. За плюс спасибо, мы старались.
Математика там довольно сложная, чтобы можно было ее объяснить на двух слайдах. Ничего сверхъестественного, впрочем. Но к большим системам/нагрузкам это не имеет непосредственного отношения. Такая же математика будет работать в случае системы и с одним сервером.
Там есть драйвера JDBC и ODBC. Мы пользуемся драйверами двух-трех летней давности, но недавно было обновление. Если протокол не меняется, то зачем менять драйвера? Вертиковцы сразу поддержали JDBC-спецификацию в полном объеме.
Разрушение и перестройка существующих связей — в общем случае дорогостоящая операция. Добавление новых там, где их не было, — дешевая. Я напишу на следующей неделе статью про физическую организацию данных в Вертике, и из нее это станет более понятно.
2. Да, плюс любые исторические данные, которые мы посчитаем нужными. Стандартный минимальный набор — всего несколько гигабайт, перенос которых занимает меньше получаса.
3. Предварительную обработку можно разбросать по разным серверам, тем самым разгрузив сеть и локальные диски. В конечном итоге данные попадают на один DWH-кластер, и перемешиваются там в соответствии с логикой базы данных, а не тем, откуда и как приходят данные.
О, спасибо за пространный комментарий с хорошими вопросами. Попробую ответить.
Название Вы предложили, не я. Мы это называем мультиплексированием.
Потеря производительности есть в том случае, когда звенья связаны и работают синхронно. У нас звенья развязаны и работают асинхронно.
Целостность данных — это проблема. Честно говоря, мне казалось, что я написал о проблемах, и это одна из них. Но, видимо, только собирался. Чуть позже допишу в пост, а пока отвечу тут. Дело в том, что нам не нужна стопроцентная целостность, так как рекламный бизнес сам по себе статистический, и незначительные отклонения несущественны. Поэтому мы не контролируем целостность на постоянной основе, но следим за тем, чтобы деньги считались одинаково, и если они по тем или иным причинам расходятся, то синхронизируем их с одного из инстансов, которые мы считаем формальным мастером. Это достаточно делать раз в день.
Полную копию работающей базы можно получить не возможно, но можно получить ее «клон», достаточный для выполнения задач. Стандартный процесс для этого следующий:
1. Включить новую базу, заполнить ее целиком данными онтологии и описания компаний.
2. скопировать исторические данные (небольшие агрегаты), которые существенны для ее работы.
3. Дать новой базе остояться неделю-две, пока она накопит достаточное количество детализированных данных.
Этот процесс можно ускорять, перенося на втором этапе больше данных, но как правило пара недель — это вполне допустимый срок. Сырые данные и факты мы не храним больше двух недель, так как они во-первых, не нужны, а во-вторых, занимают очень много места. Весь вопрос в том, сколько времени есть на восстановление и какова желетельная степень идентичности.
Базы синхронизируется естественным образом. Короткий таймаут (до суток) просто означает, что скопились незагруженные в эту базу данные. Их достаточно догрузить, и база догонит текущее состояние. Это сходно с репликацией. когда слейв можно остановить, потом включить, и он догонит накопившиеся изменения. Более длинных таймаутов в нашей практике не было, но если они произойдут, то вместо загрузки данных через ETL, нужно будет их скопировать с других серверов. Это быстрее.
И отвечая на последнюю серию вопросов:
a) Не могу сказать, не измеряли, в интерфейс влезает. В строках БД сейчас — около миллиарда фактов в день, большинство фактов — больше сотни значимых колонок.
б) да
в) Другой сервер БД означает другие ETL сервера. В записях появится другой server_id, чтобы мы понимали, откуда она пришла
г) узкое место у железа — это всегда диск. У системы в целом — конечная точка, так как там данные сливаются в общую картину и агрегируются. Масштабирование в этой точке похоже на перестройку 5го рейда, то есть недешево. В остальных частях масштабирование линейное добавлением серверов.
Я рад, что разъяснил возникшее недоразумение. Добавил в конце статьи некоторый контекст проблемы.
Железо и диски сейчас дешевы. Отказ системы стоит гораздо дороже. Нашей целью было сделать максимально простую в администрировании систему, с максимально свободными связями и возможностями восстановления.
Давайте дружить, конечно. «Мы организовали» — это кто? У меня давно сидит в голове мысль, что у нас не хватает хорошего консалтинга по системам больших данных. Типа как Percona делает для MySQL.
И статья тоже хорошая и подробная. Пара незначительных комментариев.
1. Памяти много не бывает, но Вертика ее расходует достаточно экономно, по сути только на WOS, на hash joins и на hashed group by. Если удается тяжелые запросы «перевести» на piplined group by и merge join — то ура, память расходуется минимально. При использовании очень сложных запросов так, конечно, никогда не получится, но всякие BI-средства обычно генерируют довольно простые запросы на стар-схему.
2. Группировка колонок — это палка о двух концах. С одной стороны — да, колонки вместе читаются как фрагмент строки, а с другой — на группированных колонках не работают енкодинги. У нас получилось, что выгодней держать колонки все же отдельно, выигрыш за счет меньшего размера на диске перевешивает преимущество чтения нескольких колонок «разом».
С Хадупом Вертику можно сравнивать, но сравнение будет не совсем корректно, потому что это системы разного предназначения. Для тех задач, для которых Вертика проектировалась (типичный OLAP), Хадуп потребует в 10 раз больше серверов. Но точно так же есть класс задач, где Хадуп будет эффективнее Вертики.
А Терадата лидер, конечно, но стоит, как самолет.
Но вот что понравилось в Вашем решении — это 'варианты душевного состояния'. Какой-то метафизикой от них веет :) И проблема останова.
— не поддерживается SQL (эмуляции типа Hive — это слезы)
— трудно, если вообще возможно, получить приемлимую производительность для «простых» запросов, которые должны выполняться быстрее секунды
Кроме того, на момент принятия решения HBase не была доступна, и была очень сырой. Она и сейчас еще сырая.
2. Да, плюс любые исторические данные, которые мы посчитаем нужными. Стандартный минимальный набор — всего несколько гигабайт, перенос которых занимает меньше получаса.
3. Предварительную обработку можно разбросать по разным серверам, тем самым разгрузив сеть и локальные диски. В конечном итоге данные попадают на один DWH-кластер, и перемешиваются там в соответствии с логикой базы данных, а не тем, откуда и как приходят данные.
Название Вы предложили, не я. Мы это называем мультиплексированием.
Потеря производительности есть в том случае, когда звенья связаны и работают синхронно. У нас звенья развязаны и работают асинхронно.
Целостность данных — это проблема. Честно говоря, мне казалось, что я написал о проблемах, и это одна из них. Но, видимо, только собирался. Чуть позже допишу в пост, а пока отвечу тут. Дело в том, что нам не нужна стопроцентная целостность, так как рекламный бизнес сам по себе статистический, и незначительные отклонения несущественны. Поэтому мы не контролируем целостность на постоянной основе, но следим за тем, чтобы деньги считались одинаково, и если они по тем или иным причинам расходятся, то синхронизируем их с одного из инстансов, которые мы считаем формальным мастером. Это достаточно делать раз в день.
Полную копию работающей базы можно получить не возможно, но можно получить ее «клон», достаточный для выполнения задач. Стандартный процесс для этого следующий:
1. Включить новую базу, заполнить ее целиком данными онтологии и описания компаний.
2. скопировать исторические данные (небольшие агрегаты), которые существенны для ее работы.
3. Дать новой базе остояться неделю-две, пока она накопит достаточное количество детализированных данных.
Этот процесс можно ускорять, перенося на втором этапе больше данных, но как правило пара недель — это вполне допустимый срок. Сырые данные и факты мы не храним больше двух недель, так как они во-первых, не нужны, а во-вторых, занимают очень много места. Весь вопрос в том, сколько времени есть на восстановление и какова желетельная степень идентичности.
Базы синхронизируется естественным образом. Короткий таймаут (до суток) просто означает, что скопились незагруженные в эту базу данные. Их достаточно догрузить, и база догонит текущее состояние. Это сходно с репликацией. когда слейв можно остановить, потом включить, и он догонит накопившиеся изменения. Более длинных таймаутов в нашей практике не было, но если они произойдут, то вместо загрузки данных через ETL, нужно будет их скопировать с других серверов. Это быстрее.
И отвечая на последнюю серию вопросов:
a) Не могу сказать, не измеряли, в интерфейс влезает. В строках БД сейчас — около миллиарда фактов в день, большинство фактов — больше сотни значимых колонок.
б) да
в) Другой сервер БД означает другие ETL сервера. В записях появится другой server_id, чтобы мы понимали, откуда она пришла
г) узкое место у железа — это всегда диск. У системы в целом — конечная точка, так как там данные сливаются в общую картину и агрегируются. Масштабирование в этой точке похоже на перестройку 5го рейда, то есть недешево. В остальных частях масштабирование линейное добавлением серверов.
Железо и диски сейчас дешевы. Отказ системы стоит гораздо дороже. Нашей целью было сделать максимально простую в администрировании систему, с максимально свободными связями и возможностями восстановления.