Что же происходит на рынке IT-труда в США?

[АццкоМото]

Ладно, убедил, не нужны базы данных, все нужно в кешах хранить. А мы то идиоты мучаемся.

Я не говорил про хранение всего в кэше, я говорил, что если база данных занята, то данные могут и подождать в очереди. Необработанные и в оперативке. Мелкие данные типа usage statistics. Если речь про какие-нибудь google street view данные из машин, бороздящих просторы вселенной - могут быть совсем другие соображения

А какие возражения по финансовым транзакциям буду - тоже ерунда?

абсолютная ерунда. за то время, как средний пользователь наблюдает "please wait while we are authorizing your transaction" данные можно записать руками на листик в восемнадцати копиях.

А это здесь при чем? Это одна и та же задача и данные приходят одного и того же мобильного SDK. Просто клиенты разные.

Ну ты сейчас сводишь проблему к классической проблеме "впихнуть невпихуемое". Задача скейлится идеально. На каждое накидывание нового клиента можно накидывать новых серверов в облако. А пользователю SDK (ака Rovio в твоем примере) вообще должно быть перпендикулярно, какие там еще есть клиенты

ну это все на девайсе надо аггрегировать, а не тупо постить на сервер каждый пук пользователя. и упаковывать нормально, а не выдавать высеры типа
{"event":"button_pressed", "which_button":"this big red button which is next to proceed to next level button"}

клиенты иной раз хотят schemaless данные.

Ну, я так понимаю, что это никак не мешает передать вместо "event":"button_pressed" что-то типа 0xF2, а вместо "which_button":"this big red button which is next to proceed to next level button" - 0x4DB2
А еще лучше - вместо того, чтобы передавать одно и то же 300 раз подряд - просто передать, что кнопка А была нажата 280 раз, а кнопка Б - 20 раз

[crypto5]

Ладно, убедил, не нужны базы данных, все нужно в кешах хранить. А мы то идиоты мучаемся.

Я не говорил про хранение всего в кэше, я говорил, что если база данных занята, то данные могут и подождать в очереди.

Это то как работает кассандра - держит и агрегирует данные в памяти, при этом их можно запрашивать, когда память близка к заполнению дампит данные на диск.

[АццкоМото]

https://play.google.com/store/apps/deta ... irds&hl=en

От 100 до 500 млн (а там еще есть разные версии).
Это не считая iOS девайсов.
Но не в этом суть.

дык это за сколько лет. в такой статистике я раз 20 посчитан. и это - самая популярная мобильная побрякуха в истории

[Интеррапт]

Ну ты сейчас сводишь проблему к классической проблеме "впихнуть невпихуемое". Задача скейлится идеально.

О, правильно, наконец-то ты сам заговорил о scalability. Для которых NoSQL солюшены (типа той же Кассандры) и предназначены, за счет кое-какой потери в функциональности (тех же самых query с join) - добиться лучше масштабируемости.

На каждое накидывание нового клиента можно накидывать новых серверов в облако.

Да, действительно. А еще лучше накидывать новые сервера с новой базой вообще на каждого мобильного пользователя. Ресурсы то ведь небось бесплатные? Только вот в реальном мире, а не в идеально, денежку считать приходится и вопросы скайлабилити приходится решать без того, чтобы на каждый чих добавлять новый нод в кластер.

А еще лучше - вместо того, чтобы передавать одно и то же 300 раз подряд - просто передать, что кнопка А была нажата 280 раз, а кнопка Б - 20 раз

Ну и что это даст? Обычно интересует последовательность действий (нажали то-то, перешли туда, там нажали, вернулись, еще чего-то нажали).

[crypto5]

Ну ты сейчас сводишь проблему к классической проблеме "впихнуть невпихуемое". Задача скейлится идеально.

О, правильно, наконец-то ты сам заговорил о scalability. Для которых NoSQL солюшены (типа той же Кассандры) и предназначены, за счет кое-какой потери в функциональности (тех же самых query с join) - добиться лучше масштабируемости.

