Не люблю магию, github.com/jordansissel/fpm, нарисуйте скрипты чтоб билдить все что вам нужно, привяжите их к бил серверу, артефакты автоматом на репозиторий. Добавьте puppet, salt, chef, bash, docker и тд для развертывания инфраструктуры целиком.
Как то так. Это в общем одна из задач системного администратора обеспечивающего поддержку разработки.
Менеджеров пакетов под разные языки куча, бывает что сервис работает, написан например на erlang, а разработчика нет. rebar, pecl, pip, lein, gem, cabal, stack и тд. С тем же pip я последний раз сталкивался 2 года назад, с rebar 4 года назад, lein вчера, gem пару месяцев назад, cabal — неделю назад. У каждого языка своя инфраструктура, вы их все тащите на прод? В общем это дело хозяйское, но мой опыт в администрировании склоняет меня в сторону пакетирования. Это потом сильно проще, и обеспечивает заменяемость людей.
А потом вам понадобится срочно еще какая-то либа на racket, для какого-то скрипта, немножко php что в пакетах не было, и еще что-нибудь, главное чтоб у него свой менеджер пакетов был, а может и инсталлятор в виде скрипта, в хомяк аль в opt положит мину.
В документацию записать забудут сей факт, человечек который это сделал станет не доступен.
И однажды вам понадобится развернуть сервис на новом железе (и очень срочно).
Развернете вы (debian | red-hat | sled), накатите пакеты менеджером, потом pip, потом bower, в общем все по доке.
Вот только не получится каменный цветочек. А начальство шумит, пальчиком грозится. И в думу вы погрузитесь, печальную. ))
И не вспоминайте про chef, puppet, salt, это по сути один из способов документирования ваших сервисов.
А теперь добавьте туда ruby с его менеджером пакетов, nodejs, и еще пяток интерпретаторов, накатите по 10 — 15 пакетов в каждом, а потом попробуйте понять, что у вас лежит на сервере. И как его собрать заного. Все что запускается на сервере должно устанавливаться из пакетов, иначе вы получаете помойку, которая не может поддерживаться без вечно устаревающей документации и человека обладающего божественным знанием как его собрать.
Набор вариантов использования не исчерпывается графиками. Система мониторинга, нужно выбрать последние 3 значения для вычисления состояния сервиса.
Ну и по текущему состоянию.
Примеры запросов -> ответов:
curl -G 'http://fixmon:8086/query?db=fixmon&pretty=true' --data-urlencode «q=SELECT last(time) from system»
{
«results»: [
{
«error»: «unknown field or tag name in select clause: time»
}
]
}%
time есть, но его нет
curl -G 'http://fixmon:8086/query?db=fixmon&pretty=true' --data-urlencode «q=SELECT last(free) from system»
{
«results»: [
{
«series»: [
{
«name»: «system»,
«columns»: [
«time»,
«last»
],
«values»: [
[
«1970-01-01T00:00:00Z»,
1.28894459e+08
]
]
}
]
}
]
}%
Опять косяк, время выставлено на начало эпохи(в коде куча заглушек + баги)
Способов записать сырые данные и потом проанализировать масса. Вся фишка influxdb в SQL запросах, а вот это к сожалению находится весьма в плачевном состоянии. Сам проект интересен, но не более. В общем когда они реализуют тот набор SQL который они заявили, тогда можно смотреть, а сейчас это игрушка не более. Это мое сугубо личное мнение.
Большой, ну может быть.
Сложный, не уверен.
docker это по сути обвязка над набором утилит + работа с файлами (создать, удалить, изменить)
Ну да, еще хранилище образов, ну так а что в нем сложного?
Поржал, крутая статистика.
Так на заметку, в том же haskell вы считаете все скобки, а если посчитать только слова, 22 получается (haskell98 lexical structure).
Язык и правда простой, только вот многовато понтов. Давно ждал релиза одной базы на go (influxdb), зарелизили, баг на баге багом погоняет, базового функционала, который кстати был заявлен, нет. Зато 5700 звезд, 560 форков, и 125 разработчиков, и в результате за год работы пшик(только над этой версией).
Задумка хорошая, исполнение пока на двоечку, уж подумываю не самому ли написать, а то ждать поднадоело.
Если убрать весь шум: для простых утилит, язык вполне себе, для больших и сложных проектов я пока сильно сомневаюсь.
Ну и продолжение сказочки:
Появилась тема на рынке, народ покумекал и решил бабло заколачивать.
админ chemistmail побыстрому зафигачил свой сервис на haskell, взял атом в облаке, и процесс пошел.
программист zapimir тоже по быстрому зафигачил аналог на php, взял такой же атом, и тоже зарабатывает деньги.
А группа парней решила откусить кусок от пирога который делят chemistmail и zapimir, собрались они в команду,
написали свой сервис на go, с документацией, тестами и прочими плюшками.
Все хорошо, только база на один сервер не помещается, ну дело поправимое, шардинг не глупые люди придумали.
В итоге заняли они пару — тройку i7 с большими дисками, да вот не задача, стоимость запроса у них дороговатая получается, не получается у них кусок то откусить от рынка.
И где то они прокололись. Тут и сказочке конец, а кто слушал молодец.
PS: серебряная пуля не в языке, а в алгоритмах и структурах данных.
А когда на любой чих предлагается база данных, и говорится что там уже все придумали, получается тупо база данных, но ни как не сервис.
И на тему алгоритма. Решение в лоб.
Упаковка:
Чтоб быстро искать, нужно уложить данные чтоб их можно быстро читать.
У нас 10 значные числа, в Int32(Word32) влезет только 9 цифр.
Создаем 10 файлов от 0 до 9, по первой цифре определяем в каком файле паспорт будет храниться.
Оставшиеся 9 пакуем в Word32 и пишем сплошным потоком в файл. Получается каждые 4 байта паспорт.
После mmap и сортировка данных в каждом из файлов.
Для выборки:
mmap нужного файла по первой цифре, потом бинарный поиск.
Можно еще индекс сделать, будет еще быстрей, но мне и такого варианта хватило.
Если делать индекс, то делаем дерево для бинарного поиска ~ 90000 узлов на все. Это ~800к дополнительного места.
Больше делать смысла не вижу, размер блока при рандомном чтении 4к, то есть при таком размере индекса будет читаться одна страница, это 1024 паспорта.
Любая база съест места на порядок больше, хотя конечно возможны варианты. И она здесь тупо излишняя, это фиксированный кейс, один тип запроса, всегда одни и те же данные.
Посмотрел по коду:
17 строк упаковка данных в бинарный формат и сортировка.
11 строк проверка паспорта.
Велосипед даже до колеса не дотягивает. )
Я сразу сказал что если берем базу, то места на диске будет жрать много. И просьба пока не палить структуру хранения данных и алгоритм. Вариантов на самом деле там много, у меня по сути самый тупой, задачка решалась в лоб и быстро, для получения приемлемого результата(не оптимального)
Медленный, согласен, ускорить можно легко, у меня там тупо бинарный поиск по сортированному массиву, можно индекс добавить, сразу пендаль для скорости будет. Просто и такой скорости за глаза.
Тогда мне будет не интересно.
Выкатывайте любое рабочее решение на go, показываю свое и рассказываю что за алгоритмы и какие структуры данных я использовал.
bloom filter не подходит, нужна 100% гарантия точности в обе стороны.
embedded в принципе можно, размер на диске больше будет, на вскидку.
А смысл в http протоколе? тогда уж лучше redis или memcached протокол. Избыточности меньше а кода столько же. Как сервис не реализовано потому как нет необходимости, да и выигрыша не будет, процессы которые дергают короткоживущие, соединение хранить не получится. Данные с диска в оперативку постоянно не гоняются, дисковый кэш срабатывает.
Мне интересно решение в лоб человеком который постоянно пишет на go. Сама реализация, выбор алгоритмов, структуры данных которые будут использоваться.
Язык очень простой, задача тоже. Go по скорости и ресурсам здесь за глаза.
Кода здесь много быть не должно, ну пара сотен строк кода это наверно максимум.
Как то так. Это в общем одна из задач системного администратора обеспечивающего поддержку разработки.
Менеджеров пакетов под разные языки куча, бывает что сервис работает, написан например на erlang, а разработчика нет. rebar, pecl, pip, lein, gem, cabal, stack и тд. С тем же pip я последний раз сталкивался 2 года назад, с rebar 4 года назад, lein вчера, gem пару месяцев назад, cabal — неделю назад. У каждого языка своя инфраструктура, вы их все тащите на прод? В общем это дело хозяйское, но мой опыт в администрировании склоняет меня в сторону пакетирования. Это потом сильно проще, и обеспечивает заменяемость людей.
В документацию записать забудут сей факт, человечек который это сделал станет не доступен.
И однажды вам понадобится развернуть сервис на новом железе (и очень срочно).
Развернете вы (debian | red-hat | sled), накатите пакеты менеджером, потом pip, потом bower, в общем все по доке.
Вот только не получится каменный цветочек. А начальство шумит, пальчиком грозится. И в думу вы погрузитесь, печальную. ))
И не вспоминайте про chef, puppet, salt, это по сути один из способов документирования ваших сервисов.
opentsdb.net/docs/build/html/user_guide/query/examples.html
Но это не так наглядно и удобно как SQL + сложнее в установке и требования к окружению совсем другие.
www.anchor.com.au/blog/2014/06/vaultaire-ceph-based-immutable-tsdb
Это другой вариант от австралийцев.
А если объемы небольшие, то можно писать в текст и гонять по нему sql запросы
keithsheppard.name/txt-sushi
+ Есть еще postgres с его hstore + их последние фишки в www.postgresql.org/about/news/1596
и прочее.
Ну и по текущему состоянию.
Примеры запросов -> ответов:
curl -G 'http://fixmon:8086/query?db=fixmon&pretty=true' --data-urlencode «q=SELECT last(time) from system»
{
«results»: [
{
«error»: «unknown field or tag name in select clause: time»
}
]
}%
time есть, но его нет
curl -G 'http://fixmon:8086/query?db=fixmon&pretty=true' --data-urlencode «q=SELECT last(free) from system»
{
«results»: [
{
«series»: [
{
«name»: «system»,
«columns»: [
«time»,
«last»
],
«values»: [
[
«1970-01-01T00:00:00Z»,
1.28894459e+08
]
]
}
]
}
]
}%
Опять косяк, время выставлено на начало эпохи(в коде куча заглушек + баги)
Таких примеров на самом деле очень много.
Пока можно ничего про это не писать.
{s: `SELECT field1 FROM myseries ORDER BY DESC`, err: `only ORDER BY ASC supported at this time`}
выдержка из тестов.
Сложный, не уверен.
docker это по сути обвязка над набором утилит + работа с файлами (создать, удалить, изменить)
Ну да, еще хранилище образов, ну так а что в нем сложного?
Так на заметку, в том же haskell вы считаете все скобки, а если посчитать только слова, 22 получается (haskell98 lexical structure).
Язык и правда простой, только вот многовато понтов. Давно ждал релиза одной базы на go (influxdb), зарелизили, баг на баге багом погоняет, базового функционала, который кстати был заявлен, нет. Зато 5700 звезд, 560 форков, и 125 разработчиков, и в результате за год работы пшик(только над этой версией).
Задумка хорошая, исполнение пока на двоечку, уж подумываю не самому ли написать, а то ждать поднадоело.
Если убрать весь шум: для простых утилит, язык вполне себе, для больших и сложных проектов я пока сильно сомневаюсь.
Появилась тема на рынке, народ покумекал и решил бабло заколачивать.
админ chemistmail побыстрому зафигачил свой сервис на haskell, взял атом в облаке, и процесс пошел.
программист zapimir тоже по быстрому зафигачил аналог на php, взял такой же атом, и тоже зарабатывает деньги.
А группа парней решила откусить кусок от пирога который делят chemistmail и zapimir, собрались они в команду,
написали свой сервис на go, с документацией, тестами и прочими плюшками.
Все хорошо, только база на один сервер не помещается, ну дело поправимое, шардинг не глупые люди придумали.
В итоге заняли они пару — тройку i7 с большими дисками, да вот не задача, стоимость запроса у них дороговатая получается, не получается у них кусок то откусить от рынка.
И где то они прокололись. Тут и сказочке конец, а кто слушал молодец.
PS: серебряная пуля не в языке, а в алгоритмах и структурах данных.
А когда на любой чих предлагается база данных, и говорится что там уже все придумали, получается тупо база данных, но ни как не сервис.
И на тему алгоритма. Решение в лоб.
Упаковка:
Чтоб быстро искать, нужно уложить данные чтоб их можно быстро читать.
У нас 10 значные числа, в Int32(Word32) влезет только 9 цифр.
Создаем 10 файлов от 0 до 9, по первой цифре определяем в каком файле паспорт будет храниться.
Оставшиеся 9 пакуем в Word32 и пишем сплошным потоком в файл. Получается каждые 4 байта паспорт.
После mmap и сортировка данных в каждом из файлов.
Для выборки:
mmap нужного файла по первой цифре, потом бинарный поиск.
Можно еще индекс сделать, будет еще быстрей, но мне и такого варианта хватило.
Если делать индекс, то делаем дерево для бинарного поиска ~ 90000 узлов на все. Это ~800к дополнительного места.
Больше делать смысла не вижу, размер блока при рандомном чтении 4к, то есть при таком размере индекса будет читаться одна страница, это 1024 паспорта.
Ну как то так.
zapimir: теперь можно и ваш вариант объяснить.
Посмотрел по коду:
17 строк упаковка данных в бинарный формат и сортировка.
11 строк проверка паспорта.
Велосипед даже до колеса не дотягивает. )
Выкатывайте любое рабочее решение на go, показываю свое и рассказываю что за алгоритмы и какие структуры данных я использовал.
embedded в принципе можно, размер на диске больше будет, на вскидку.
А смысл в http протоколе? тогда уж лучше redis или memcached протокол. Избыточности меньше а кода столько же. Как сервис не реализовано потому как нет необходимости, да и выигрыша не будет, процессы которые дергают короткоживущие, соединение хранить не получится. Данные с диска в оперативку постоянно не гоняются, дисковый кэш срабатывает.
Мне интересно решение в лоб человеком который постоянно пишет на go. Сама реализация, выбор алгоритмов, структуры данных которые будут использоваться.
Язык очень простой, задача тоже. Go по скорости и ресурсам здесь за глаза.
Кода здесь много быть не должно, ну пара сотен строк кода это наверно максимум.