esobchenko / probix Goto Github PK

В модуле probix_probe.erl еще нет функций, реализующих выборку проб по дате и по дате в диапазоне от=timestamp и до=timestamp. Нужно реализовать эти функции, поскольку они подразумеваются probix http api.

исследовать возможность реализации интерфейса в парадигме comet; создать прототип интерфейса.

нужна опция, задающая тип таблиц для probix сервера при запуске.
переменная окружения PROBIX_TABLE_TYPE. значение по умолчанию: disc_copies.

скрипт, замеряющий текущий cpu load в процентах и регулярно отсылающий измерения в probix

вместо сообщений типа "Are you okay?" нужно сформулировать аккуратные и внятные сообщения об ошибках, чтобы в контексте они воспринимались нормально. Желательно в нижнем регистре.

для безопасной адресации объектов в системе (в будущем, надеюсь, многопользовательской) нужно сделать идентификаторы объектов уникальными и случайными строками.
Даже в тиметрике они представляют собой уникальные строки (e.g.: dQq_dbUOTZmCq6bbNCCMJA)

Предлагаю пока следующее решение:
unique_id() ->
<<I:160/integer>> = crypto:sha(term_to_binary({make_ref(), now()})),
erlang:integer_to_list(I, 16).

Генерирует уникальную строку. E.g.: 82E045A48F93D4E55DACDFA6E157CC42B40A1F64

отключить возвращение добавленных проб; добавить ?return uri-ключ для отладки.

Реализовать интерфейс в соответствии спецификации README ветки beatles.

поскольку функции представления объектов и проб в модулях уже подразумевают возможность использования разных форматов -- нужно придумать как эти форматы можно будет переключать чтобы получать данные в xml или yaml в дальнейшем. Ядро знать в каком формате поступают данные и в каком формате отдавать их пользователю. Очевидно, json по умолчанию. Есть идеи?

нужно аккуратно реимплементировать инициализацию базы данных. текущий вариант с
try/catch выглядит грубо. очевидно нужна функция вроде следующей:

table_exists(TableName) ->
    Tables = mnesia:system_info(tables),
    lists:member(TableName,Tables).

Пожалуй также нужно вынести создание таблиц в отдельную функцию и т.п.

конечно create_for_object нужно сделать обычным create для probe по тому что object_id это требуемый по умолчанию параметр. Нужно также осуществлять атомарную проверку на foreign key, то бишь на наличие объекта с переданным id. Ненужные create/1 функции можно удалить нафиг.

при попытке доступа к http://localhost:8000/foo/bar.baz возникает эксцепшн.

Нужно реализовать http-интерфейс для управления пробами в соотвтетсие интерфейсу из README

1. нужно добавить возможность конфигурации базовых директорий через переменные окружения как в RabbitMQ: http://www.rabbitmq.com/install.html
2. дефолтивные значения портов сервера нужно объявить как макро в include/probix.hrl

В эксперементальной ветке beatles есть файл probix_formats.erl. нужно реализовать функцию преобразования даты формата iso 8601 в григорианские секунды. Примеры преобразования времени из строк можно посмотреть в файле httpd_util.erl : http://friendpaste.com/3HOvEiE0bYBSOfkVdentmZ

нужно реализовать функцию запуска probix_db на нодах-репликах.
функция будет искать схемы при помощи schemafinder или подключаться к явно указанному хосту и реплицировать содержимое. Проблема легко разрешима и хорошо описана для систем с постоянным набором таблиц: http://erlanganswers.com/web/mcedemo/mnesia/DistributedHelloWorld.html В нашем случае для каждого объекта создается отдельная таблица для проб, которая может быть создана в момент когда одна или несколько других реплик отключены, поэтому задача усложняется.

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

поскольку подсистема диспатчинга реквестов была жестко реформатирована и содержание некоторых аргументов handle() изменилось и по сути и по форме поле request в ошибках теперь содержит несуразную информацию. Например:

~/devel/probix $ curl http://localhost:8000
{"request":"","error":"unknown request"}
~/devel/probix $ curl http://localhost:8000/foo/bar/baz/1
{"request":"foobarbaz1","error":"unknown request"}

я думаю, что нужно переосмыслить формат ошибок и обновить probix_error.erl.

Необходимо реализовать обработку запросов таким образом, чтобы наличие / не влияло на обработку.

К примеру я думаю о том чтобы сделать handle('GET',Request,_) -> в котором разбирать Request и вызывать какие-нибудь соответствующие handle_get методы

вынести управление сериями данных в отдельных gen_server и подключить его к probix_sup

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

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

текущая реализаця handle('PUT', "/object/" + Id ....) мне не нравтся.
и реализация handle('DELETE', "/object/" ++ Id_string, _) мне не нравится тоже.
Во-первых потому, что блок try, который выполняет проверку на существования объекта с заданным Id у них реализован по-разному, а похожие вещи нужно реализовывать одинаково , как известно. Но проблема не в этом. Проблема в том, что проверки на наличие объекта и его обновление/удаление выполняется двумя разными и операциями и, соответствтенно -- не атомарны. Нужно зарефакторить функции update и delete таким образом чтобы они выполняли провкрку на наличие объекта и манипуляции с ним в одной транзакции. Если объект не существует -- функции должны райзить not_found.

