Да, прошу прощения, но всё-таки очень хочется спросить ещё про In-Memory-Data-Grid, или In-Memory-SQL-Grid. Вы их рассматривали? В частности, например проект apache ignite предоставляет не только программный интерфейс в стиле Data Grid computing, но обещают прямо ANSI SQL-99 совместимость и стандартный JDBC доступ.
Очень интересно ваше мнение по этому поводу.
Даже наличие опциональной поддержки inmemory как отменяет использование индексов?? Причём как в памяти, так и для оставшейся на диске части? Некоторые базы, вроде Exasol, вообще делают их автоматически в памяти, как рассказывал tinkoff, большинству же остальных так или иначе они всё равно нужны от DBA.
Обученная модель в переменной model.
Если вам прислали картинку которую вы хотите классифицировать, в общем случае вам нужно привести её в тот же вид (сначала размерность и цветность 28*28 grayscale, затем в одномерный вектор, как в начале статьи). Затем, в простейшем случае вы можете просто вызвать метод predict.
Для сохранения модели, чтобы не тратить лишний раз время на тренировку, имеются различные методы записи на диск и экспорта в JSON или YAML — https://keras.io/models/about-keras-models/
Базовые индексы и механизмы у вас очень хорошо рассказаны в DBA2 курсе. А вот про «новые», Бартунов и Коротков постоянно рассказывают на конференциях, прямо как затравки. Каждый раз думаешь «вау, как круто», но так чтобы понять, а главное приспособить в реальной жизни что-то кроме Btree или Gin даже и не понятно с какой стороны смотреть толком…
3 Мб оверхеда, да ещё и выковырянных из другого проекта. Вы же, как я понял, всё равно используете maven-указаение зависимостей и его артефакты. Ivy (https://mvnrepository.com/artifact/org.apache.ivy/ivy/2.4.0) занимает всего 900Кб и готов к использованию. В том числе как зависимость проекта, в котором вы собираете единый артефакт.
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
Конечно можно. И парсить вывод. А если бинарного git нет в PATH ещё поставить его или подтянуть зависимость. А потом прикритить логику парсинга имен бранчей, потом логику формирования версий. А потом добавить логику обработки dirty рабочей копии, а потом ввести чтение переменных окружения… А потом понять что этого кода в скрипте билда стало больше чем остального описания билда и вынести это в плагин градл. Ну или взять один из имеющихся.
Это не функции Jenkins никак, если у вас проект в другом месте. В лучшем случае, может быть плагин интеграции, который сможет решить часть проблем. Но в общем gitlab не так много хуков предлагает, чтобы сделать это так же удобным как с его CI. Если вам не предоставляется возможности рядом с коммитом отобразить статус билда из другой системы (исключительно для примера, с другими возможностями также) — то вы это из плагина не сделаете.
Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.
Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
На самом деле, с Jenkins 2.0, когда они у себя также внедрили концепцию пайплайнов (pipline), разрыв значительно уменьшился. На митапе в Яндексе в прошлом году, они очень активно рассказывали как это всем поможет. Теперь не обязательно все билды «накликивать мышкой». Раньше для меня это было просто бедой, хотя и можно было экспортировать конфигурацию в XML. Теперь можно нормально версионировать скажем с помощью того же GIT.
Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…
Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.
Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
varnav, честно говоря, тут в общем всё просто, но зависит от ваших специфических нужд. На хабре уже есть неплохие стати на эту тему, например Введение в GitLab CI.
По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.
Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.
Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…
Полагаю вы не вполне поняли для чего afuse и autofs.
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
Autofs тоже хорошая штука, согласен. Я его тоже использовал.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
значительно сложнее в настройке. Работает на древнем automount
при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.
Очень интересно ваше мнение по этому поводу.
Если вам прислали картинку которую вы хотите классифицировать, в общем случае вам нужно привести её в тот же вид (сначала размерность и цветность 28*28 grayscale, затем в одномерный вектор, как в начале статьи). Затем, в простейшем случае вы можете просто вызвать метод predict.
Для сохранения модели, чтобы не тратить лишний раз время на тренировку, имеются различные методы записи на диск и экспорта в JSON или YAML — https://keras.io/models/about-keras-models/
А почему не тестировались CitusDB (в отличие от GreenPlum ставится поверх Postgres, то есть работает на свежих версиях, а не 8.4) и monetdb?
А когда ждать продолжение про RUM и VODKA?
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
Однако полагаю это всё же уже оффтопик.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…
Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.
По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.
Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.
Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов: