Doctrine и PostgreSQL

Проверенные VDS на SSD в Европе и России

Тема в разделе "PHP & Postgres", создана пользователем scorpion-ds, 12 апр 2017.

  1. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    Работаем над проектом Symfony который использует Doctrine и MySQL, на данный момент весь функционал работы с БД реализован средствами ORM (то есть ни каких встроенных функций, триггеров и т.п.), недавно возник вопрос в целесообразности перейти на PostgreSQL.

    Есть ли в этом смысл?

    P.S.: Буквально на днях в другом проекте возникала проблема с deadlock, читал, что в PostgreSQL такой проблемы не было бы.
     
  2. Вурдалак

    Вурдалак Newbie

    Сообщения:
    5.862
    Ваш город:
    Russia, Moscow
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Это и есть причина миграции на другую СУБД?
     
  3. fixxxer

    fixxxer К.О.

    Сообщения:
    12.198
    Ваш город:
    Moscow, Russia
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Какие аргументы за и против? Что конкретно из возможностей postgresql требуется?

    Вжух, и нет дедлоков! :)
    Это такая же глупость, как сказать что-то вроде "если писать на языке XXX, то не будет багов".
    Почитай про то, как работают РСУБД, что такое транзакции и уровни изоляции, и от чего возникают дедлоки.
     
  4. fixxxer

    fixxxer К.О.

    Сообщения:
    12.198
    Ваш город:
    Moscow, Russia
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Кстати, а где это ты такое читал? Ну чтобы обходить это место за милю.
     
  5. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    Я поправил уже, там проблема была не показательная.

    Реальных причин на данный момент нет, обдумать использование встроенных возможностей PostgreSQL и нужны ли они сейчас нет, но через несколько месяцев будет время обдумать различные "оптимизации кода". Так, что эта идея возникла только как на перспективу и из-за того, что поменялся курс приложения и все равно много чего приходится сейчас по быстрому менять.
     
  6. флоппик

    флоппик promotor fidei Команда форума Партнер клуба

    Сообщения:
    4.719
    Ваш город:
    Павлодар, Казахстан
    Adress:
    Pavlodar, Kazakhstan
    Country:
    Location on Map:
    Тебе не кажется, что у тебя каждый раз такая ситуация? )
     
  7. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    Есть такое, за последние 8-9 месяцев, курс поменялся уже трижды, но сейчас наиболее существенно.

    Ситуацию я понял, как и предполагал смысла в этом на данный момент нет, я "надеялся" на какие-то "магические возможности" в PostgreSQL (кстати в чистом виде с фикстурами, развернуть проект на это СУБД получилось), которые бы ускорили и повысили надежность. :)
     
  8. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    Гипотетический вопрос, прям сейчас ничего я меня не собираюсь.

    Сейчас вся логика работы с БД происходит через ORM. В работе приложения есть места, где на основе данных из разных таблиц, подбиваются усредненные данные или я называю это кешированными данными, они используются только для вывода и перезаписываются каждый раз при завершении определенных действий, эти вычисления иногда довольно большие. Может стоит перенести такие вычисление на БД (я имею введу процедуры и т.п.)? Когда-то так делал с MySQL, но были разные проблемы, может ради этого стоило бы перейти на PostgreSQL или другую СУБД?

    Еще вариант поступить более радикально и глянуть в сторону облачных вычислений Амазон, Гугол и MS, но это мне кажется как из пушки по воробьем.

    Такие вопросы у меня возникают после наших митингов, где я все узнаю о нововведениях и сжатых сроках и что ожидаемая нагрузка 15-20 тыс. хитов в минуту (большая часть будет просто на чтение), простои и сбои недопустимы.

    P.S.: Команде я один бэкэнд разработчик, опыта с высоконагруженными приложения у меня нет, во второй команде тимлид и несколько джунов, у них другие проекты, устроить мозговой штурм не представляется возможным, от сюда и странные вопросы.
     
  9. AnrDaemon

    AnrDaemon Продвинутый новичок

    Сообщения:
    3.907
    Ваш город:
    Moscow, Russia
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Если в "тяжёлых вычислениях по определённому действию" тебя смущает именно сам факт отягощения действия последующим процессингом - возьми да раздели эти два события.
    По совершении действия посылай сообщение, которое будет обработано… где-то ещё, независимо от этого действия, но строго по его завершении.
     
  10. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    На данный момент, по завершению "действия" консольно вызывается команда пересчета, что бы сразу "отпустить клиента", но да я подумываю перенести вычисления куда-то еще, но как бы не потратить больше ресурсов на обмен данными между сервисами, чем само вычисление. Каждое "тяжелое вычисление" в отдельности не так страшно, укладываюсь в 1 - 1,5 секунды, но когда их станет больше, это уже может создавать проблемы, еще вариант рассматриваю за раз обрабатывать по несколько вычислений из очереди, но тут появятся задержки "живого интерфейса".
     
  11. AnrDaemon

    AnrDaemon Продвинутый новичок

    Сообщения:
    3.907
    Ваш город:
    Moscow, Russia
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Опять голову забиваешь хернёй?
    Сделай просто, не надо усложнять себе жизнь.
    Если критична обработка сразу - MQ, если плевать - cron раз в минуту.
    И выносить куда-то далеко, чтобы это создавало проблемы на уровне обмена данными, вообще глупость несусветная.
     
  12. scorpion-ds

    scorpion-ds Новичок

    Сообщения:
    983
    Ваш город:
    Kharkiv, Ukraine
    Adress:
    Kharkiv, Ukraine
    Country:
    Location on Map:
    Вроде у нас все согласились, что делаем как делается, потому создаем нагрузочное тестирование, ищем слабые места и решаем проблемы по мере возникновения.

    Также БД будет обнулена, так что СУБД можно будет изменить без проблем.