Так «бутылочные горлышки» можно решить 2-мя способами:
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Несколько странно слышать про то, что оперативка работает принципиально быстрее БД. Если БД на той же машине и настроена, то она так же практически не обращается к жесткому диску (в идеале только на запись). Если же чисто в оперативке хранить, то теряем в надежности данных (бд сбрасывает на жесткий диск и понятным образом делаются бекапы).
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
Соображения по Руби (если не вспоминать о JRuby) описал в комментарии ниже на странице. В целом, вполне можно собрать аналог на текущих инструментах и практиках для кластеризации. Писать нужно будет только скрипт как данные будут перетекать по нодам, но в любом случае это достаточно зависимая от проекта вещь. Понятно, что такой подход в теории технически может быть несколько менее оптимален, чем XAP (потребуется для такого же кол-ва запросов больше нод, но не учитывается стоимость лицензий и поддержки XAP), но пиковую нагрузку все равно сможет выдержать.
Судя по статье у них балансеры были. Было много серверов. Но не было мониторинга (какие сервисы начинают перегреваться и их нужно расширять). И не были готовы расширяться быстро (не было готовых современных образов для облачных систем и т.п.). Особенно не смогли бы масштабироваться, если у них покупные продукты есть на серверах.
В итоге большую часть покупателей обслужить не смогли.
Т.к. потеря 20% от года — невероятно много, начались внутренние разборки кто виноват и что делать, чтобы это НИКОГДА!!!!!111 не повторилось. XAP удачно подвернулась и была внедрена. Возможно, даже, айтишники сохранили свои рабочие места после этого.
У XAP, опять же по статье, достаточно простая идея: берем трехзвенку (БД+сервер приложений+сервер статики+кеш какой-нить), размещаем на 1ой машине, базе даем достаточно ОЗУ, чтобы все хранилось в ней, делаем образы такой машины, деплоим их по необходимости. Понятно, что именно в XAP это, скорее всего, не только на 1 машине, но еще и как-то дополнительно оптимизировано, чтобы было за что деньги брать.
У подхода (без деталей реализации) 3 проблемы на вскидку:
1) Т.к. XAP платен, то, возможно, будут задержки во времени на получение лицензий и их оплату (тысяч 10 долларов, например, быстро перевести) при необходимости увеличить в 10 раз количество серверов.
2) По самой же архитектуре мы предполагаем, что систему можем разбить на одинаковые маленькие блоки. Оставив только один какой-то суперблок для авторизации и перераспределения блоков. Такое можно сделать для всяких Бейскемпов — там один аккаунт не зависит совершенно от другого, только информация о аккаунте централизована. В интернет-магазине добавляются единая информация о складе. Ее как отдельную систему можно так же по XAP масштабировать, но тогда получаем 2 отдельных системы: уже нужно принимать решение какую из них масштабировать. Впрочем, при наличии мониторинга и готовой инфраструктуры это особой проблемой не будет. В зависимости от особенностей проекта может быть достаточно много таких отдельных XAP-систем.
3) С практической точки зрения будет важным удобство инструмента перераспределения количества нодов. Т.е. мы добавляем к 10 нодам еще 2. Нужно, чтобы данные, в транзакционном режиме (без потери изменений в последний момент на старом сервере или выдачи ошибки клиенту), перетекли на 2 новых сервера и они включились в работу. Аналогично мы отключаем 3 ноды и данные обратно должны перетекать. Возможно и не при включении перетекать, а при логине пользователя. Пользователь залогинился — данные с его учетки перетекли на этот сервер (их относительно немного).
По поводу других платформ (той же Ruby on rails). Версию для своей системы сделать довольно просто:
1) придумываете на сколько систем разбивать проект и как внутри каждой системы разбивать данные.
2) собственно разбиваете проект на подпроекты, настраиваете обычную свою БД и пишите скрипт миграции данных (тут можно было со временем выделить общие для разных проектов библиотеки, но и без этого достаточно недорого самим написать).
3) готовите отдельные образы операционных систем под каждую систему и каждый предполагаемый облачный хостинг
4) тестируете, что добавление и удаление нод работает как предполагалось; не забываете подключить мониторинг на каждый нод и нотификации в смс о перегрузках; возможно, автоматическое увеличение нод в каких-то пределах
5) далее не забываете обновлять образы (в принципе, что-то вроде capistrano вполне поможет)
Тут главное, чтобы был мониторинг и 100%-ая готовность запустить новые ноды с дроблением данных по нодам. Дальше уже можно бесконечно оптимизировать и фичерить каждый отдельный элемент схемы, чем, видимо, разработчки XAP и занимаются.
Именно из-за того, что сейчас у айтишников всё хорошо никому профсоюзы и не нужны. Найти работодателя на зп такую же или выше текущей — особой проблемы нет. Хочешь с белым оформлением — можно и таких найти. Практически повсеместно гибкие графики и прочие плюшки. Вообще не вижу смысла связываться с профсоюзами.
Тут несколько моментов:
1) Крупная организация по определению более эффективна, чем мелкая. Если вы не справляетесь по цене, то вон с рынка, это нормально. Как раз рыночная экономика на этом построена. Дополнительно, часто квалификация фрилансеров (фактически описанная вами мелкая организация) выше, чем сотрудников крупных организаций (в крупных организациях много «студентов», а фрилансеры обычно сформировавшиеся профессионалы).
2) Если ТЗ позволяет плохо выполнить работу, то это ваше плохое ТЗ, а не фрилансеры виноваты.
3) Если человек, который ходил в гос. конторы, и человек, который писал тз, — это одно и то же лицо, то в этом наверняка и проблема. «Технари» весьма редко умеют общаться с людьми, тут должны работать «аккаунт менеджеры».
Ну, а рассуждения по поводу того как должно быть весьма поверхностны, на эти темы соотв. люди могут книги написать. Пока лучше того что есть особо не придумали.
Датчик движения (включает) + датчик давления на стульчак (включает и продлевает таймер света).
А для построения умного дома перспективным кажется использование RFID-меток: так людей можно легко находить в нужных местах по идее. Да и гостям будет прикольно выдавать (чтобы свет в туалете и ванной для них включался), оценят, что в доме будущего побывали. :)
Единственно, нужно перепроверить экологичность данных методов (что отрицательно на здоровье и нервы не повлияет). Как-то настораживают моргающие светодиоды с частотой 34к.
Миллисекунды при загрузке учитывать — вот что точно бездумное программирование.
Но 5 строк на метод — сильно зависит от предметной области. Все-таки строк 20 реальней. Особого смысла уменьшать именно в 5 нет, это только усложнит читаемость кода, а это один из важнейших параметров.
1 объект в контроллере — идея понятна, в некоторых фреймворках применяется, но добавляет уровень абстрации, используемый в одной связке, и особого практического смысла не несет. Фактически получается протокол контроллер-представление, только он явный не особо и нужен. Но, опять же, зависит от проекта.
100 строк на класс и 4 аргумента — примерно нормально. Если аргументов больше, то большая вероятность, что нужно вводить новую модель данных. Исключение — собственно методы вывода, где куча параметров и там нормально.
Сейчас мне кажется лучший вариант — это по принципу инкубаторов (без их менторства и отбора): закутки (как в Казани в ИТ-Парке) или комнаты на компанию (до 6 чел) с общими переговорными, кухней, принтерами/телефонией/интернетом и секретарем. Но и масштаб сильно больше (по минимуму): 20кв.м*(5 комнат для компаний + 1 переговорная + 1 кухня/миникафе + 2 на коридоры и прочее) = 180-200 квадратов. Все-таки, если не заказная разработка на фрилансе, а продукт/услуга, то несколько человек набираются очень быстро.
Это сложная дорогая серверная программа. Саму базу знаний никто давать не будет. Судя по описанию будут ставить 1U клиентский сервер, который, по сути, будет только перенаправлять запросы «в облако».
В принципе, такое купить и у нас (в СНГ) могут. Только там входными данными являются американские мед. карты. Есть подозрение, что наши врачи не смогут заполнять вторую карту на англ. языке в американских стандартах, а потом заносить это в компьютер. И я наших врачей с iPad не представляю (при месячных зп ниже 10тр бывает).
Извините что вмешаюсь, но в чем проблема зайти на сайт производителя и посмотреть? Там же даже на русском языке. Автор же вроде бы не является евангелистом на зп или региональным представителем, чтобы отвечать на вопросы потенциальных покупателей, не связанных напрямую с его внедрением (и легко получаемые с оф. сайта)?
А вот про сами устройства… Для себя сравниваю с Z-Wave. Минусы:
1) Нигде ничего не увидел про безопасность. Значит, ее там нет с вероятностью 99%.
2) Мне не совсем понятно будут ли устройства мешать друг другу в многоквартирном доме (вспоминая радиотелефоны Panasonic).
3) Нет обратной связи, но она и не всегда нужна.
4) «При 4-х нажатиях в день на год хватает батарейки.» — так я каждые 4 месяца буду их менять примерно. Мало.
5) По фото сложно понять, но многих смущают сенсорные кнопки. Действительно ли будет удобно их в темноте искать.
6) По функционалу системы (фактически только свет) можно сделать вывод, что она пока что на поиграться (WOW-фактор). Реальный умный дом начинается с экономии (температура в помещении, свет и так люди выключают), безопасности (датчики протечки воды и газа, возможно пожара) и температурного комфорта (датчик температуры, регуляторы батарей и котла). Когда холодно или жарко свет кнопкой включать прикольно, но не первостепенно.
Плюсы:
1) дешевле в 2 раза тот функционал, что есть.
В итоге система получше того, что есть в каком-нибудь Леруа Мерлен тем, что позволяет связывать комплекты между собой и даже подключать к компьютеру для более сложных сценариев. Но реальное применение пока что весьма специфично, сам буду все-таки начинать с системы климат-контроля, затем протечек. А свет пока что по старинке, переключателем.
Ну и купите его, 220$ за программно-аппаратный комплекс — очень хорошая цена. Т.к. продукт для компаний и нишевой отдельно софт будет стоить не меньше, бесплатное что-то вряд ли есть, если только приспособить под свои нужны ПО из другой области.
Прямо примеров дешевого софта для Digital Signage не знаю, тоже было бы интересно для кругозора и каких-нибудь отдельных решений.
1) Выделить между блоками специализацию (ренжи), в том числе и отдельные физические каналы.
2) Если первого не хватит, то посадить блоки по возможности на 1 машину, чтобы выдавался только результат небольшой из такой системы.
Собственно, это сделано у них и описано у меня.
Обороты ниже — можно через издателя попробовать.
16 инстансов не проблема, если делаем шарды. Что собственно и предполагает как основное архитектурное изменение XAP. Отдельно, недавно была статья про монстров с сотнями процессоров для БД (видимо, и для подобных случаев, только их за день не купишь).
Как бы это смешно не звучало, но шарды и MySQL (или PostgreSQL) спасли бы ситуацию с большой вероятностью (если бы были до инцидента). OpenSource DB, т.к. новые ноды бесплатно и не нужно оперативно за 1 час закупать в 2 раза больше лицензий (за бешенные деньги), чем есть сейчас. Они бы и шардинг потребовали бы раньше, т.к. в некоторых случаях все же хуже работают.
Ребята из Kohl были просто не готовы отмасштабировать систему до нужного уровня. Будь, условно, у них 1 месяц на подготовку, они бы и без всякого XAP придумали бы и отработали как при необходимости поднять производительность. Либо халатность, либо не дали денег на масштабирования до инцидента.
В итоге большую часть покупателей обслужить не смогли.
Т.к. потеря 20% от года — невероятно много, начались внутренние разборки кто виноват и что делать, чтобы это НИКОГДА!!!!!111 не повторилось. XAP удачно подвернулась и была внедрена. Возможно, даже, айтишники сохранили свои рабочие места после этого.
У XAP, опять же по статье, достаточно простая идея: берем трехзвенку (БД+сервер приложений+сервер статики+кеш какой-нить), размещаем на 1ой машине, базе даем достаточно ОЗУ, чтобы все хранилось в ней, делаем образы такой машины, деплоим их по необходимости. Понятно, что именно в XAP это, скорее всего, не только на 1 машине, но еще и как-то дополнительно оптимизировано, чтобы было за что деньги брать.
У подхода (без деталей реализации) 3 проблемы на вскидку:
1) Т.к. XAP платен, то, возможно, будут задержки во времени на получение лицензий и их оплату (тысяч 10 долларов, например, быстро перевести) при необходимости увеличить в 10 раз количество серверов.
2) По самой же архитектуре мы предполагаем, что систему можем разбить на одинаковые маленькие блоки. Оставив только один какой-то суперблок для авторизации и перераспределения блоков. Такое можно сделать для всяких Бейскемпов — там один аккаунт не зависит совершенно от другого, только информация о аккаунте централизована. В интернет-магазине добавляются единая информация о складе. Ее как отдельную систему можно так же по XAP масштабировать, но тогда получаем 2 отдельных системы: уже нужно принимать решение какую из них масштабировать. Впрочем, при наличии мониторинга и готовой инфраструктуры это особой проблемой не будет. В зависимости от особенностей проекта может быть достаточно много таких отдельных XAP-систем.
3) С практической точки зрения будет важным удобство инструмента перераспределения количества нодов. Т.е. мы добавляем к 10 нодам еще 2. Нужно, чтобы данные, в транзакционном режиме (без потери изменений в последний момент на старом сервере или выдачи ошибки клиенту), перетекли на 2 новых сервера и они включились в работу. Аналогично мы отключаем 3 ноды и данные обратно должны перетекать. Возможно и не при включении перетекать, а при логине пользователя. Пользователь залогинился — данные с его учетки перетекли на этот сервер (их относительно немного).
По поводу других платформ (той же Ruby on rails). Версию для своей системы сделать довольно просто:
1) придумываете на сколько систем разбивать проект и как внутри каждой системы разбивать данные.
2) собственно разбиваете проект на подпроекты, настраиваете обычную свою БД и пишите скрипт миграции данных (тут можно было со временем выделить общие для разных проектов библиотеки, но и без этого достаточно недорого самим написать).
3) готовите отдельные образы операционных систем под каждую систему и каждый предполагаемый облачный хостинг
4) тестируете, что добавление и удаление нод работает как предполагалось; не забываете подключить мониторинг на каждый нод и нотификации в смс о перегрузках; возможно, автоматическое увеличение нод в каких-то пределах
5) далее не забываете обновлять образы (в принципе, что-то вроде capistrano вполне поможет)
Тут главное, чтобы был мониторинг и 100%-ая готовность запустить новые ноды с дроблением данных по нодам. Дальше уже можно бесконечно оптимизировать и фичерить каждый отдельный элемент схемы, чем, видимо, разработчки XAP и занимаются.
1) Крупная организация по определению более эффективна, чем мелкая. Если вы не справляетесь по цене, то вон с рынка, это нормально. Как раз рыночная экономика на этом построена. Дополнительно, часто квалификация фрилансеров (фактически описанная вами мелкая организация) выше, чем сотрудников крупных организаций (в крупных организациях много «студентов», а фрилансеры обычно сформировавшиеся профессионалы).
2) Если ТЗ позволяет плохо выполнить работу, то это ваше плохое ТЗ, а не фрилансеры виноваты.
3) Если человек, который ходил в гос. конторы, и человек, который писал тз, — это одно и то же лицо, то в этом наверняка и проблема. «Технари» весьма редко умеют общаться с людьми, тут должны работать «аккаунт менеджеры».
Ну, а рассуждения по поводу того как должно быть весьма поверхностны, на эти темы соотв. люди могут книги написать. Пока лучше того что есть особо не придумали.
А для построения умного дома перспективным кажется использование RFID-меток: так людей можно легко находить в нужных местах по идее. Да и гостям будет прикольно выдавать (чтобы свет в туалете и ванной для них включался), оценят, что в доме будущего побывали. :)
Единственно, нужно перепроверить экологичность данных методов (что отрицательно на здоровье и нервы не повлияет). Как-то настораживают моргающие светодиоды с частотой 34к.
PS. Больше всего огорчила позиция русскоязычных сотрудников, которые осознавая что делают, пытались оправдать действия компании. Ответ рабов.
Но 5 строк на метод — сильно зависит от предметной области. Все-таки строк 20 реальней. Особого смысла уменьшать именно в 5 нет, это только усложнит читаемость кода, а это один из важнейших параметров.
1 объект в контроллере — идея понятна, в некоторых фреймворках применяется, но добавляет уровень абстрации, используемый в одной связке, и особого практического смысла не несет. Фактически получается протокол контроллер-представление, только он явный не особо и нужен. Но, опять же, зависит от проекта.
100 строк на класс и 4 аргумента — примерно нормально. Если аргументов больше, то большая вероятность, что нужно вводить новую модель данных. Исключение — собственно методы вывода, где куча параметров и там нормально.
В принципе, такое купить и у нас (в СНГ) могут. Только там входными данными являются американские мед. карты. Есть подозрение, что наши врачи не смогут заполнять вторую карту на англ. языке в американских стандартах, а потом заносить это в компьютер. И я наших врачей с iPad не представляю (при месячных зп ниже 10тр бывает).
А вот про сами устройства… Для себя сравниваю с Z-Wave. Минусы:
1) Нигде ничего не увидел про безопасность. Значит, ее там нет с вероятностью 99%.
2) Мне не совсем понятно будут ли устройства мешать друг другу в многоквартирном доме (вспоминая радиотелефоны Panasonic).
3) Нет обратной связи, но она и не всегда нужна.
4) «При 4-х нажатиях в день на год хватает батарейки.» — так я каждые 4 месяца буду их менять примерно. Мало.
5) По фото сложно понять, но многих смущают сенсорные кнопки. Действительно ли будет удобно их в темноте искать.
6) По функционалу системы (фактически только свет) можно сделать вывод, что она пока что на поиграться (WOW-фактор). Реальный умный дом начинается с экономии (температура в помещении, свет и так люди выключают), безопасности (датчики протечки воды и газа, возможно пожара) и температурного комфорта (датчик температуры, регуляторы батарей и котла). Когда холодно или жарко свет кнопкой включать прикольно, но не первостепенно.
Плюсы:
1) дешевле в 2 раза тот функционал, что есть.
В итоге система получше того, что есть в каком-нибудь Леруа Мерлен тем, что позволяет связывать комплекты между собой и даже подключать к компьютеру для более сложных сценариев. Но реальное применение пока что весьма специфично, сам буду все-таки начинать с системы климат-контроля, затем протечек. А свет пока что по старинке, переключателем.
Прямо примеров дешевого софта для Digital Signage не знаю, тоже было бы интересно для кругозора и каких-нибудь отдельных решений.