Бобби Шифер, Ну если все делать по честному, то нужно идти к автору на работу, всех опрашивать, и оценивать бизнес процесс, после уже предлагать решение ;)
То что я вижу из сообщения, сервис начал расти, и его функционал требуется расширить на несколько пользователей(опять непонятно на сколько ?). То есть динамика и курс идет на увеличение нагрузки. А дальше я просто продолжил Ваше решение на рост. И в таком случае веселье начинается даже не на 10к . а когда пользователей станет от 50. Резко вырастают накладные расходы на администрировании, не говоря уже о смежных случаях аналитики, или быстрых запросов, а сколько пользователей сегодня логинилось.
Да и со стороны проектирования баз данных, я бы не сказал что такое решение правильно.
Бобби Шифер, Честно мне жуткой представить , как такая система будет справляться с ростом пользователей. Когда перевалить их хотя бы за 1000. Потом вылезут проблемы с тем что нам надо будет мапить пользователей к каким-нибудь продуктам(другим таблицам(например к покупкам)).
Бобби Шифер, да нет, не выворачиваю. Думаю это первый или второй вопрос , который возникнет, после ввода в эксплуатацию системы.
Мне интересно посмотреть на лицо DataScientist когда ему скажут, что все пользователи лежат по разным базам данных, причем в каждой базе один пользователь.
И еще интереснее , посмотреть на запрос который будет вытягивать всех пользователей.
Или вот еще кейс, как в такой структуре найти самого старого пользователя, или у кого больше денег сейчас на счету..
Безопасность это хорошо, но не надо выворачивать инструменты ради нее, после таких действий они начинают плохо работать.
UPD еще в голову пришло, всеми любимые индексы, как их делать ?
Бобби Шифер, как проводить бизнес аналитику в такой структуре ? Как реализовать регистрацию пользователей ?
безопасность это хорошо, но что то у меня есть сомнения, что база не скажет ой при 10000 пользователей.
Jacen11,
По поводу непредсказуемо. Каждая профессия подразумевает определенный набор скиллов.
Из-за того что у меня "гибридная специализация", это приводит к тому, что часть скиллов , относительно чистой специализации, у меня нет, или недостаточно прокачаны. Я могу претендовать на должность, но скорее всего с грейдом ниже чем я сейчас занимаю. Со всеми вытекающими. И просто разбрасывая свое резюме на все вакансии, я просто буду тратить время на разговоры с неустраивающим меня результатом. Конечно есть вариант, что скажут о ты то нам и нужен и будут платить дофига денег. Но в реальности, будут пытаться сыграть на то что знаний недостаточно, но ты преспективен, поэтому мы готовы платить x/4, а там посмотрим.
По сути много действий, с вероятно не преспективным исходом. А время дорогой ресурс, с учетом того что надо есть , пить, желательно развлекаться, не говоря уже о всяких обязательствах.
хотите чтобы звали на 90 из 100 на работу? зачем если достаточно одного?
Потому что это как минимум возможность выбрать, где будет комфортнее. Где печеньки вкуснее, быстрее до работы добраться и пр.
Jacen11, в принципе мне ваша позиция понятна. И она рабочая.
Мне этот вариант не нравиться, слишком не предсказуемо.
А может предыдущие собеседования у меня были не очень удачными, когда я менял работу последний раз.
Из-за этого наверное есть опасения, и хотелось бы больше устойчивости в новом раунде.
Jacen11, Это понятно.
Сложность в другом. Благодаря опыту, я могу претендовать на несколько позиций. В каких то вещах я более прокачен, в каких то менее. Но даже в том что я менее прокачан, это реальные боевые навыки, а не просто книжку прочитал.
Например у меня есть опыт управления людьми. Сейчас у меня небольшая команда в подчинении. Но достаточно ли этого количества людей , чтобы претендовать в дальнейшем например : на должность зама начальника отедела, вот у меня сомнения берут.
Отсюда то и вопрос. Как мне лучше себя позиционировать, идти на архитектора, или не париться и искать работу програмцом.
Тут же еще такой вопрос, как dba у меня уровень около jun. И если я пойду jun dba , просто кушать нечего будет.
Вероятно, я сильно заморачиваюсь. Поэтому и ищу возможность понять что происходит вокруг, и как мне со всем этим крутиться.
Мне нужна внешняя оценка спеца, который понимает пути развития в ИТ, чтобы он сопоставил мои пожелания , мой опыт, и подсказал в какую сторону лучше идти. Рекрутеры они стараются закрыть свои вакансии, а моя задача на текущий момент понять, как лучше позиционировать себя. Человек, который бы выступал с моей стороны и моих интересов, а не интересов работодателя.
Тимур Шамсутдинов, В браузерах надо будет указать прокси сервер, на каждой рабочей станции. Вообще могут быть различные варианты настройки. Можно сделать прозрачный прокси, а через DHCP , как шлюз по умолчанию выставить прокси сервер.
По поводу статичного ip, базово , да вам нужно будет сделать статичный ip адрес. Но опять же могут быть варианты. Например есть технология когда рабочая станция или сервер автоматически регистрируются со своим ip на DNS сервере. Если выставить в настройки прокси DNS имя прокси сервера, и реализовать этот механизм, можно оставить динамичным ip.
Почему плохое решение делать сервис на своей рабочей станции. Это ваша рабочая станция, у вас может возникать необходимость перезагружаться, вы можете запускать какие то приложения необходимые для вашей работы. Все это несет риски , что сервис будет недоступен для пользователей. Что не хорошо для сервиса, и в конечном итоге для вас.
Тимур Шамсутдинов, лучше на отдельном сервере. В простом варианте , на роутере запрещаете выходить в интернет всем, кроме прокси. На рабочих компах в браузерах прописываете прокси. При желании можете приправить прокси аутентификацией пользователей.
Можно развернуть прокси на своей рабочей станции, но это будет плохое решение.
ух, как я давно задавал этот вопрос )
Спасибо за рекомендацию, проблемка была решена года полтора назад )
На тот момент, с текущей высоты , вопрос стоял скорее так: как в спринг сделать подключение к двум базам данных, при этом ClickHouse не имеет ORM hibernate ) Драйвера , даже на тот момент были не проблемой, на страничке с jdbc были официальные , и альтернативные , которые поддерживали даже бинарный режим работы )
Но все равно спасибо за статью)
В целом я покопался, грешу пока что на vmware tools и небольшом расхождении времени между хостом и виртуалкой . Vmware tools пытается синхронизировать время , и ломает процесс ntp.
Сейчас сделал два действия Хост перевел на ntp синхронизацию, плюс в крон добавил перезагрузку ntp каждые 4 часа. Вроде бы пока что сервис жив, и время системы адекватное.
1) Когда смотрел было нормальным, но выставленно было руками. Сейчас перевел на ntp синхронизацию.
2) Есть , где установлен ntp, он не падает.
3) До перезагрузки сервиса пишет connection refuse , после перезагрузки выдает штатную картинку с серверами с которыми он синхронизируется.
В целом я покопался, грешу пока что на vmware tools и небольшом расхождении времени между хостом и виртуалкой . Vmware tools пытается синхронизировать время , и ломает процесс ntp.
Сейчас сделал два действия Хост перевел на ntp синхронизацию, плюс в крон добавил перезагрузку ntp каждые 4 часа. Вроде бы пока что сервис жив, и время системы адекватное.
zyusifov11, в начале кода, у вас должны быть строчки import , что там указано?
По коду, у вас должна быть еще одна функция, которая должна выполнить запрос. Что нибудь типа con.send();
Так же вы просто выполняете методы, а результат никуда не пишется. Если допустить что con.setRequestMethod("GET"); сразу же отправляет запрос , то в приведенном примере вы никак не обрабатываете ответ.
Не идет или нет вывода ? По коду у вас есть запрос, а потом вы закрываете соединение. А куда вы пишете ответ от сервера ?
UPD. Какая библиотека используется ? Сейчас посмотрел внимательно. Скорее по коду вы просто выставляете метод, и после закрываете соединение. Вероятно даже запрос не шлется.
То что я вижу из сообщения, сервис начал расти, и его функционал требуется расширить на несколько пользователей(опять непонятно на сколько ?). То есть динамика и курс идет на увеличение нагрузки. А дальше я просто продолжил Ваше решение на рост. И в таком случае веселье начинается даже не на 10к . а когда пользователей станет от 50. Резко вырастают накладные расходы на администрировании, не говоря уже о смежных случаях аналитики, или быстрых запросов, а сколько пользователей сегодня логинилось.
Да и со стороны проектирования баз данных, я бы не сказал что такое решение правильно.