Ладно, если речь пошла про расширение структуры и алгоритмы работы с учетом большого количества серверов, обслуживающих базу данных:
Тут тоже есть варианты, вытекают из тех же вариантов.
0. Самая простая реализация размазывания базы счетов и транзакций по нодам — это привязать транзакции одного счета к своей ноде, тогда все алгоритмы становятся точно такими же как и в односерверной реализации, просто балансер, выбирающий нужную ноду должен по счету однозначно выбирать ноду за O(1), обычно это тупой хеш. Метд идеален, когда количество транзакций на счете значительно меньше количества счетов, иначе прирост в скорости за сет расширения количества нод будет не линейным.
1. Если же количество транзакций велико… Есть два вида задач, в одних, когда нужно ускорить получение остатка на счете и когда нужно быстро обрабатывать транзакции (у транзакции тоже есть моменты, транзакция создается отдельно от своего исполнения, и если есть возможность не проверять величину остатка на счете во время исполнения, например не превышает ли объем транзакции лимита на счете, то это тоже имеет смысл), и конечно ничто не мешает реализовать оба механизма:
a) ускорение исполнения транзакции: каждая нода хранит часть транзакций, т.е. один счет может быть размазан по нодам, на каждой ноде хранится информация о итоговой сумме транзакций в этой ноде, т.е. для получения остатка нужно обратиться ко всем нодам запросом.
Плюсы:
* при создании/исполнении транзакции трудоемкость O(1), затрагивается только одна нода (на самом деле тут влияет от алгоритма выбора ноды, но в общем это так)
Минусы:
* запрос на итоговое значение на счете затрагивает сразу все ноды, с трудоемкостью O(m), где m — количество нод (если конечно алгоритм выбора нод не позволит определить ее до запроса)
* при создании/исполнении транзакции необходимо пересчитывать и следить за итоговой суммой на ноде (кстати не вижу особых проблем, понятие тригеры и атомарные операции в виде транзакций хранилища есть у даже самых отсталых БД), а значит пока идет запрос к нодам, необходимо либо блокировать глобально операции по транзакциям соответствующего счета (это и есть глобальный лок на счет), либо делать как то поправку на текущие исполняемые транзакции с этим счетом на других нодах.
b) ускорение получения итоговой суммы на счете:
Решение вообще то самое простое — где то хранить и обновлять информацию о состоянии счета, не размазывая ее по нодам, т.е. для одного счета задействовать не больше одной ноды, то есть на каждой ноде дополнительная коллекция счет->итог. Для каждой транзакции в этом случае придется затрагивать от одной до двух нод (одна нода — это если итоговая информация о счете хранится на той же ноде, куда попала транзакция), но благодаря этому трудоемкость транзакции остается O(1), и при этом трудоемкость получения итога так же O(1) — затрагивает одну ноду.
2. Стоит напомнить, что хранение истории/архива транзакций и исполнение транзакций — это разные задачи, и использовать одни и те же структуры данных для них как минимум глупо. Почти наверняка требования при работе с архивом/историей отличаются от требований по работе с текущими/исполняемыми транзакциями (время исполнения транзакции — время необходимое чтобы информация о ней расползлась по нодам, даже если их всего две, а это время не только записи, но и ожидания, когда выполнится предыдущая). Отсюда напрашивается простое решение — для поддержания архива транзакций использовать алгоритм 0, а для текущих транзакций — 1.
Ничто не мешает сделать модуль работы с веб-сайтом на mono, а основную логику закодить на php, общение навести через ajax-http-запросы к localhost.
Вот скажите мне пожалуйста, какое именно из требований ограничивает в выборе языка? Мне на ум приходит только жесткие требования по оперативке, но известные мне удобные средства анализа html-dom на php кушают память так что дополнительный демон-прослойка на mono не будет заметен.
Без учета 'какой то программы' все описанное ложится на один день спокойной работы, бонус к скорости тут то, что приложения уже есть и работают, т.е. вопрос в установке и переносу настроек… какие недели, откуда?
p.s. привожу пример почти универсальной миграции на другой физический сервер старого за 1-2 часа (и то, это в основном проблемы с драйверами при смене платформы ну и +физическое копирование данных, если там сотни гигабайт то подольше получится) — это использование виртуальной машины.
>> PS прямо сейчас как раз мучаюсь с ней — у неё неподписанный драйвер ставиться — а на 64-битную семерку так просто такой не поставишь…
Уже НЕ НАДО запускать windows 7 x64 в тестовом режиме, буквально пару месяцев назад выпустили обновление (я связывался по этому поводу с их службой поддержки, тешу надеждой что сертификат они сделали после моего обращения)
p.s. форум у них заброшен давно и заспамлен, очень жаль. проект замечательный. У меня используется версия на 2 рабочих места и именно как игровая платформа (2 видеокарты, 16Gb оперативки,..). Положительные впечатления (хотя, к примеру Aion от Инновы, а скорее всего защитная система Frost, тормозит компьютер в самые непонятные моменты… и к диску не обращается, и видео независимое… но это последний год, раньше спокойно работали параллельно и 3D-шутеры, и стратегия типа Diablo III...)
Было бы замечательно, собрать емкое хранилище на основе карт памяти (десяток карт по 64гб или 20-цать на 32гб), но возникает вопрос, где взять компактный ридер на десять/двадцать слотов.
Когда то решил это проблему похоже… на странице, где была кнопка для перехода к форме создания записи, вместо перехода к самой форме был переход к промежуточной странице, которая создавала пустую запись с дефолтными значениями и открывала ее на редактирование… только нужно заранее проектировать базу данных на существование таких недоделанных записей (иногда соответствующий статус помогает).
Будет еще хуже — будет форма, с дырками, которые получились из-за отломившегося материала, отломившийся, потому что от старости, грязи и слежавшести… видел 'солдатиков' в такой форме в одном поезде (ехали с обычными пассажирами, человек 20), осознайте уровень обветшалости, если в этом их отправили 'на люди'.
О реальной работе программиста могут думать считанные доли процента тех кто попадет туда 'по специальности'.
upd. постоянно ведите диалог с подрядчиком. Никакой тишины. Специально выделенные специалисты от вашей организации должны на ряду со специально выделенными людьми от подрядчика (а они будут, те кто будет изучать ваш современный бизнеспроцесс и старую базу) должны постоянно организовывать встречи (еженедельно, ежемесячно, по мере поступления проблем), на которых должны обсуждаться текущие результаты, задачи и проблемы.
Этот момент наверное даже важнее всех других, любая тишина сейчас — это проблемы потом.
Тогда у меня для вас плохие новости :(
Что бы вы не делали, сколько бы сил не потратили, 'как надо' не получится… сам не однократно вплетался в эту лямку… результат был одинаковый.
Первый маркер распила — требование подрядчика. Что бы вам не говорило начальство, у госконторы есть резервы и деньги и ставки, просто именно они уже давно распределены по дочерам и внукерам (доч/сын начальника, внук заместителя начальника и т.п.).
Советы по тз:
1. Настаивайте в ТЗ на поэтапную разработку и сдачу проекта… никаких 'через год дадим готовый проект', Должны быть прописаны ряд конкретных сроков, по которым должен быть конкретный результат, например поквартально или даже помесячно.
2. На середине срока у вас, хотя бы и на площадке заказчика, должен быть готовый работающий проект (альфа версия), на котором должны быть уже загружены все необходимые данные для работы пользователей, и в ТЗ должно быть прописан тест на примере хотя бы одного подразделения (или как еще позволяет разделить работу задача)
3. Вторая половина срока должна быть потрачена:
* на тестирование и выявление ошибок, из-за неточного ТЗ
(а ТЗ будет неточным, это реальность, так как правильное ТЗ это больше половины дела… а ведь вам 500к не заплатят, а подрядчик не достаточно знаком с вашей организацией чтобы сделать правильное ТЗ), неточного понимания задачи и т.п… возможность исправить ошибки на этом этапе должны быть прописаны в договоре с подрядчиком.
* на конвертацию данных из старой базы в новую
Об этом вечно все забывают, иногда задача может быть не легче разработки всей системы, так как может потребоваться разработка специального функционала или даже рабочих мест операторов, обслуживающих этот перенос, для случаев когда полный автомат невозможен (а это почти гарантированно будет так, одно сведение справочников старой базы к новым реалиям чего стоит).
* на установку и настройку оборудования уже на стороне заказчика
* на обучение персонала и учителей персонала
* на выявление проблем в документации
p.s. если у вас не будет этих пунктов, вы получите проект, сделанный фрилансером за пару месяцев перед окончанием срока за 1-3% от первоначальной стоимости проекта, без документации, без грамотно организованных бизнеспроцессов, при этом для начальства будет красивый дизайн, много много кнопочек и пунктиков (чтобы принимающие не сразу въехали) и тонной проблем, выползающих во время реальной эксплуатации, за исправление которых вашей организации придется обратиться к подрядчику и за нехилые бабки.
не, не, не… посмотрите слева… один fetchurl = один вызов задачи… тысячи запросов справа это просто сумма всех операций datastore слева.
Больше всего меня интересует даже не почему на один вызов примитивной задачи (позже выложу пример и напишу статью) делается 19 запросов на чтение и 2 запроса на запись… а почему при такой не высокой интенсивности (один запрос за 70 секунд, точнее 60+20*rand) за три часа приложение выжрало 50т. запросов по биллингу… как не считай это расхождение с прогнозом на порядок, т.е. должно было быть ~3т.
Если это так, то у меня для GAE плохие новости,… у них криворукие программисты :)
Но проблема в том, что штатный механизм контроля за количеством запросов не показывает такой запредельной нагрузки, а соотношение запросов на чтение к запускам задачи не изменяется по мере заполнения базы (список элементов не уменьшается… если бы каждый раз читался весь список, то нагрузка росла бы экспоненциально… а у меня при перезапуске (при сбросе статистики), отношение количества запросов остается таким же.
Да не сильно тайна… я пока его упрощаю поэтапно, хочу разобраться, где же собака порылась. Чуть чуть позже выложу пример, если не разберусь, да и если разберусь, выложу.
Просто позже я уже работал с GAE и там обычно все упиралось в записи, но никак не чтение…
Штатно, только через API, при его отсутствии реверсинженеринг протокола не выход.
p.s. Google публично не предоставляет протокола для авторизации приложений не через веб, даже его собственные приложения на дексктопах открывают во встроенном окне минибраузера окно авторизации. Для мобильных платформ протокол авторизации закрыт.
А зачем могут понадобиться файлы QR-кодов такого высокого разрешения? Сомневаюсь что обычный мобильник со своей куцей камерой способен распознать такой сложный код (если на точку будут выделены к примеру 1x1 или 2x2 пиксела при разрешении выше 1000px).
Тут тоже есть варианты, вытекают из тех же вариантов.
0. Самая простая реализация размазывания базы счетов и транзакций по нодам — это привязать транзакции одного счета к своей ноде, тогда все алгоритмы становятся точно такими же как и в односерверной реализации, просто балансер, выбирающий нужную ноду должен по счету однозначно выбирать ноду за O(1), обычно это тупой хеш. Метд идеален, когда количество транзакций на счете значительно меньше количества счетов, иначе прирост в скорости за сет расширения количества нод будет не линейным.
1. Если же количество транзакций велико… Есть два вида задач, в одних, когда нужно ускорить получение остатка на счете и когда нужно быстро обрабатывать транзакции (у транзакции тоже есть моменты, транзакция создается отдельно от своего исполнения, и если есть возможность не проверять величину остатка на счете во время исполнения, например не превышает ли объем транзакции лимита на счете, то это тоже имеет смысл), и конечно ничто не мешает реализовать оба механизма:
a) ускорение исполнения транзакции: каждая нода хранит часть транзакций, т.е. один счет может быть размазан по нодам, на каждой ноде хранится информация о итоговой сумме транзакций в этой ноде, т.е. для получения остатка нужно обратиться ко всем нодам запросом.
Плюсы:
* при создании/исполнении транзакции трудоемкость O(1), затрагивается только одна нода (на самом деле тут влияет от алгоритма выбора ноды, но в общем это так)
Минусы:
* запрос на итоговое значение на счете затрагивает сразу все ноды, с трудоемкостью O(m), где m — количество нод (если конечно алгоритм выбора нод не позволит определить ее до запроса)
* при создании/исполнении транзакции необходимо пересчитывать и следить за итоговой суммой на ноде (кстати не вижу особых проблем, понятие тригеры и атомарные операции в виде транзакций хранилища есть у даже самых отсталых БД), а значит пока идет запрос к нодам, необходимо либо блокировать глобально операции по транзакциям соответствующего счета (это и есть глобальный лок на счет), либо делать как то поправку на текущие исполняемые транзакции с этим счетом на других нодах.
b) ускорение получения итоговой суммы на счете:
Решение вообще то самое простое — где то хранить и обновлять информацию о состоянии счета, не размазывая ее по нодам, т.е. для одного счета задействовать не больше одной ноды, то есть на каждой ноде дополнительная коллекция счет->итог. Для каждой транзакции в этом случае придется затрагивать от одной до двух нод (одна нода — это если итоговая информация о счете хранится на той же ноде, куда попала транзакция), но благодаря этому трудоемкость транзакции остается O(1), и при этом трудоемкость получения итога так же O(1) — затрагивает одну ноду.
2. Стоит напомнить, что хранение истории/архива транзакций и исполнение транзакций — это разные задачи, и использовать одни и те же структуры данных для них как минимум глупо. Почти наверняка требования при работе с архивом/историей отличаются от требований по работе с текущими/исполняемыми транзакциями (время исполнения транзакции — время необходимое чтобы информация о ней расползлась по нодам, даже если их всего две, а это время не только записи, но и ожидания, когда выполнится предыдущая). Отсюда напрашивается простое решение — для поддержания архива транзакций использовать алгоритм 0, а для текущих транзакций — 1.