День 117 :: Почему PostgreSQL замедляет наш MVP, но это того стоит 🐘💡
Если бы стартапы были кулинарией, то переход с MySQL на PostgreSQL — это как поменять газовую плиту на молекулярную кухню. Всё сложнее, дольше, но результат... Когда-нибудь он будет фантастическим. А пока объясняем, почему мы «допиливаем» и терпим.
---
Почему PostgreSQL задерживает наш MVP?
1. «Мы учимся заново готовить»
Раньше мы жили в уютном мире MySQL, где JOIN-ы были простыми, а запросы — предсказуемыми.
Теперь — погружаемся в PostgreSQL с его:
- CTE (Common Table Expressions) — это как SQL на стероидах.
- Оконными функциями — чтобы делать аналитику в одном запросе.
- JSONB — потому что NoSQL внутри SQL это круто (и сложно).
Итог: Пишем запросы в 2 раза дольше, но они в 10 раз мощнее.
---
2. «Микросервисы требуют магии»
Наш сервис — это не монолит, а оркестр из микросервисов. PostgreSQL тут — дирижёр, который должен:
- Синхронизировать данные между сервисами без конфликтов.
- Обрабатывать сложные JOIN между 100+ таблицами (спасибо, что вообще есть).
- Масштабироваться так, чтобы не упасть при первом же наплыве заказов.
Пример: Запрос для расчёта оптимального маршрута курьера в реальном времени — это не
---
3. «Тестирование — это ад»
Раньше в MySQL мы проверяли запросы за 5 минут. Теперь:
- EXPLAIN ANALYZE — чтобы понять, почему запрос тормозит.
- Индексы-призраки — то создашь, то удалишь, а они всё равно не работают.
- Репликация и шардирование — потому что «надо сразу делать как у взрослых».
Почему мы не откажемся от PostgreSQL?
1. Сложные запросы = гибкость
- Геоданные — ищем ближайших курьеров через PostGIS.
- Полнотекстовый поиск — чтобы пользователи находили «крымский сыр» даже с опечаткой.
- Триггеры и процедуры — автоматизируем всё, что можно.
2. Надёжность > скорость
MySQL падал при 1000 одновременных запросов. PostgreSQL держит удар даже при 10 000.
3. Будущее уже здесь
Когда мы масштабируемся до уровня Alibaba (а мы масштабируемся!), PostgreSQL позволит:
- Горизонтально масштабировать базу через Citus.
- Работать с Petabytes данных без переписывания кода.
- Строить real-time аналитику прямо в БД.
---
Что в итоге?
Да, мы тормозим. Но только потому, что:
- Пишем не «костыли», а архитектуру на 5 лет вперёд.
- Учимся работать с инструментом уровня Enterprise.
- Готовимся к тому, что наш MVP превратится в монстра с 500 000 RPS.
P.S. Если бы Илон Маск спешил, SpaceX до сих пор запускала бы ракеты на MySQL.
@achopochom — закулисье создания стартапа🦄
#стартап #PostgreSQL #MVP #техдолг #микросервисы
Если бы стартапы были кулинарией, то переход с MySQL на PostgreSQL — это как поменять газовую плиту на молекулярную кухню. Всё сложнее, дольше, но результат... Когда-нибудь он будет фантастическим. А пока объясняем, почему мы «допиливаем» и терпим.
---
Почему PostgreSQL задерживает наш MVP?
1. «Мы учимся заново готовить»
Раньше мы жили в уютном мире MySQL, где JOIN-ы были простыми, а запросы — предсказуемыми.
Теперь — погружаемся в PostgreSQL с его:
- CTE (Common Table Expressions) — это как SQL на стероидах.
- Оконными функциями — чтобы делать аналитику в одном запросе.
- JSONB — потому что NoSQL внутри SQL это круто (и сложно).
Итог: Пишем запросы в 2 раза дольше, но они в 10 раз мощнее.
---
2. «Микросервисы требуют магии»
Наш сервис — это не монолит, а оркестр из микросервисов. PostgreSQL тут — дирижёр, который должен:
- Синхронизировать данные между сервисами без конфликтов.
- Обрабатывать сложные JOIN между 100+ таблицами (спасибо, что вообще есть).
- Масштабироваться так, чтобы не упасть при первом же наплыве заказов.
Пример: Запрос для расчёта оптимального маршрута курьера в реальном времени — это не
SELECT * FROM orders. Это 15 вложенных подзапросов, 3 оконные функции и молитва. ---
3. «Тестирование — это ад»
Раньше в MySQL мы проверяли запросы за 5 минут. Теперь:
- EXPLAIN ANALYZE — чтобы понять, почему запрос тормозит.
- Индексы-призраки — то создашь, то удалишь, а они всё равно не работают.
- Репликация и шардирование — потому что «надо сразу делать как у взрослых».
Почему мы не откажемся от PostgreSQL?
1. Сложные запросы = гибкость
- Геоданные — ищем ближайших курьеров через PostGIS.
- Полнотекстовый поиск — чтобы пользователи находили «крымский сыр» даже с опечаткой.
- Триггеры и процедуры — автоматизируем всё, что можно.
2. Надёжность > скорость
MySQL падал при 1000 одновременных запросов. PostgreSQL держит удар даже при 10 000.
3. Будущее уже здесь
Когда мы масштабируемся до уровня Alibaba (а мы масштабируемся!), PostgreSQL позволит:
- Горизонтально масштабировать базу через Citus.
- Работать с Petabytes данных без переписывания кода.
- Строить real-time аналитику прямо в БД.
---
Что в итоге?
Да, мы тормозим. Но только потому, что:
- Пишем не «костыли», а архитектуру на 5 лет вперёд.
- Учимся работать с инструментом уровня Enterprise.
- Готовимся к тому, что наш MVP превратится в монстра с 500 000 RPS.
P.S. Если бы Илон Маск спешил, SpaceX до сих пор запускала бы ракеты на MySQL.
@achopochom — закулисье создания стартапа🦄
#стартап #PostgreSQL #MVP #техдолг #микросервисы
👍3❤1🔥1
День 155 :: Инфраструктура это фундамент
Стартап можно представить как небоскрёб. Можно нарисовать красивый фасад, повесить гирлянды и кричать: «Смотрите, мы самые высокие!». Но если нет фундамента — первый же шторм превратит его в руины.
В этом месяце мы глубоко копали, заливали бетон и прокладывали арматуру.
Инфраструктура — это супер важно. Сломаный код можно починить за час. Если сломалась инфраструктура - сервис может лежать сутками, а клиенты и инвесторы этого страшно не любят.
Поэтому наша цель сразу построить систему, которая выдержит 100 000 заказов в час, 10 обновлений в день и крики «Почему опять всё сломалось?».
Что мы делали месяц?
Коротко:
1. Документировали всё, даже чайник в офисе
- Писали инструкции так подробно, что даже кофемашина теперь умеет деплоить код.
- Ещё из важного - 50 страниц про то, как настроить RabbitMQ, чтобы он не глючил при лунном свете.
2. Тестировали. Ещё раз тестировали. И снова.
- Запускали и перезапускали все по 10 раз. Сначала кто в лес, кто по дрова. Сейчас получше. Дальше больше.
3. Настраивали CI/CD как для космического шаттла
- Теперь к каждому коммиту можно прикрутить хоть 20 тестов, включая «а не сломает ли это закон Ома?».
- Автоматические деплои. Уже скоро. И это уже серьезно. Даже ИИ заподозрил здесь магию.
Цифры, которые не соврут:
- 250+ файлов с документацией и техзаданиями.
- 140 часов билдов: система выдержала, но наши нервы — под вопросом.
Почему это важно? Пример из жизни: В 2012 году Airbnb рухнул в самый неподходящий момент — из-за плохой инфраструктуры. У них всё закончилось хорошо. Но хотим ли мы повторять их ошибку?
Что сейчас?
Мы готовы к тому, чтобы:
- Масштабироваться в 10 раз за неделю.
- Добавлять фичи без страха, что всё развалится.
- Спать спокойно (ну, почти).
@achopочом — закулисье создания стартапа🦄
#инфраструктура #техдолг #масштабирование #CI_CD #тестирование
Стартап можно представить как небоскрёб. Можно нарисовать красивый фасад, повесить гирлянды и кричать: «Смотрите, мы самые высокие!». Но если нет фундамента — первый же шторм превратит его в руины.
В этом месяце мы глубоко копали, заливали бетон и прокладывали арматуру.
Инфраструктура — это супер важно. Сломаный код можно починить за час. Если сломалась инфраструктура - сервис может лежать сутками, а клиенты и инвесторы этого страшно не любят.
Поэтому наша цель сразу построить систему, которая выдержит 100 000 заказов в час, 10 обновлений в день и крики «Почему опять всё сломалось?».
Что мы делали месяц?
Коротко:
1. Документировали всё, даже чайник в офисе
- Писали инструкции так подробно, что даже кофемашина теперь умеет деплоить код.
- Ещё из важного - 50 страниц про то, как настроить RabbitMQ, чтобы он не глючил при лунном свете.
2. Тестировали. Ещё раз тестировали. И снова.
- Запускали и перезапускали все по 10 раз. Сначала кто в лес, кто по дрова. Сейчас получше. Дальше больше.
3. Настраивали CI/CD как для космического шаттла
- Теперь к каждому коммиту можно прикрутить хоть 20 тестов, включая «а не сломает ли это закон Ома?».
- Автоматические деплои. Уже скоро. И это уже серьезно. Даже ИИ заподозрил здесь магию.
Цифры, которые не соврут:
- 250+ файлов с документацией и техзаданиями.
- 140 часов билдов: система выдержала, но наши нервы — под вопросом.
Почему это важно? Пример из жизни: В 2012 году Airbnb рухнул в самый неподходящий момент — из-за плохой инфраструктуры. У них всё закончилось хорошо. Но хотим ли мы повторять их ошибку?
Что сейчас?
Мы готовы к тому, чтобы:
- Масштабироваться в 10 раз за неделю.
- Добавлять фичи без страха, что всё развалится.
- Спать спокойно (ну, почти).
@achopочом — закулисье создания стартапа🦄
#инфраструктура #техдолг #масштабирование #CI_CD #тестирование
1🔥4👍3❤2