На самом деле джойн - это как раз мотивация NoSql, это очень затратная операция, а например в кассандре ее легко предпосчитать и заденормализировать.

[Интеррапт]

На самом деле джойн - это как раз мотивация NoSql

Ес-но я имел в виду нормализированные данные (при котором запрос можно построить на многих таблицах без дублирования данных), а не то, каким образом join в nosql мире решается за счет денормализации. Простота и затратность (в случае с SQL базами) против эффективности и меньше затратности (в случае с NoSQL).

[crypto5]

На самом деле джойн - это как раз мотивация NoSql

Ес-но я имел в виду нормализированные данные, а не то, каким образом join в nosql мире решается за счет денормализации.

А джойн на нормализированных данных в NoSql тоже можно легко реализовать, просто в большинстве баз его пока нету.

[Интеррапт]

На самом деле джойн - это как раз мотивация NoSql

Ес-но я имел в виду нормализированные данные, а не то, каким образом join в nosql мире решается за счет денормализации.

А джойн на нормализированных данных в NoSql тоже можно легко реализовать, просто в большинстве баз его пока нету.

Совсем даже не легко, особенно если данные валяются физически на разных нодах. В том же самом GAE, например, это решалось при помощи того, что данные должны находится в пределах одной entity group (что подразумевало, физически находится на одной машине). Т.е. реализовать, конечно, можно, но это уже будет довольно затратно.

[crypto5]

На самом деле джойн - это как раз мотивация NoSql

Ес-но я имел в виду нормализированные данные, а не то, каким образом join в nosql мире решается за счет денормализации.

А джойн на нормализированных данных в NoSql тоже можно легко реализовать, просто в большинстве баз его пока нету.

Совсем даже не легко, особенно если данные валяются физически на разных нодах. В том же самом GAE, например, это решалось при помощи того, что данные должны находится в пределах одной entity group (что подразумевало, физически находится на одной машине). Т.е. реализовать, конечно, можно, но это уже будет довольно затратно.

Наивный джойн будет строк 10-20 на скале ))

[Интеррапт]

Наивный джойн будет строк 10-20 на скале ))

А тупые разработчики Кассандры и подобных баз никак не могут додуматься до этих 10-20 строк для не ad-hoc случаев. Хотя скорее всего они просто понимают, что это дорогущая операция и нет приемлемого решения (если это не ad-hoc ес-но). Вот и оставляют на усмотрения разработчика.

[crypto5]

Наивный джойн будет строк 10-20 на скале ))

А тупые разработчики Кассандры и подобных баз никак не могут додуматься до этих 10-20 строк для не ad-hoc случаев. Хотя скорее всего они просто понимают, что это дорогущая операция и нет приемлемого решения (если это не ad-hoc ес-но). Вот и оставляют на усмотрения разработчика.

есть много распределенных баз где умные разработчики как то умудрились реализовать join-ы, у разработчиков кассандры видимо свои приоритеты

[Интеррапт]

есть много распределенных баз где умные разработчики как то умудрились реализовать join-ы, у разработчиков кассандры видимо свои приоритеты

У Гугла тоже свои приоритеты похоже. Тоже с JOIN для BigTable не торопятся. И разработчики MongoDB тоже не торопятся. Аналогично с HBase. И аналогично с подавляющим большинством популярных NoSQL решений.

[crypto5]

есть много распределенных баз где умные разработчики как то умудрились реализовать join-ы, у разработчиков кассандры видимо свои приоритеты

У Гугла тоже свои приоритеты похоже. Тоже с JOIN для BigTable не торопятся.

Ну вам виднее

И разработчики MongoDB тоже не торопятся. Аналогично с HBase.

У этих пока что других проблем хватает, рано или поздно дойдут я думаю.

[АццкоМото]

О, правильно, наконец-то ты сам заговорил о scalability. Для которых NoSQL солюшены (типа той же Кассандры) и предназначены, за счет кое-какой потери в функциональности (тех же самых query с join) - добиться лучше масштабируемости.

