Игорь, миграции очень часто вообще делают сторонним инструментом или отдельной библиотекой. Например, phinx. Я в своем текущем проекте Доктрину не использую, и могу сказать, что мне только гидраторов разве что не хватает. В остальном, запросы достаточно хитрые - Доктрина избыточна (максимум квери билдер из нее кое-где можно приспособить). А юзать ее только для маппинга результата на объект особого смысла не вижу. По крайней мере, на текущий момент. Кстати, Вы пробовали мокать доктрину для unit-тестов?
Игорь, так а смысл, когда у меня в микросервисе суммарно запросов штук 30 было, из низ лишь 2 или 3 шло через доктрину (ORM), остальное как раз нативно? Нет никакого смысла вообще в таком случае Доктрину оставлять. Только ради маппера разве что.
Arris, второе хорошее и без фреймворка: можно использовать только DBAL из Doctrine (https://www.doctrine-project.org/projects/doctrine... и юзать без фреймворка, как, впрочем, и саму Doctrine целиком, если припрет. Ее вовсе не обязательно вместе с Симфони использовать.
Минус первого и второго варианта заключается в том, что тебе в итоге придется писать руками гидратор. То есть некие функции, которые будут результат выполнения запроса маппить на некий объект (entity) с методами get/set. Можно, конечно, просто напрямую работать с записями из базы, как с массивом, но это такое себе дело, потому что в большом проекте начнется полная каша, когда, например, столбец удаляют/переименовывают - придется по всему коду лазать и менять. И не факт, что где-то не забудешь. Эту проблему даже покрытие тестами не всегда решает, как показала практика.
Минус ORM заключается в том, что они всегда недостаточно гибкие. У меня есть проекты, где изначально была Доктрина, а сейчас я смотрю - и она там по итогу почти не используется, потому что запросы сложные (используют конструкции типа with из PostgreSQL и т.п., которые средствами ORM сложно делать), пришлось их руками писать.
Alexander, вопрос в силе: при чем тут хайлоад?) То, что Вы описали, к хайлоаду вообще отношения не имеет. А с перечисленными задачами вполне спокойно справится даже комп года 2011, скажем. Юниты так вообще легковесные обычно ж, а 700к записей в базе - это вообще копейки. Насчет js-да, всякие хот релоады, действительно, много ресурсов жрут, но, опять-таки, никакого отношения к хайлоаду это не имеет.
Александр Кубинцев, учитывая, что это все топы, Вы, по идее, можете при изменении баланса какого-либо пользователя смотреть максимальный и минимальный элемент в редисе и, если баланс попадает в этот диапазон, то добавлять туда запись, а запись минимальным значением удалять (иначе, если не попадает в диапазон, не делать ничего). То есть ограничить количество элементов в списке в Redis. Вам же в любом случае не потребуется там все 80 миллионов пользователей держать.
DomowDenis, грубо говоря, product_subgroup='A' - это boolean-выражение. Если у записи product_subgroup = A, то это true, иначе false. То есть, получается, что это как сортировка по полю со значением boolean - сначала идут все с true, потом с false.
pygame,
1. Там, где хайлоад и производительность, там не только ORM нет, но и запросов в базу практически не делается, т.к. данные, в основном, берут из кеша, а в базу ходят редко (когда кеш протух). Чтобы заполнить кеш, можно раз в N минут ORMкой в базу сходить - обычно это не проблема. К тому же в любом проекте бывает все равно достаточно много простых запросов. ORM - это ведь не только тяжелый квери-билдер. Например, пилить самостоятельно гидраторы и т.п. не сказал бы, что удобно. Вот делаешь join-запрос нескольких таблиц 1-1, например - и чего, руками на структуры маппить? А в java, где нужна производительность, Hubernate, кстати, не юзают разве?
2. Так и есть, но есть легаси проекты, которые все равно поддерживают, делят на сервисы, переписывают и т.п. Если был там исторически Сфинкс, то не всегда есть реальная возможность его поменять на, скажем, Эластик. Как будто Вы сами с таким никогда не сталкивались)
3. Вполне вероятно, я потому и уточнил, что это субъективно.
4. Так, собственно, и делаю.
5.
Привыкайте к строготипизированным языкам.
То есть это так везде? В java-проектах тоже такая проблема имеется? За jsoniter спасибо - погляжу.
Alex, не совсем правильно выразился насчет первого пункта) Конечно, я имел в виду, что в любом микросервисе, как ни крути, будет достаточно большой процент простых запросов, которые крутить через ORM-ку было бы удобно.
3 - спасибо, учту
4 - ну так инициализирую сервис, допустим, в пакете - пишу его адрес в переменную. Где ее хранить?
5 - а вы пользователям API это скажите. Одно дело, когда API какое-то внутриконторное - это ладно, но API бывает и публичным. И такое себе, если оно крашится на таких вещах.
Konstantin Zhikhor, да и владелец интернет-магазина для правок по сайту может на любой фриланс-бирже найти веб-мастера, который все сделает за гроши. А для сайта на фреймворке нужны нормальные разрабы, работа которых стоит в любом случае дороже.
Konstantin Zhikhor, может быть, отстой, но согласитесь, что поменять платёжную систему в cms куда проще, быстрее и надёжнее, чем делать это в интернет-магазе, который написан вручную на фреймворке.
Для cms есть куча готовых плагинов под почти любые нужды интернет-магазов. Писать это все самостоятельно, даже с использованием современных фреймворков, в любом случае займёт больше времени. Особенно с написанием тестов. И хорошо если фреймворк ещё позволяет генерить и кастомизировать админку, а то и её руками пилить придётся. А потом заказчик придёт и скажет "а давайте добавим акции". К cms это прикручивается просто установкой плагина, а на фреймворке это пилить обычно офигеешь.
grabbee, гугл давно говорит, что ssr не нужен. По факту он такие сайты хуже индексирует, а многие страницы видит пустыми. По крайней мере, ещё год назад так было. Да и в СНГ на траф с яндекса тоже есть смысл ориентироваться.