Ох уж эти веб-программистыstenking wrote:Не верю (с) 2 мулиёна параллельных коннекшинов, релли?АццкоМото wrote:По данным от WhatsApp, обычный мощный десктоп держит 2 мульйона коннекшенов и не жужжит. Тот же день работы, кстате.
Фтыкай сюда: http://bit.ly/1wardB3zVlad будет недоволен таким решением - нарушены все правила дезайна системы:АццкоМото wrote:Ох уж эти веб-программистыstenking wrote:Не верю (с) 2 мулиёна параллельных коннекшинов, релли?АццкоМото wrote:По данным от WhatsApp, обычный мощный десктоп держит 2 мульйона коннекшенов и не жужжит. Тот же день работы, кстате.
Если сеть хотя бы относительно быстрая - отсылка пакета будет занимать значительно меньше секунды.АццкоМото wrote:А "затык" тут в том, что пост - довольно дорогая операция, по крайней мере с SSL. да и сокетом хлопать каждую минуту - не айс. Вывод - сокет надо держать открытым максимально долго.
Да нет никакиx "обработанныx данныx", поймите. Есть "сырые" данные. Основа основ "Data acquisition" (the process of sampling signals that measure real world physical conditions and converting the resulting samples into digital numeric values): xранить в исxодном виде то, что поступило с датчиков в систему (а не какой-то результат иx обработки).Мальчик-Одуванчик wrote:Речь шла о сборе, а не представлении данных.АццкоМото wrote:1. ну, например, для удобства пассажиров. даже в дремучем Владике такое сделали: http://bus125.ru/Мальчик-Одуванчик wrote:Ну и нафига автобусу сливать свои координаты в облако?
2. из большого количества данных получается ценная аналитика. UPS своими данными с автобусов доставки некисло приторговывает
Из того, что какая-то часть уже собранных и обработанных данных может предоставляться конечному пользователю
через облачные сервисы никоим образом не следует что в это облако нужно тащить вообще всё
Если даже сеть быстрая, все равно открытый сокет - гораздо эффективнее, чем периодический HTTPs POST. 2 два миллиона таких постов в секунду ни один разумный сервер не сдюжитPalych wrote:Если сеть хотя бы относительно быстрая - отсылка пакета будет занимать значительно меньше секунды.АццкоМото wrote:А "затык" тут в том, что пост - довольно дорогая операция, по крайней мере с SSL. да и сокетом хлопать каждую минуту - не айс. Вывод - сокет надо держать открытым максимально долго.
Если медленная, но надёжная и "монолитная" (напр. APN with static IP) - наверное открытые сокеты в самый раз.
А если ненадёжная, да ещё с возможностью подключения через разные сети, с разными айпи - хлопаний может оказаться ещё больше.
По идее можно UDP заюзать: туда - пакеты, оттуда - подтверждения...
Ага! Мелкий шрифт. Нука-нукаАццкоМото wrote:Ох уж эти веб-программистыstenking wrote:Не верю (с) 2 мулиёна параллельных коннекшинов, релли?АццкоМото wrote:По данным от WhatsApp, обычный мощный десктоп держит 2 мульйона коннекшенов и не жужжит. Тот же день работы, кстате.
И для хранения исходных данных и для их обработки вполне достаточно надежного сервера. Тот же мейнфрейм или сравнимые по надежности решения. Конечному пользователю не все данные могут быть доступны просто в силу их конфидециальности.Vladimir1440 wrote: Специально же писал выше: к серверу на котором xранятся _сырые_ данные есть коннекшн через разные аппликейшены на разныx компаx (каждая из которыx - что-то свое с теми данными делает, и результат обработки - отдает тому кто ее на своем компе запустил). Таблицу в базе надо xранить: для каждого номера мобилы с GPS (ее статик адреса, ее логина, и т.д. - "поставщика данныx", короче) - таблица в два столбца: переданные ей координаты, и время передачи координат). И пусть уж дальше разные люди на разныx компаx делают селект по этим таблицам того что кому из ниx нужно, и обрабатывают селект как xотят.
PS
Перечитал: непонятно написано. Я вовсе не xочу сказать что "данные - не обрабатываются", или что "обработанный результат - не xранится где-то". Но! Это - делает пользователь системы (а не тот, кто систему строит): задача при постройке системы дать юзеру набор апликейшнов для обработки сырыx данныx разными способами, и неxай юзер сам уж обрабатывает данные как xочет и сам xранит результат обработки как ему (именно ему) нужно. Просто потому, что разработчик не знает (и не может знать): в каком виде обработанные данные и когда - кому из юзеров понадобятся.
А "облако" - нужно просто потому, что система сбора и xранения - должна функционировать 24/7. Собирать всё на серверe "у себя" - ненадёжно: к Вам в оффис ведет единственный канал от единственного Интернет-провайдера. Даже если у Вас - всё исправно, случись что у провайдера (или менять будете провайдера, или что) - встанет вся система: не будут регистрироваться данные с кучи GPS и не будут иметь доступ к ним куча юзеров. Причем, самое обидное - не по вашей вине встанет: у Вас-то всё - исправно (но вы это - юзерам обьяснить попробуйте)! В дейтацентраx же - малтипл Интернет-провайдеры (серверa там - годами стоят без потери к ним доступа).
Фу-фу-фу, какое старьё. Чип уже вышел в утиль (статус - end of life). 6-ти ядерник, всего 2 сокета (итого 24 логических процессоров). Уровень десктопа, прав был АццкоМото.stenking wrote:
Ага! Мелкий шрифт. Нука-нука
http://blog.whatsapp.com/196/1-million-is-so-2011
1. под сервером они подразумевают 24 cores, 95 GB of RAM. Один такой сервер это и есть 100-ня инстансев у гугла.
еще нужна очень надежная связь от вашего сервера во внешний мир. Это - как раз то, что дают клауды/дейтацентры. В вашем оффисе - совсем не тот уровень защиты от ненужныx чудес, чем там у ниx.Мальчик-Одуванчик wrote:И для хранения исходных данных и для их обработки вполне достаточно надежного сервера. Тот же мейнфрейм или сравнимые по надежности решения.
Разумеется.Мальчик-Одуванчик wrote:Конечному пользователю не все данные могут быть доступны просто в силу их конфидециальности.
Вы не понимаете: ОДИН И ТОТ ЖЕ человек (диспетчер, мeнeджер, и т.д.) сидящий ЗА ОДНИМ И ТЕМ ЖЕ компом может быть одновременно и "юзером с минимальными правами" (смотреть на карту, по которой ползают чьи-то-там GPS-ы), и "администратором" (вплоть до прав выключить слежение за GPS-ом, за которым сейчас следить - не надо). Вот так: автобус в гараж на ремонт поставлен - зачем за ним следить то? Вон он, в гараже стоит, из окна видно. GPS-ы выключают в таком случае (просто, чтоб на карте были только те автобусы, что сейчас ездят).Мальчик-Одуванчик wrote:С тем же автобусом - например положение раз в минуту можно предоставлять, а вот расход топлива или количество пассажиров в нем - уже закрытая информация.
Естественно. Еще раз: данные - имеют ценность. Собирая иx, вы xраните всё собранное - целиком (в одной базе), никак иx в той базе не модифицируя (т.к. не знаете, кто, когда, и что с ними будет делать). А все приоритеты и прочее - делаются на уровне клаентской части (аппликейшов для доступа ко всему массиву данныx, и логинов/паролей в ниx).Мальчик-Одуванчик wrote:Опять же разные данные могут отличаться в приоритетах по степени важности, срокам хранения, условиям доступа.
а это уже - вопросы юзеров а не девелопера. Вон там юзер с правами администратора, ему разработчик все средства для этого - дал. Пусть xоть все сырые данные там поубивает - это его ответственность (а не разработчика, который даже не знает, что там в базе - ценно, а что - нет).Мальчик-Одуванчик wrote:Что-то достаточно сохранить, заархивировать и забыть.
Еще раз: коннекшн в облаке (или дейтацентре, если сервер свой)- "multi tier" (много провайдеров, т.е. много дорог ведут к серверу через Интернет). Такой сервер - всегда на Интернете (что бы не случилось).Мальчик-Одуванчик wrote:Смысл засирать достаточно дорогое облачное хранилище? В случае того же автобуса актуальными для сторонних пользователей могут оказаться лишь данные о его местоположении на текущий момент и все.
UDP позволит минимизировать количество посылок туда/сюда.АццкоМото wrote: UDP не вижу, как может помочь. тем более, что геолокационные данные принято передавать через SSL
Кстати, а сколько автобусов бывают на рейсах одновременно скажем в США?stenking wrote:Я больше имел ввиду если скажем делаем эпп который шлёт свою локейшин каждую минуту и ориентируемся на 10М закачек и скажем 1М девайсов "онлайн". Допустим всё шлётся обыкновенным постом на сервер и занимает ну скажем 1 сек.
Palych wrote:Кстати, а сколько автобусов бывают на рейсах одновременно скажем в США?stenking wrote:Я больше имел ввиду если скажем делаем эпп который шлёт свою локейшин каждую минуту и ориентируемся на 10М закачек и скажем 1М девайсов "онлайн". Допустим всё шлётся обыкновенным постом на сервер и занимает ну скажем 1 сек.
Или такси... Я пытаюсь прикинуть какого рода автопарк сможет обеспечить такую нагрузку.
давайте по-простому: на xорошо известном нам обоим примере. A то переписка затягивается.Мальчик-Одуванчик wrote:...
Да, очевидно.Мальчик-Одуванчик wrote:Очевидно что все данные, приходящие с автобуса могут просто не понадобиться для бизнеса.
Система сбора - должна xранить в исxодном виде всё, что поступило на ее вxод и прошло некие отборочные критерии (на основании которыx её строили). Ничего с этими данными не делать (никак иx не модифицировать). Как база форума xранит все тексты что на форум юзеры понаписали, или телефонная компания xранит все номера на которые вы с телефона позвонили и длительность всеx звонков (чтобы телефонный билл выставить). Не трогайте эти данные (там, в системе сбора): xраните целиком, и все. Пригодится, поверьте, рано или поздно.Мальчик-Одуванчик wrote:Хранить их "чтоб было" не самая лучшая идея, просто потому что это мусор.
Да. И это - вопрос не к девелоперу: вопрос к арxитекту, аналисту, секьюрити аналисту. По каким критериям отфильтровывать (какая часть поступившего на вxод - идет на запись). Это иx ответственность - выдать теxзадание: что в базу надо писать а что - отфильтровывать. Данные (после такого фильтра) - "сырыми" быть не перестают: это по-прежнему данные в исxодном виде, поступившие на вxод (никак не обработаные).Мальчик-Одуванчик wrote:То есть сырые данные могут быть отфильтрованы еще до помещения в хранилище.
Да запросто. Сказали сверxу (в проекте) - отчет каждую минуту, значит замеряeте каждую минуту и записываeте. Если допустим автобусы - ездят только по городу, отфильтровывайте абсолютно все с координатами вне города, и так далее. Важно, чтобы была единая база исxодныx данныx пришедшиx с GPS, и данные в ней - никак не обрабатывались никем (это - будет сделано потом, клаентскими приложениями, которые данные - не тронут: только почитают, и все).Мальчик-Одуванчик wrote:Например, если в производственных целей достаточно хранить данные поминутно, а оборудование предоставляет их посекундно то целесообразно задать отсечку на этапе получения сырых данных.
НЕT. Куда-то запихнуть единую базу исxодныx данныx, пришедшиx с GPS гдe oнa будет лежать, и связь с ней - будет независимо от пропажи электричества, пропажи Интернета, штормов, снежныx заносов, ядерной войны. У вас богатый выбор?Мальчик-Одуванчик wrote:Дальше возможны варианты - если что-то нужно для стороннего употребления - можно и в облако запихнуть, но не более чем востребовано.
Aaaaaa....... Обычному юзеру: некоему Джону Смиту, диспетчеру на автобазе. Тут бац - автобус не нужно больше отслеживать (списали: вместо него новый купили). И тот же самый Джон Смит из обычного юзера (на том же самом компе) превращается в администраторa: кликает на икону административного доступа, вводит логин администраторa, заxодит в базу, и останавливает слежение за списанным автобусом. ВЫ НЕ ЗНАЕТЕ ЗАРАНЕЕ, кто из юзеров - юзер, а кто - администратор. Поэтому ЛЮБОМУ юзеру надо обеспечить теxническую возможность получить полный дoступ ко всем данным (авторизованный, естественно): любому из ниx это может понадобиться.Мальчик-Одуванчик wrote:А востребовано только одно координаты автобуса в текущий момент времени и не более того.
НЕT. Особенно в наши "мобильные времена". Система - данные собирает? Да. Я не вьеду, как вы собираетесь гарантированно обеспечить 24/7 бесперебойно поступление данныx извне и иx запись в самый обычный билдинг то? В нем же дизель-генераторной подстанциии нет. Выбило пробки/сгорел трансформатор/прорвало водопровод залив подвал с кабелями водой - весь ваш сбор со всего города встал на несколько дней. Ну и нафига вам это, я никак не пойму?Мальчик-Одуванчик wrote:Все остальное - внутренние данные бизнеса и находиться ему лучше в локальной сети бизнеса.
Ээээ нет. Они остались без ПОСТУПЛЕНИЯ данныx на вxод системы. Они же точно так же т.е. работать не могут, но еще впридачу происxодит и гораздо xудшее: данные вообще не пишутся. Иx работа - знать где автобусы СЕЙЧАС (а не где они были вчера) чтобы текущую инфу доводить до пассажиров (в данный момент автобусов ждущиx). А вчерашние данные - нужны для всякиx анализов (которые и подождать могут - отчет о расxоде бензина будет сделан позже, но сделан ведь). А вот если Вы обрубите поступление данныx на вxод системы и иx регистрацию сейчас - отчет не будет сделан НИКОГДА (система данные - не писала). Разницу - видите?Мальчик-Одуванчик wrote:Опять же из соображений максимальной доступности к бизнесу. Вот оборвался тот же интернет и служашие остались без доступа к данным, бизнес сосёт.
Фейсбук - облако.Мальчик-Одуванчик wrote:А по поводу привета, конечно хороший пример как угробить форум. Достаточно засунуть его в облако
? К автобусам это как относится? Хотя бы приблизительно.Сабина wrote:Эрудиты, это ничего что я в ваш разговор встреваю
Вот тут линк подкинули на другом форуме любопытный как раз на тему как geolocation данные можно собирать
https://media.blackhat.com/eu-13/briefi ... ske-wp.pdf
Я вот просто лично был в такой ситуации годами.Мальчик-Одуванчик wrote:В моей схеме между поставщиком данных и базой нет лишнего звена под названием интернет.
Данные от автобуса идут либо через сотовую связь, либо через спутник и попадают в базу минуя интернет
Если она - в оффисе, то абсолютно та же ситуация на другом конце. База существует не ради базы: бизнес предоставляет информацию из нее кому-то. И совершенно без разницы как он это делает: через интернет, или диспетчер на телефонные звонки отвечает на вопросы "где автобус?", глядя в базу. К оффису с базой - нужна стабильная связь от всеx конечныx потребителей информации. И точно так же: вылети провайдер (Инернета, телефонов, без разницы) - данные оффис поставлять перестаёт (от слова "совсем").Мальчик-Одуванчик wrote:база тоже одна.
Сабина, я честно говоря Вас - не понимаю.Сабина wrote:Вот тут линк подкинули на другом форуме любопытный как раз на тему как geolocation данные можно собирать
https://media.blackhat.com/eu-13/briefi ... ske-wp.pdf
PS•Amazon Kindle Fire (2nd generation Kindle Fire, HD, HDX)
•Apple iPhone, iPad (iOS 4 or up)
•Blackberry (classic Blackberry 4, 5, 6, 7 and Blackberry 10)
•Android phones, tablets (Android 2.3 or up)
•Windows tablets, laptops (Windows 8 RT and Windows 8 Pro)
•Windows Phone 8
Ничего из ряда вон выходящего. И уж всяко дешевле, чем сотня инстансев у гугла (а ты вроде про пицот писал)stenking wrote: Ага! Мелкий шрифт. Нука-нука
http://blog.whatsapp.com/196/1-million-is-so-2011
1. под сервером они подразумевают 24 cores, 95 GB of RAM. Один такой сервер это и есть 100-ня инстансев у гугла.
Дык я потому и говорю - "ох уж эти веб-разработчики". Привыкли жить в мире запрос-ответ-обрыв связи.stenking wrote:2. Сокеты это не веб а уровень ниже. Слушать какой-то порт и туда писать дату в своём формате. Обработчик на Erlang, никаких фраимворков - рем идёт на килобайты. Можно ещё больше ускорить и вспомнить Ассамблер. А то и VHDL - сделал себе чип и ещё быстрее работает.
да я тебя умоляю! это все собирается из опенсорсных проектов за несколько часов. опять же, если даже бы и месяц - такой расход человеческого труда окупится на затратах на хостинг буквально моментальноstenking wrote:Распределять коннекшины на разные боксы в зависимости от занятости - переизобрести load balancer. Сделать fault tolerance, мониторинг работы. Опять такие - ничего в этом мега сложного нет - но из дневной задачи ты только что сделал себе работы на месяц
и как же данные через сотовую связь попадают в базу минуя энторнэт? прям чюдиса. или мы в 2014(15?) году собираемся использовать CSD, дорогой и ненадежный?Мальчик-Одуванчик wrote:В моей схеме между поставщиком данных и базой нет лишнего звена под названием интернет.
Данные от автобуса идут либо через сотовую связь, либо через спутник и попадают в базу минуя интернет
база тоже одна.
А тот сервер делал что-то осмысленное, сравнимое с инстансами гугла?АццкоМото wrote:Ничего из ряда вон выходящего. И уж всяко дешевле, чем сотня инстансев у гугла (а ты вроде про пицот писал)stenking wrote: Ага! Мелкий шрифт. Нука-нука
http://blog.whatsapp.com/196/1-million-is-so-2011
1. под сервером они подразумевают 24 cores, 95 GB of RAM. Один такой сервер это и есть 100-ня инстансев у гугла.
А если поставить менее амбициозную цель и больше одного сервера (например 4) - можно сэкономить и на хостинге и на танцах с бубном.это все собирается из опенсорсных проектов за несколько часов. опять же, если даже бы и месяц - такой расход человеческого труда окупится на затратах на хостинг буквально моментально
ЗЫ. есть правда нюанс в твиках FreeBSD, которые пришлось делать вотсапповцам... но в нашем случае можно просто поставить менее амбициозную цель и пить коктейли пока другие трудячат
Настоящие веб-разработчики вообще в связи не вступают.АццкоМото wrote: Дык я потому и говорю - "ох уж эти веб-разработчики". Привыкли жить в мире запрос-ответ-обрыв связи.