Для сбора usage statistics не то, что query с join не нужен - даже вообще база данных не особо нужна. Хоть SQL, хоть NoSQL. С ней просто привычнее.

На каждое накидывание нового клиента можно накидывать новых серверов в облако.

Да, действительно. А еще лучше накидывать новые сервера с новой базой вообще на каждого мобильного пользователя. Ресурсы то ведь небось бесплатные? Только вот в реальном мире, а не в идеально, денежку считать приходится и вопросы скайлабилити приходится решать без того, чтобы на каждый чих добавлять новый нод в кластер.

Мы только что посчитали, что цена вопроса - копеечная. В применении опять же к статистике использования мобильных приложений. Если для Злых Птиц хостинг статистики копеечный, то кому вообще в налогичных ситуациях нужно париться?
Возможно, для стартапа, который пытается подмять под себя рынок мобильной статисктики использования (кажется, такой в Сиэттле засветился недавно) это может сыграть роль за счет объемов, не знаю. Ну как в супермаркет сходить за яйцами. Что они 2 доллара за дюжину стоят, что 3 - и мне и тебе будет пофиг. Конторе, которая оставляет 100500 миллионов таких коробок во все Воллмарты страны - наверное, важно

А еще лучше - вместо того, чтобы передавать одно и то же 300 раз подряд - просто передать, что кнопка А была нажата 280 раз, а кнопка Б - 20 раз

Ну и что это даст? Обычно интересует последовательность действий (нажали то-то, перешли туда, там нажали, вернулись, еще чего-то нажали).

[/quote]
Ну как что... есть же паттерны использования. Использование "птичек" сводится к очень простым сценариям - типа "запустил, перешел к последнему непройденному уровню, прошел 17 новых, на первый ушло 15 секунд и 1 попытка, на второй - минута и 3 попытки.... пара сотен байт. А если проанализировать хорошо паттерны, то хватит и байта: сегодня был паттерн номер 42. Все. Нафиг эти нажатия на кнопочки, никому это не нужно, на самом деле

[Интеррапт]

Для сбора usage statistics не то, что query с join не нужен - даже вообще база данных не особо нужна. Хоть SQL, хоть NoSQL. С ней просто привычнее.

Так вообще ничего не нужно. Можно по старой доброй традиции велосипеды изобретать для любой задачи.

А если проанализировать хорошо паттерны, то хватит и байта: сегодня был паттерн номер 42. Все. Нафиг эти нажатия на кнопочки, никому это не нужно, на самом деле

Это всего-лишь один из аспектов mobile analytics А дальше уже ключевые слова "advertisement", "A/B testing", "predictable analytics", "user retention", "recommendations" и т.п. А ты приходи и рассказывай заказчику, как ты ему сейчас систему смастеришь на кешах. Озолотишься

[АццкоМото]

Для сбора usage statistics не то, что query с join не нужен - даже вообще база данных не особо нужна. Хоть SQL, хоть NoSQL. С ней просто привычнее.

Так вообще ничего не нужно. Можно по старой доброй традиции велосипеды изобретать для любой задачи.

Ну ты же грамотный чел, прекрасно понимаешь, где проходят границы между сценариями 1. написать хреново, но быстро, а если что - переписать, 2. написать более-менее стандартно, а если что - добавить серверов 3. изобрести велосипед и порвать всех на объемах, потому что наш велосипед на 3,5% велосипедее всех остальных велосипедистых велосипедов

Это всего-лишь один из аспектов mobile analytics А дальше уже ключевые слова "advertisement", "A/B testing", "predictable analytics", "user retention" и т.п. А ты приходи и рассказывай заказчику, как ты ему сейчас систему смастеришь на кешах. Озолотишься

Что-то терзают меня смутные думки...
Вкратце - с чего заказчика должно вообще колебать, какие у меня там кэши? Он с вероятностью в 146% смотрит на Гоголь-Онолитег и только невероятно языкастые стартапы могут его переубедить и заставить его пользоваться другим сервисом из-за другого подхода, который якобы кошернее. Кэш, NoSQL, масштабируемость - вообще ниачом

