Уже 3 года живу на Кипре. К жаркой погоде отношусь спокойно. Зимой и вправду бывает холодно, но это всего пару недель. Часто летаю на родину и ни разу не было проблем в аэропорту. Да, график работы банков на Кипре значительно отличается от банков в СНГ, в остальном с банками все хорошо.
Насчет общественного транспорта согласен. Такси не пользуюсь, так как купил машину. Кондиционера в машине полностью хватает.
Насчет ИТ компании. Я работаю в хорошей ИТ компании и у меня нету таких проблем как у вас. Просто нужно внимательно выбирать компанию.
Возможно вы правы. На тот момент это был мой первый опыт работы с MongoDB и скорей всего, в некоторых местах, я сделал не оптимально. Но, в целом, я остался доволен.
А как насчет выполнения compact или обновления версии mongodb? В нашей конфигурации, мы просто выводили из под нагрузки одну реплику, на ней все делали и снова пускали ее в бой. Затем так же самое на других нодах. При конфигурации мастер-слейв-арбитр так получиться сделать?
Нам нужна была гибкая структура данных. Мы меняли модель одного документа примерно 1 — 2 раза в неделю.
Только искусственный шардинг, иначе говоря, партиционирование.
PostgreSQL рассматривали. Но на тот момент когда мы выбирали БД, у них не было поддержки запросов, с условиями по json. Нельзя было делать индексы по конкретным ключам json.
Для нас были важны две вещи. Во-певрых это скорость обработки, а во-вторых, что бы каждый шард был всегда доступен. Самая минимальная конфигурация репликасета как раз и состоит из 1 мастера и 2 слейвов.
У нас было 4 шарда, каждый шард состоял из 3 нод (1 мастер, 2 реплики). Все ноды были одинаковые — 4 CPU, 12 GB RAM, 100 GB HDD.
Да, что касается стоимости, MongoDB не дешевое удовольствие. Хотя это наверное все относительно, так как есть и более дорогие решения, например, Amazon DynamoDB. Ну и для банка это были не большие деньги, тем более, система себя очень хорошо показала.
Мы использовали MongoDB для системы по анализу платежей на предмет мошенничества. MongoDB выбрали по двум причинам:
Легко расширять модель платежа.
Легко шардируется.
Давайте теперь по порядку.
1) Банк достаточно крупный, поэтому он имеет огромное количество каналов через которые пользователь может совершать платежи. Все каналы разрабатываются разными командами, иногда даже на разных языках. У всех каналов формат платежей разный. Формат может часто меняться. Поэтому нам было важно иметь гибкую модель данных.
2) Система построена на анализе истории платежей. Shard key был выбран таким образом, что все расчеты по конкретному платежу происходили в пределах одного шарда, что значительно снизило время на обработку одного платежа. Время обработки одного платежа было критичным, так как система должна была работать в real-time режиме и бизнес выделял не более 1 сек. на анализ.
Если будет интересно, могу написать более подробную статью о том, как мы использовали MongoDB. Сейчас этот комментарий выглядит очень сумбурно )
Скажите пожалуйста, а native методы не попадают под JIT оптимизации? Если попадают, то как происходят эти оптимизации и есть ли вообще в них смысл для native методов?
Дальше я думал написать о производительности Spring. Я мог бы попробовать копнуть Spring еще чуть-чуть глубже, но не уверен, что это будет кому-нибудь интересно. А вообще, предлагайте темы связанные со Spring, я с радостью разберусь в них и напишу об этом)
BeanDefinition — это java интерфейс и он не переводится, а по поводу «парсирования» и «кастомных», как по мне, то для ИТ сообщества эти слова более привычны, нежели «разбор» и «собственных».
Уже 3 года живу на Кипре. К жаркой погоде отношусь спокойно. Зимой и вправду бывает холодно, но это всего пару недель. Часто летаю на родину и ни разу не было проблем в аэропорту. Да, график работы банков на Кипре значительно отличается от банков в СНГ, в остальном с банками все хорошо.
Насчет общественного транспорта согласен. Такси не пользуюсь, так как купил машину. Кондиционера в машине полностью хватает.
Насчет ИТ компании. Я работаю в хорошей ИТ компании и у меня нету таких проблем как у вас. Просто нужно внимательно выбирать компанию.
А как насчет выполнения compact или обновления версии mongodb? В нашей конфигурации, мы просто выводили из под нагрузки одну реплику, на ней все делали и снова пускали ее в бой. Затем так же самое на других нодах. При конфигурации мастер-слейв-арбитр так получиться сделать?
PostgreSQL рассматривали. Но на тот момент когда мы выбирали БД, у них не было поддержки запросов, с условиями по json. Нельзя было делать индексы по конкретным ключам json.
Год назад была вот такая ситуация:
Да, что касается стоимости, MongoDB не дешевое удовольствие. Хотя это наверное все относительно, так как есть и более дорогие решения, например, Amazon DynamoDB. Ну и для банка это были не большие деньги, тем более, система себя очень хорошо показала.
Давайте теперь по порядку.
1) Банк достаточно крупный, поэтому он имеет огромное количество каналов через которые пользователь может совершать платежи. Все каналы разрабатываются разными командами, иногда даже на разных языках. У всех каналов формат платежей разный. Формат может часто меняться. Поэтому нам было важно иметь гибкую модель данных.
2) Система построена на анализе истории платежей. Shard key был выбран таким образом, что все расчеты по конкретному платежу происходили в пределах одного шарда, что значительно снизило время на обработку одного платежа. Время обработки одного платежа было критичным, так как система должна была работать в real-time режиме и бизнес выделял не более 1 сек. на анализ.
Если будет интересно, могу написать более подробную статью о том, как мы использовали MongoDB. Сейчас этот комментарий выглядит очень сумбурно )