очевидно, что нужно рендерить график только для определенного кол-ва значений за период во имя избежания перегрузок, поэтому нужно добавить парметр, который будет ограничивать размер окна для выборки и возвращать только N аггрегированных значений для указанного промежутка.
e.g.:
запрос
curl -i -X GET http://localhost:8000/series/wv1E2FawQp?from=1254136036&window=100
должен вернуть не больше 100 тиков для указанного промежутка времени. при этом эти 100 тиков -- это должны быть агрегированные данные для всего указанного промежутка.

Исключение возникает при доступе к http://localhost:8000/objects сразу после компиляции и запуска (без запуска тестов). Все происходит кошерно, если перед запуском start.sh запустить acceptance.sh.

сейчас сервер может быть запущен в нескольких режимах: 3 режима создания бд (ram_copies, disc_copies & disc_only_copies) и также в режиме реплики на другом хосте.
Необходим аккуратный shell-скрипт или erlang-script для запуска системы в этих режимах. Под аккуратностью я имею ввиду: изящность имплементации, удобство использования и максимальную кросс-платформенность по возможности.

Нужно сделать аутентификацию агентов каким-то образом, чтобы кто попало не мог слать данные об измерениях, а только авторизованные агенты.

нужно добавить тест для фикса #21. забуду.

Очевидно нужно реализовать систему логгирования. Я полагаю она должна быть реализована в виде отдельного процесса.

Вне зависимости от того что является ошибкой - не well-formed json или неправильная структура данных в json - необходим единый exception и соответственно ошибка для пользователя.

Предусмотреть наличие различных форматов ввода-вывода.

пока я буду заниматься фиксами многочисленных нововыявленных проблем в существующем коде было бы здорово чтобы ты выполнил кое-какой ресерч в отношении следующих задач:

1. аутентификация агентов
   нужно сделать аутентификацию агентов каким-то образом, чтобы кто попало не мог слать данные об измерениях, а только авторизованные агенты.
2. журналирование (log)
   необходимость очевидна. журналирование должно вестись на уровне probix_http.erl
3. параллелизация запросов map-reduce
   я не вкурил сналету как используется map-reduce в couchdb, но для выборки большого массива данных это, вероятно, эффективно и было бы интересно попрактиковать.

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

Информацию по первым двум пунктам можно подчерпнуть, ознакомившись с исходным кодом webmachine: http://bitbucket.org/justin/webmachine

По поводу mapreduce запросов нужно обратиться к документации couchdb.

Приветствуются любые интересные идеи/мысли. Главные требования: минимализм, ясность, простота.

текущая реализация с использованием junction table имеет ряд недостатков:
-- probes_by_object_id/* выполняет join (снижается прозводительность);
-- все пробы в одной таблице быстро упруться в 4GB limit.

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

Размер передаваемых агентом данных должен указываться в content-lenght заголовке наличие которого обязательно и должно соответствующим образом проверяться.

Реализовать поддержку mongodb при помощи реафкторинга probix_db

система выдает ошибку при обращению к корню со слешом или без в запросе:

crasher:
initial call: mochiweb_socket_server:acceptor_loop/1
pid: <0.109.0>
registered_name: []
exception error: no match of right hand side value []
in function probix_http:dispatch_requests/1
in call from mochiweb_http:headers/5
ancestors: [probix_http,probix_sup,<0.98.0>]
messages: []
links: [<0.103.0>,#Port<0.2408>]
dictionary: [{mochiweb_request_path,"/"}]
trap_exit: false
status: running
heap_size: 610
stack_size: 24
reductions: 597
neighbours:

{mochiweb_socket_server,235,{child_error,{badmatch,[]}}}

методы PUT/POST рекоммендуют использовать с учетом идемпотентности выполняемых ими операций.
See:
http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/
http://horicky.blogspot.com/2009/05/restful-design-patterns.html

Не все важные исключения обрабатываются в функиях handle/3. Например, клиент не получит сообщения о том что object not found если попытается обновить несуществующий объект. Нужно еще раз пройтись по всем функциям и добавить обработчики для нужных исключений.

Наверняка можно будет удобно использовать map/reduce при агрегировании и анализе больших массивов данных.
Исследовать возможности такого использования алгоритма

Нужно реализовать страницу, которая будет отображать список существующих объектов и рисовать простой график (например scale из http://vis.stanford.edu/protovis/ex/) для проб данного объекта по клику. Это должна быть статичная html страница , которая взаимодействует с сервером probix через REST интерфейс, используя jquery или удобный аналог. Выбор библиотеки для рисования графиков и REST клиент должен быть взвешеным.

при попытке запросить пробы с диапазоном, который не преобразуется в integer возникает exception. e.g.: curl http://localhost:8000/object/1/probes?from="foo"

{bad_input, "some probes have wrong object_id"} райзится при попытке добавить пробу без указания id_object.

поскольку форматов представления данных , вероятно, будет множество (xml, yaml, whatever) -- имеет смысл упростить интерфейс соответствующих core api.

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