[Интеррапт]

Что-то терзают меня смутные думки...
Вкратце - с чего заказчика должно вообще колебать, какие у меня там кэши?

Заказчика? Ни с чего. Просто пока ты будешь сам строить свои кэш велосипеды, вместо того, чтобы брать готовые решения - то с вероятностью 146% вылетишь в трубу. Еще и не факт, что сможешь что-то удачное сделать.

Он с вероятностью в 146% смотрит на Гоголь-Онолитег и только невероятно языкастые стартапы могут его переубедить и заставить его пользоваться другим сервисом из-за другого подхода, который якобы кошернее.

Т.е. про Flurry, Localytics и т.п. не слыхал? Один только Flurry обслуживает больше инсталляций нейтивных мобильных приложений, чем Google Analytics, а ты тут чего-то про 146% рассказываешь (сколько там сейчас у Flurry? что-то вроде 2.5 млрд сессий в день, это умножь на хрен его знает сколько log events). Ага, держи и обрабатывай все в "кешах"

Про "себя" я молчу, мы в основном обслуживаем enterprise кастомеров с заточкой аналитики под конкретных заказчиков.

[АццкоМото]

Заказчика? Ни с чего. Просто пока ты будешь сам строить свои кэш велосипеды, вместо того, чтобы брать готовые решения - то с вероятностью 146% вылетишь в трубу. Еще и не факт, что сможешь что-то удачное сделать.

Да перестань. Обычная очередь реализуется быстрее, чем мы тут терки трем. И кода в ней меньше, чем мы тут буковок истоптали.

Т.е. про Flurry, Localytics и т.п. не слыхал? Один только Flurry обслуживает больше инсталляций нейтивных мобильных приложений, чем Google Analytics, а ты тут чего-то про 146% рассказываешь (сколько там сейчас у Flurry? что-то вроде 2.5 млрд сессий в день, это умножь на хрен его знает сколько log events). Ага, держи и обрабатывай все в "кешах"

Я тем не менее не вижу, в каком месте скорость записи стала критичной
В 2.5 миллиарда сессий в день я не поверю даже под страхом расстрела. Это просто феерическая фигня. Столько смартфонов в мире едва наберется. При этом не вижу ничего выдающегося в числе как таковом - за неделю сделаю бесплатно платформу, которая это всосет и не подавится. Без красивых картинок, конечно.

[Интеррапт]

В 2.5 миллиарда сессий в день я не поверю даже под страхом расстрела. Это просто феерическая фигня. Столько смартфонов в мире едва наберется.

При чем тут кол-во смартфонов? Сессия - это когда ты открыл приложение, поработал (поиграл), закрыл. Потому через час опять открыл - это уже вторая сессия. Таких за день (сессий работы с приложением) может с десяток набегать в день для одного приложения. А есть еще другие приложения.

При этом не вижу ничего выдающегося в числе как таковом - за неделю сделаю бесплатно платформу, которая это всосет и не подавится.

Не понял, что именно ты сделаешь? За неделю напишешь Big Data решение для кластера, с "no single point of failure", с "multi data center" репликацией, со scalability, когда ты просто втыкаешь машину в нод и read/write у тебя линейно вырастает? С поддержкой redundancy и disaster recovery? С поддержкой MapReduce? С query языком, чтобы все-таки иметь возможность для выборки данных? Давай, делай, откроешь стартап. Я честно признаю, что у меня бы одному и несколько лет не хватило на что-либо подобное даже в упрощенном виде, просто банально не хватило бы знаний, а тут неделя.

[АццкоМото]

При чем тут кол-во смартфонов? Сессия - это когда ты открыл приложение, поработал (поиграл), закрыл. Потому через час опять открыл - это уже вторая сессия. Таких за день (сессий работы с приложением) может с десяток набегать в день для одного приложения. А есть еще другие приложения.

Ну, дружище, я же тоже не совсем идиот, знаю, что такое сессия. Задачка из серии "сколько камертонов во Флориде" - вроде это из Вашингтона пошло, разве нет? Если в мире - предположим - 2,5 миллиарда смартфонов, то минимум 50% людей даже не знают, что это смартфоны. Ну, звонят-фотают, не больше. Из оставшихся процентов 80 пользуются очень стандартным набором софта - мыло, плюсики, фейсбучек, браузер, твитырь. Из оставшихся значительная часть пользуется всем тем же, что и предыдущие, но с национальнвм колоритом. Что там в Китае вместо твитыря, принадлежит, кажется, Байду? И только среди оставшихся попадаются клиенты Flurry, большинство из которых, я уверен, генерируют благо если одну сессию в неделю. Точную оценку хрен сделаешь, но в 2,5 ярда сессий не верю никак.

Не понял, что именно ты сделаешь? За неделю напишешь Big Data решение для кластера, с "no single point of failure", с "multi data center" репликацией, со scalability, когда ты просто втыкаешь машину в нод и read/write у тебя линейно вырастает? С поддержкой redundancy и disaster recovery? С поддержкой MapReduce? С query языком, чтобы все-таки иметь возможность для выборки данных? Давай, делай, откроешь стартап. Я честно признаю, что у меня бы одному и несколько лет не хватило на что-либо подобное даже в упрощенном виде, просто банально не хватило бы знаний, а тут неделя.

Я за неделю сделаю складывание http requests с репортами в очередь в памяти, offload ее на диск, если на памяти волки срать уехали, подгрузку обратно если волки вернулись плюс банальнейшее сжатие на стороне клиента по типу WBXML. Абсолютно с no single point of failure, масштабируемо (для этого даже ничего делать не надо на самом-то деле), а бигдата и прочий процессинг - out of scope, потому что его так и сяк должно делать. И map-reduce туда же. Уверен, ты все то же сделаешь в 2 раза быстрее меня, а не за несколько лет

[Komissar]

не ссорьтесь, горячие финские парни.

[Интеррапт]

Ну, дружище, я же тоже не совсем идиот, знаю, что такое сессия. Задачка из серии "сколько камертонов во Флориде" - вроде это из Вашингтона пошло, разве нет? Если в мире - предположим - 2,5 миллиарда смартфонов, то минимум 50% людей даже не знают, что это смартфоны. Ну, звонят-фотают, не больше. Из оставшихся процентов 80 пользуются очень стандартным набором софта - мыло, плюсики, фейсбучек, браузер, твитырь. Из оставшихся значительная часть пользуется всем тем же, что и предыдущие, но с национальнвм колоритом. Что там в Китае вместо твитыря, принадлежит, кажется, Байду? И только среди оставшихся попадаются клиенты Flurry, большинство из которых, я уверен, генерируют благо если одну сессию в неделю. Точную оценку хрен сделаешь, но в 2,5 ярда сессий не верю никак.

А я верю Хотя бы потому, что я вижу, сколько сессий у нас репортится каждый день, это при том, что у нас покрытие намного меньше, чем у Flurry (Flurry работает со всеми, а мы только с paying customers).

[АццкоМото]

не ссорьтесь, горячие финские парни.

Да ну, бросьте! Чтобы с Интерраптом поссориться? Это почти невозможно

[Интеррапт]

не ссорьтесь, горячие финские парни.

Да ну, бросьте! Чтобы с Интерраптом поссориться? Это почти невозможно

Точно

[АццкоМото]

А я верю Хотя бы потому, что я вижу, сколько сессий у нас репортится каждый день, это при том, что у нас покрытие намного меньше, чем у Flurry (Flurry работает со всеми, а мы только с paying customers).

На это у меня заранее припасенный backup plan - даже если поверить в 2,5 ярда сессий в день, не пугает. Как результат конторы - чуть более, чем дофига. Как нагрузка для контупера... если только для лампового