Как стать автором
Обновить

Комментарии 29

Хочется спросить про то как вам nodejs после .net ? ?

Интересуют некоторые детали.
Из технологий выбрали Node.js для серверной части, React — для фронтенда и MongoDB — в качестве базы данных

Какие причины переезда с .NET и почему именно Node? Рассматривал обе технологии, не заметил огромных преимуществ у ноды, которые бы обосновывали смену технологии после 7 лет опыта работы с другой (рассуждение применимо и к переезду Node -> .NET).

Аналогичный вопрос про Mongo. Какие именно недостатки были у предыдущей базы данных и почему была выбрана Mongo? Используется ли шардирование? Репликация?
Так же, не нашёл в статье, какая база изначально была у монолит решения. Postgres?

Не утверждаю, что технология X лучше технологии Y. Вот про мнолит vs микроскервисы готов поспорить :) Дотнет у нас используется и сейчас в целом ряде проектов, просто это уже не монолит как было раньше, а микросервисы. Про Монго — до этого использовался MS SQL, он не очень идеологически вписывался в наш новый опесорсный стек. Была выбрана Монга как простое решение, но смростом требований и фич оказалось, что она не очень подходит под наши новые задачи.

Вот про мнолит vs микроскервисы готов поспорить :)

Плюсы и минусы есть у обоих подходов, распределённый монолит в разы хуже обычного, поэтому я предпочитаю распиливать на сервисы когда уже есть опыт и понимание доменной области, иначе будут только проблемы. Но это так, полноценный анализ необходимости микросервисов и их пользы занимает огромное количество времени.
Дотнет у нас используется и сейчас в целом ряде проектов, просто это уже не монолит как было раньше, а микросервисы

Ну, в тех проектах, где он перестал использоваться, в чём была причина?

Выглядит как будто вы переехали на «крутые» штуки, особенно учитывая тот же выбор монго, хотя по факту ни у реляционных баз, ни у.нет нет никаких недостатков по сравнению с вашим предыдущим стеком.

То есть вы перешли с реляционной БД на no-sql только по идеологическим соображениям? Ведь есть же mysql, postgresql и тд.

Для слоя БД описана типовая "история успеха":

  • Возьмем Монгу - это модно, стильно и молодежно

  • Уррра! Легко загрузили все данные. Но, блин, что-то с запросами совсем беда...

  • Переходим на Постгрес - это хоть и не молодежно, но модно и, типа, бесплатно

  • Ура! Запросы, наконец, стало удобно писать, язык человеческий. Но, блин, почему так медленно? Неужели Оракл и Микрософт не зря хотят денег за свои СУБД с оптимизаторами, вылизанными за десятки лет?

  • Нет, СУБД из Big-3 нам не потянуть, придется перенести часть вычислений из запросов и хранимых процедур в код служб...

  • Продолжение следует...

Именно

Уррра! Легко загрузили все данные.

Ещё смешнее, что некоторые грузят данные в режиме j:false или вообще w:0, что значит, что они по сути не durable и могут потеряться даже после того, как клиент получил подтверждение об успешной записи. Более того, до версии 5 подобная настройка была дефолтной для монго.

Если же настроить монго корректно, мы обнаружим, что данные грузятся не сильно быстрее. А разгадка одна — в монго нет магии, которая позволяет durable сохранять данные в разы быстрее, чем это делает реляционная база. Мой опыт работы с постгре показывает, что при прочих равных она не сильно проседает на примерно таких же нагрузках.

Если вставлять данные в РСУБД правильным образом, то это не будет медленнее даже не настроенной на durable Монги.

Расскажите, пожалуйста, подробнее, что значит правильный образ. С трудом представляю себе ситуацию, когда пересылка данных по сети и мгновенный ack может быть медленнее, чем пересылка + запись на диск.

Даже в случае bulk insert, не настроенная монго ответит вам как только получит сами данные, в то время как реляционной базе нужно их непосредственно вставить.

Можно, конечно, реляционную субд привести к поведению монги — in-memory tables, delayed transaction durability, но мне кажется вы не об этом.

Давайте сравнивать яблоки с яблоками, а не с теннисными мячиками. В вашем примере можно замерить передачу данных по сети и снова окажется, что она быстрее у РСУБД за счет в разы более компактного табличного формата. Сравнивать время выполнения BULK INSERT корректно не с получением сигнала о передаче пакета (это легко изобразить с SqlBulkCopy.WriteToServerAsync), а с реальной вставкой данных. То, что она не гарантирована - следующий уровень игры.

Давайте более предметно.

Вы утверждаете, что вставляя данные в субд «правильный образом» можно добиться скорости не меньше, чем с write concern 0 для монго. Распишите, пожалуйста, что вы понимаете под «правильный образом» и о каких данных мы говорим. Я с радостью проверю ваш способ на postgresql/ms sql, если он для них работает.

Таки да - sql server bulk insert позволяет заливать данные не перестраивая индексы и закрывая транзакцию в момент окончания импорта.

Этот подход и скорость вставки позволила нам отстоять производительность RDBMS при импорте больших данных, когда бодались с большими клиентами.

Если условия позволяют использовать minimally logged (пустая таблица с ключом, индексы строим позже, заливка в порядке кластерного ключа), то даже простой INSERT SELECT отрабатывает так же быстро, как BULK.

PostgreSQL не такой уж и медленный, нормальная альтернатива Oracle, если не нужно чего-то специфического.

Можно подробнее на тему медленного PostgreSQL и быстрого ms sql/oracle

Если не секрет, какой размер кода у бекенда? Меньше 1 млн строк или больше?

Если честно, очень сложно так навскидку оценить в строках. У нас очень много команд (~30), и репозиториев (~500). Каких-то готовых даже приблизительных оценок у меня на данный момент нет.

Разворачивание происходит по нажатию на одну кнопку в соответствующей ветке. По завершении тестирования мы мерджим ветку в мастер, и после этого она автоматом выкатывается на основной тестовый стенд, чтобы продакты и вообще все желающие могли посмотреть на новую фичу перед релизом.

По нажатию еще одной кнопки происходит мердж в мастер и выкатка на продакшен. Мы специально не делали этот процесс полностью автоматизированным, чтобы можно было в ручном режиме подтвердить деплой в нужное время.

У вас разные репозитории для продакшена и "основной" разработки?

Спасибо, что заметили ошибку, я поправил в статье. Во втором абзаце речь о выкатке в прод кода из мастера по кнопке.

В TeamCity нельзя разграничить доступ по веткам - если дать билдить программисту, то он не только в тест, но и на прод может запустить билд. У вас это как-то решалось?

Спасибо за статью, рад что проект живёт. Я в свое время приложил руку к разработке этого монолита :-)

Хотел спросить, тк не очень понял из статьи, на какие всё-таки конкретно микросервисы вы порезали его?

Если вы из команды "Добро", то можно поинтресоваться, чем у вас занята команда "Зло"? Подбором коллекторов? :)

Сервис "Добро" и подбор кредитных продуктов. :D

Возможно переносит микросервисы в монолит)

НЛО прилетело и опубликовало эту надпись здесь

Никакой практической информации, бла-бла, мы смогли, у нас теперь все круто.

На данный момент куски монаците ещё существуют? И сколько времени занял переезд?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий