Comments 22
Хорошее решение… единственное что не сделать это по моему Scatter диаграммы и TreeMap
но ими не так часто для анализа пользуются…
а так по идее через «условное форматирование» даже Cohort аналитику по идее можно сделать…
но ими не так часто для анализа пользуются…
а так по идее через «условное форматирование» даже Cohort аналитику по идее можно сделать…
--Мы пишем по 60 млн событий в день
это много для sqlserver?
сколько террабайт база?
это много для sqlserver?
сколько террабайт база?
Пару терабайт уже. Какой предел y MySQL по вашему мнению? Мне правда интересно.
Может sql это и потянет, но постоянно появляется желание лить туда больше и больше, причём в разы. Поэтому я всё-таки боюсь за масштабируемость в sql мире.
Может sql это и потянет, но постоянно появляется желание лить туда больше и больше, причём в разы. Поэтому я всё-таки боюсь за масштабируемость в sql мире.
самая большая база изображений мире на MSSQL (после гугля я думаю) www.terraserver.com/ — сотни петабайт
федеральная база позволяет масштабировать горизонтально habrahabr.ru/company/epam_systems/blog/192984/
федеральная база позволяет масштабировать горизонтально habrahabr.ru/company/epam_systems/blog/192984/
Мне тоже показалось, что до ограничений MySQL еще очень далеко.
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.
Правильная структура данных + правильная агрегация под те или иные нужны творят чудеса!
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.
Правильная структура данных + правильная агрегация под те или иные нужны творят чудеса!
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.
Можно об этом чуть подробнее?
Попробую.
Есть лог событий, приходит на сервер в виде текстового файла длиной в минуту (порядка 6-9 млн записей). Лог содержит id юзеров, id событий, ip адреса, время и прочую информацию.
Загружаем данные в MySQL через LOAD DATA INFILE (самая быстрая операция в MySQL), по моим прикидкам предел для LOAD DATA INFILE где-то на уровне 40-50 млн. записей в минуту.
Потом удаляем дубликаты записей через INSERT IGNORE в MEMORY таблицу. Никакой движок на дисках не справиться с этим, проверено!
Собрав час бросаем таблицу на диски и дальше уже либо прямо тут делаем агрегацию (например подсчет юзеров на каждое событие), либо уносим на реплику и там делаем агрегацию.
Агрегированную информацию сохраняем в отдельные статичные таблицы, и уже с них работает frontend.
В общем у нас получилось наши задачи сделать на MySQL, но в реальности все конечно зависит от кейсов. Наверное есть такие задачи, которые в MySQL не сделать, но я пока не встречал. :-)
Есть лог событий, приходит на сервер в виде текстового файла длиной в минуту (порядка 6-9 млн записей). Лог содержит id юзеров, id событий, ip адреса, время и прочую информацию.
Загружаем данные в MySQL через LOAD DATA INFILE (самая быстрая операция в MySQL), по моим прикидкам предел для LOAD DATA INFILE где-то на уровне 40-50 млн. записей в минуту.
Потом удаляем дубликаты записей через INSERT IGNORE в MEMORY таблицу. Никакой движок на дисках не справиться с этим, проверено!
Собрав час бросаем таблицу на диски и дальше уже либо прямо тут делаем агрегацию (например подсчет юзеров на каждое событие), либо уносим на реплику и там делаем агрегацию.
Агрегированную информацию сохраняем в отдельные статичные таблицы, и уже с них работает frontend.
В общем у нас получилось наши задачи сделать на MySQL, но в реальности все конечно зависит от кейсов. Наверное есть такие задачи, которые в MySQL не сделать, но я пока не встречал. :-)
Интересно. А какие преимущества для себя видите в использовании MySQL?
Главное преимущество в том, что я и другие сотрудники достаточно глубоко знают MySQL. Это максимально ускоряет разработку, ибо не требует время на изучение, внедрение и поддержку новых технологий.
Я больше чем уверен, что многие разработчики просто ленятся глубоко копать SQL, а вместо этого, при первом же затыке бегут на Хабр читать что у нас там нового из NOSQL появилось (сам не раз спорил с сотрудниками по этому поводу).
Повторюсь, я не исключаю возможности использования каких-нибудь других решений. Просто пока задачи решаются на MySQL, они решаются на MySQL.
Я больше чем уверен, что многие разработчики просто ленятся глубоко копать SQL, а вместо этого, при первом же затыке бегут на Хабр читать что у нас там нового из NOSQL появилось (сам не раз спорил с сотрудниками по этому поводу).
Повторюсь, я не исключаю возможности использования каких-нибудь других решений. Просто пока задачи решаются на MySQL, они решаются на MySQL.
NoSQL предоставляют скорее административно-технологические преимущества, а не преимущества языка или еще что-то. Удобная масштабируемость кластера, репликации, возможность легкой работы с большими объемами данных (в том же Риаке новые ноды добавляются в кластер за пару десятков секунд, миграция данных в кластере происходит автоматически). Из возможностей «для разработчика» — пожалуй только хранение длинных вложенных объектов, что само по себе бывает необходимо не так уж часто. В остальных случаях большинство NoSQL и NewSQL — это наоборот слегка урезанные «ущербные» SQL-образные вещи. В той же Кассандре, например, SQL убогий настолько, что использовать его для чего-то большего, чем select * from table where id=1 — практически невозможно. С другой стороны, Кассандра — особенно в кластере — показывает такие скорости записи, что я даже не могу себе представить, сколько человеко-часов потребовалось бы для настройки аналогичного кластера на MySQL.
Все это здорово до тех пор, пока Google не примет решение остановить любой из этих сервисов (как, например, Google Reader).
Есть такая буква в этом слове. Подозреваю что Google Sites настигнет эта участь в первую очередь. Но замену найти не сложно, не заплачу. Что касается ключевых технологий, то я вижу как они пилят Big Query прямо на глазах, не похоже, что убьют в ближайшие пару тройку лет (это при плохом сценарии). А там уже не важно, вечного ничего нет.
Мы пишем по 60 млн событий в день
А сколько это в гигабайтах? Интернет-канала хватает?
Другой вопрос, есть ли к этим данным интерфейс кроме SQL-like?
Данные можно сохранить на диск в виде текстового файла. Сохраняет Big Query в Storage проекта, а уже от туда можно скачать на диск.
Иногда операторы просят дампы логов по определённым критериям и Big Query удобен, чтобы сделать выборку (например, по определённому списку телефонных номеров) и отдать в виде csv файла. Но такие вещи как биллинг, которые нужно хранить по договору, мы конечно бэкапим и в виде лог-файлов. Это на случай проблем с Big Query.
Канала хватает. У нас распределённая система. Сервера стоят в куче дата-центров на стороне операторов. Звонки по другому не принять.
Иногда операторы просят дампы логов по определённым критериям и Big Query удобен, чтобы сделать выборку (например, по определённому списку телефонных номеров) и отдать в виде csv файла. Но такие вещи как биллинг, которые нужно хранить по договору, мы конечно бэкапим и в виде лог-файлов. Это на случай проблем с Big Query.
Канала хватает. У нас распределённая система. Сервера стоят в куче дата-центров на стороне операторов. Звонки по другому не принять.
А как вы пишете? Через файловые логи или kafka/flume/etc?
Хорошо, когда есть свобода выбора. Кстати — для ваших задач можно использовать с десяток (если не больше) различных решений — от старых добрых кластеров реляционок (кстати Postgres в этом плане постабильнее MySQL) до новых Cassandra, Riak, Hive, Storm и еще много чего.
Плюсы экосистемы Хадупа — можно использовать и SQL-подобные надстройки, и на тех же самых данных запускать более сложные map-reduce штуки.
Плюсы экосистемы Хадупа — можно использовать и SQL-подобные надстройки, и на тех же самых данных запускать более сложные map-reduce штуки.
А когда нет свободы выбора? У Вас данные секретные и их нельзя в облако лить? Тогда, конечно, сложнее.
У Big Query, конечно, много альтернатив. Меня привлекла именно лёгкость интеграции хранилища данных с другими частями системы, получилось собрать готовый продукт.
У Big Query, конечно, много альтернатив. Меня привлекла именно лёгкость интеграции хранилища данных с другими частями системы, получилось собрать готовый продукт.
Cloud-решения по определению дороже self-hosted. Сюда же относим бизнес-риски — клауд-провайдеры могут отказаться от работы с вами в любой момент безо всяких компенсаций.
Далеко не все задачи решаются в SQL, для очень многих нужны более сложные (но гибкие) Map-Reduce вычисления.
Где-то отличный thoughput на запись, но большая latency на чтение (Cassandra).
Где-то все быстро, но негибко и немасштабируемо (Redis).
Где-то все удобно и быстро, но не идеально в плане производительности для наших задач (Riak).
Поработав с самыми разными данными в течение года, мы пришли к выводу, что даже существующий зоопарк всевозможных новых решений для работы с данными далек от идеала — всегда найдется место для оптимизации, что для специфических видов бизнеса может означать снижение расходов на железо\зарплаты на десятки, если не сотни процентов.
Далеко не все задачи решаются в SQL, для очень многих нужны более сложные (но гибкие) Map-Reduce вычисления.
Где-то отличный thoughput на запись, но большая latency на чтение (Cassandra).
Где-то все быстро, но негибко и немасштабируемо (Redis).
Где-то все удобно и быстро, но не идеально в плане производительности для наших задач (Riak).
Поработав с самыми разными данными в течение года, мы пришли к выводу, что даже существующий зоопарк всевозможных новых решений для работы с данными далек от идеала — всегда найдется место для оптимизации, что для специфических видов бизнеса может означать снижение расходов на железо\зарплаты на десятки, если не сотни процентов.
Отличная статья, спасибо!
Также пользуемся инфраструктурой Google уже несколько лет.
Про плюсы Вы много написали, с ними согласна.
Есть один неприятный минус который не упомянут, но с которым мы столкнулись и не раз. Google время от времени вносит изменения в API и в какой-то момент все что написано просто перестает работать. Это неуправляемо и непредсказуемо практически в реальной жизни. А в результате текущие планы рушатся и нужно быстро латать дыры. Вот из недавнего — они изменили API функций по работе с файлами в Google Drive, у нас небольшие скрипты, но чтобы пофиксить понадобился день.
Также пользуемся инфраструктурой Google уже несколько лет.
Про плюсы Вы много написали, с ними согласна.
Есть один неприятный минус который не упомянут, но с которым мы столкнулись и не раз. Google время от времени вносит изменения в API и в какой-то момент все что написано просто перестает работать. Это неуправляемо и непредсказуемо практически в реальной жизни. А в результате текущие планы рушатся и нужно быстро латать дыры. Вот из недавнего — они изменили API функций по работе с файлами в Google Drive, у нас небольшие скрипты, но чтобы пофиксить понадобился день.
Спасибо. Всё так и есть, тоже налетал на резкие изменения. Но с другой стороны, продукт быстро развивается, на stackoverflow на половину вопросов по BigQuery отвечают разработчики и очень быстро реагируют. Думаю тут должна появиться какая-то комьюнити, которая будет заниматься оборачиванием продукта в хорошую обёртку. Я помню как пытался дружить python pandas (где я делают все сложные модели) и BigQuery. Стандартная процедура из pandas не завелась (наверное, это у меня руки кривые, но и не должно это быть сложно!). Скачал другую c github, заработала, но не делает всего, что нужно мне. В итоге проще оказалось написать самому по туториалу из гугла. Но эта процедура поломается, если гугл поменяет API, а чинить только мне. Понимаю, что нужно класть такие вещи в оперсорс, но нет времени, да и засмеют — писалось же под себя.
Sign up to leave a comment.
Lean Big Data на 6 сервисах Google