Я не настоящий админ, я bash на стройке нашел, но когда попробовал поставить MS SQL Server 2016 Developer Edition из Express Installer в настоящем корп. окружении — он просто не смог скачать основной ISO. Без всякой диагностики. Пришлось руками искать на сайте микрософт (где 2014, 2016 и другие версии перемешаны неясным порядком) и скачивать 2GB образы.
Еще из приятного — ставите галку установить R Server — на этапе установке инсталлер запросится в интернет. Надо откатываться назад до этапа конфигурации убирать галку и снова с песней.
После этого говорить о том, что это делается для корп окружения (которое с самого начала кремния сидело за прокси), наверное рановато.
> Нет, требуют идентичные адреса. Абсурдно, нельзя рядом в той же сети поставить такой же кластер.
Наверное, вы имеете ввиду, что вертика требует идентичные адреса для interconnect/control. На мой взгляд, это мелкое неудобство, поскольку public может быть любым, а interconnect/control все равно должен быть от public отделен ( да и пошире ему сеть нужна 10Gb). Мы у себя разруливаем это через VLAN-ы.
Мне кажется, что дело не только в количестве разработчиков, а в соотношении количества незакрытых запросов на человека за итерацию. Причем если число разработчиков растет, то и предел при котором нужен трекер тоже понижается.
Да, очень хорошо подмеченный нюанс. Тем приятнее знать людей выполняющих миграцию с технологий вчера на технологию завтра — с FoxPro на node.js и RaspBerry PI.
Про хадуп очевидно, что он не встроен. Дрова, конечно же. Такая же история была со spread. На 6.1 он чуть ли не отдельно ставился, а сейчас даже как пакет не виден.
С лицензиями сужу только по описанию — сами мы хадуп еще не подняли к вертике
Видимо, речь про HP Vertica SQL for Hadoop.
Драйвера питона есть только для linux x64 и несовместимы с другими OS (пока).
Хадуп встроен в Vertica, только лицензия теперь на него отдельная — по числу нод.
Multiple Active ResultSets — это прекрасно, но в целом такая функциональность есть у конкурентов.
Но этот релиз конечно крутой — исправили кучу того, что мешало жить раньше.
Во-первых, добавился LdapLink — теперь не только пользователи, но и роли могут быть унесены в Ldap (это я еще не тестировал, но руки чешутся еще с версии 6.1).
Во-вторых, добавили inherited privileges — теперь если создается новая таблица, то люди, у которых выдан грант select on all tables, ее все-таки видят, а не ждут повторного выполнения grant.
В-третьих, теперь не надо извращаться с предоставлением доступа к таблице sessions. Спец. роль SYSMONITOR дает доступ к таблицам 8)
В-четвертых, дали возможность уносить тяжелые запросы в другие пулы посередине исполнения (читай, понижать приоритет и уменьшать ресурсы).
Довольно сильно. Говорю с позиции как раз такого сотрудника. Скорее всего, это часто эмоционально неуравновешенные люди с определенной долей инфантилизма. Легко раздражаются в случае активного согласия или малейшего несогласия и начинают саркастически перебивать, унижать собеседника. Исправление зависит от степени испорченности и на мой взгляд достигается чтением книг про переговоры. Как-то так )
А если для второго пункта использовать serialVersionUID? Это, конечно, определенные требования к написанию кода, но можно автоматизировать как проверки, так и собственно добавление этого поля.
Ловлю себя на мысли, что представленный план довольно статичен. То есть принимается как аксиома неизменность потребностей пользователей и уровня владением созданным инструментом. В моем опыте, довольно большое количество проблем решается более глубоким знакомством с используемыми инструментами работы. Конечно, для произведения действия необходимо зафиксировать стабильный уровень опытности пользователей, но очевидно, что его необходимо регулярно пересматривать и приводить в соответствие инструменты-уровень владения.
Кроме того, мне неясен критерий необходимости автоматизации против оптимизации бизнес-процесса (подскажите, может быть не увидел). Можно было бы например рассматривать выигрыш от переложения рутинной работы на автомат и снижение числа человеческих ошибок, но обычно это еще труднее оценить.
А ru.wikipedia.org/wiki/РЖД с 880тч? При этом HP делает бизнес по всему миру. У нас например Enterprise Maps вот в пилоте. Другой вопрос, как они будучи такими крупными и продвинутыми довольно мало средств вкладывают в дизайн и UIX своих продуктов.
Хотел уточнить - по п1. описание механизма Retry https://pulsar.apache.org/docs/2.11.x/concepts-messaging/#retry-letter-topic подходит под описанный сценарий использования?
Еще из приятного — ставите галку установить R Server — на этапе установке инсталлер запросится в интернет. Надо откатываться назад до этапа конфигурации убирать галку и снова с песней.
После этого говорить о том, что это делается для корп окружения (которое с самого начала кремния сидело за прокси), наверное рановато.
Наверное, вы имеете ввиду, что вертика требует идентичные адреса для interconnect/control. На мой взгляд, это мелкое неудобство, поскольку public может быть любым, а interconnect/control все равно должен быть от public отделен ( да и пошире ему сеть нужна 10Gb). Мы у себя разруливаем это через VLAN-ы.
С лицензиями сужу только по описанию — сами мы хадуп еще не подняли к вертике
Видимо, речь про HP Vertica SQL for Hadoop.
Хадуп встроен в Vertica, только лицензия теперь на него отдельная — по числу нод.
Multiple Active ResultSets — это прекрасно, но в целом такая функциональность есть у конкурентов.
Но этот релиз конечно крутой — исправили кучу того, что мешало жить раньше.
Во-первых, добавился LdapLink — теперь не только пользователи, но и роли могут быть унесены в Ldap (это я еще не тестировал, но руки чешутся еще с версии 6.1).
Во-вторых, добавили inherited privileges — теперь если создается новая таблица, то люди, у которых выдан грант select on all tables, ее все-таки видят, а не ждут повторного выполнения grant.
В-третьих, теперь не надо извращаться с предоставлением доступа к таблице sessions. Спец. роль SYSMONITOR дает доступ к таблицам 8)
В-четвертых, дали возможность уносить тяжелые запросы в другие пулы посередине исполнения (читай, понижать приоритет и уменьшать ресурсы).
Кроме того, мне неясен критерий необходимости автоматизации против оптимизации бизнес-процесса (подскажите, может быть не увидел). Можно было бы например рассматривать выигрыш от переложения рутинной работы на автомат и снижение числа человеческих ошибок, но обычно это еще труднее оценить.