Ну что, приступим
Разговоры это хорошо, но нужна уже сегодня практическая реализация распределенной системы планирования нового поколения.
В связи с чем создал проект:
https://github.com/vkorehov/PlanEconomy2
Для начала нужно определить архитектуру и потом можно переходить к реализации.
первый набросок:
1) Представить данные о планировании не в виде матрицы а в виде графа зависимостей (ациклического)
2) Различные плоскости планирования (например одна плоскость может согласовывать скорости производства, другая текущие количества к производству, еще одна запасы на каждом этапе производства)
3) Система должна состоять из распределенного ядра (написанного на языке C) и минимальной функциональности обхода и манипулирования данными графа (с гарантированной целостностью).
И также клиентских программ, которые будут прорабатывать различные варианты планов, оптимизацию и т.д.
Своего рода граф это база данных а программы это клиенты этой базы.
4) Защита ядра должна обеспечиваться шифрованием (по модели скайпа), ни один пользователь не может повлиять на правильности расчетов системы.
5) Интерфейс с ядром на основе минимальной реализации HTTP и интерфейса графа в стиле RESTfull API.
Архитектура ядра:
1) Реализация распределенных транзакций. Snapshot Isolation и принцип copy-on-write при манипулировании данными через REST API. Транзакции определяются сессией HTTP. Если нет сессии то доступ без транзакции REad-only.
2) Во время транзакции, репликация (повторение транзакции) минимум на 3 нодах. и 2-х фазовый коммит.
3) Partitioning и репликация данных между нодами (модель 2+2) репликации как во время транзакций так и периодические для подтверждения целостности, Система голосования(между 3-мя нодами) в случае повреждений целостности.
4) Базовые операции над данными должны быть не деструктивными. Например прибавление и вычитание показателя на число, но никак не присвоение нового значения. Такая архитектура позволит избежать конфликтов данных. Данные всегда можно интегрировать.
5) Транзитивные зависимости должны вычисляться автоматически при изменении показателя в данной транзакции. Т.е. изменили число яичниц и должен быть проход по графу до изменения числа яиц и т.д.
На практике возможен Threshold до которого нужно проходить, и соответственно коэффициент "нахлеста", сколько пере производить для для каждого нода.
Проект открытый, предложения приветствуются.
В связи с чем создал проект:
https://github.com/vkorehov/PlanEconomy2
Для начала нужно определить архитектуру и потом можно переходить к реализации.
первый набросок:
1) Представить данные о планировании не в виде матрицы а в виде графа зависимостей (ациклического)
2) Различные плоскости планирования (например одна плоскость может согласовывать скорости производства, другая текущие количества к производству, еще одна запасы на каждом этапе производства)
3) Система должна состоять из распределенного ядра (написанного на языке C) и минимальной функциональности обхода и манипулирования данными графа (с гарантированной целостностью).
И также клиентских программ, которые будут прорабатывать различные варианты планов, оптимизацию и т.д.
Своего рода граф это база данных а программы это клиенты этой базы.
4) Защита ядра должна обеспечиваться шифрованием (по модели скайпа), ни один пользователь не может повлиять на правильности расчетов системы.
5) Интерфейс с ядром на основе минимальной реализации HTTP и интерфейса графа в стиле RESTfull API.
Архитектура ядра:
1) Реализация распределенных транзакций. Snapshot Isolation и принцип copy-on-write при манипулировании данными через REST API. Транзакции определяются сессией HTTP. Если нет сессии то доступ без транзакции REad-only.
2) Во время транзакции, репликация (повторение транзакции) минимум на 3 нодах. и 2-х фазовый коммит.
3) Partitioning и репликация данных между нодами (модель 2+2) репликации как во время транзакций так и периодические для подтверждения целостности, Система голосования(между 3-мя нодами) в случае повреждений целостности.
4) Базовые операции над данными должны быть не деструктивными. Например прибавление и вычитание показателя на число, но никак не присвоение нового значения. Такая архитектура позволит избежать конфликтов данных. Данные всегда можно интегрировать.
5) Транзитивные зависимости должны вычисляться автоматически при изменении показателя в данной транзакции. Т.е. изменили число яичниц и должен быть проход по графу до изменения числа яиц и т.д.
На практике возможен Threshold до которого нужно проходить, и соответственно коэффициент "нахлеста", сколько пере производить для для каждого нода.
Проект открытый, предложения приветствуются.