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