Комментарии 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 Монги.
Даже в случае bulk insert, не настроенная монго ответит вам как только получит сами данные, в то время как реляционной базе нужно их непосредственно вставить.
Можно, конечно, реляционную субд привести к поведению монги — in-memory tables, delayed transaction durability, но мне кажется вы не об этом.
Давайте сравнивать яблоки с яблоками, а не с теннисными мячиками. В вашем примере можно замерить передачу данных по сети и снова окажется, что она быстрее у РСУБД за счет в разы более компактного табличного формата. Сравнивать время выполнения BULK INSERT корректно не с получением сигнала о передаче пакета (это легко изобразить с SqlBulkCopy.WriteToServerAsync), а с реальной вставкой данных. То, что она не гарантирована - следующий уровень игры.
Вы утверждаете, что вставляя данные в субд «правильный образом» можно добиться скорости не меньше, чем с write concern 0 для монго. Распишите, пожалуйста, что вы понимаете под «правильный образом» и о каких данных мы говорим. Я с радостью проверю ваш способ на postgresql/ms sql, если он для них работает.
Если все-таки желаете сравнивать теплое с мягким, проверяйте (с поправкой на объемы 2008 года)
Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings
PostgreSQL не такой уж и медленный, нормальная альтернатива Oracle, если не нужно чего-то специфического.
Можно подробнее на тему медленного PostgreSQL и быстрого ms sql/oracle
Если не секрет, какой размер кода у бекенда? Меньше 1 млн строк или больше?
Разворачивание происходит по нажатию на одну кнопку в соответствующей ветке. По завершении тестирования мы мерджим ветку в мастер, и после этого она автоматом выкатывается на основной тестовый стенд, чтобы продакты и вообще все желающие могли посмотреть на новую фичу перед релизом.
По нажатию еще одной кнопки происходит мердж в мастер и выкатка на продакшен. Мы специально не делали этот процесс полностью автоматизированным, чтобы можно было в ручном режиме подтвердить деплой в нужное время.
У вас разные репозитории для продакшена и "основной" разработки?
В TeamCity нельзя разграничить доступ по веткам - если дать билдить программисту, то он не только в тест, но и на прод может запустить билд. У вас это как-то решалось?
Спасибо за статью, рад что проект живёт. Я в свое время приложил руку к разработке этого монолита :-)
Хотел спросить, тк не очень понял из статьи, на какие всё-таки конкретно микросервисы вы порезали его?
Если вы из команды "Добро", то можно поинтресоваться, чем у вас занята команда "Зло"? Подбором коллекторов? :)
Никакой практической информации, бла-бла, мы смогли, у нас теперь все круто.
На данный момент куски монаците ещё существуют? И сколько времени занял переезд?
Как мы переезжали с монолита на микросервисы