Комментарии

Я уже где-то встречал это мнение, кажется в сообществе Doctrine так считается. Я думаю, это неправильный подход. Конструктор это по своей природе функция, которая вызывается при создании объекта в оперативной памяти некоторого процесса, для инициализации занимаемой им оперативной памяти. Это инфраструктурная вещь. Если у нас есть более высокоуровневая абстракция, если у нас одна и та же сущность может появляться в разных процессах, значит и для конструктора нужно создать более высокоуровневую абстракцию, специальный бизнес-конструктор, который и будет вызываться один раз. А не пытаться через рефлексию и аннотации имитировать то, что должно быть в конструкторе.

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

То есть инжектить сторонние зависимости через сигнатуру метода сущности? Тогда остаётся вопрос, в какой момент остановиться и не отработать весь процесс приложения в этом методе сущности)

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

Остаются бизнес-сервисы, сервисы предметной области. Тут подход другой: мы моделируем сущность, она имеет жизненный цикл и создаётся, конструируется только один раз. То есть ее конструктор должен вызываться только один раз. Если про rest-like веб API говорить, то где-то в обработчике соответствующего POST метода. Если про UI, то где-то в обработчик кнопок new/create/etc.

Используемый ORM/ODM/… или даже язык в целом, может не допускать такой сценарий и придётся использовать какой-то именованный конструктор/фабричный метод/фабрику, но вот семантика должна сохраниться, то есть инжектить сервисы через конструктор даже под их капотом всё равно нельзя, по-моему. У класса сущности должна быть одна ответственность — моделировать сущность предметной области. Если и надо что-то инжектить в сущность, то из-за эфемерной природы программных сервисов (их в базу не сохранишь), то через double dispatch

Вот это мне не удаётся хорошо обосновать. Стараюсь через Clean Architecture, но с сомнительным успехом. Еще через глобальное состояние и «чистоту» эффектов, но через это по-видимому я вообще только себе могу что-то доказать. В материалах по DDD разве есть что-то про это? По-моему нет.

Во-первых, DDD не ограничивает источники единого языка, он просто должен быть единым в рамках чётко определённого контекста. И бизнес вполне может перестать использовать некоторые «доморощенные» термины в пользу предложенных разработчиками. И это реально работает.

DDD роли бизнес-аналитика и архитектора не исключает. Более того, субъективно, их функции становятся более важными. Бизнес-аналитик же по определению должен быть экспертом предметной области. Или нет? Да и архитектуру кто-то должен определять. Например, «достоин» ли какой-то контекст, агрегат или даже сущность выноса в отдельный сервис или нет.

В пределе, наверное, бизнес-аналитик и архитектор могут «заставить» разработку идти по DDD даже без ведома разработчиков. Архитектор определит слои, бизнес-аналитик контексты и модели, а разработчики будут это имплементировать. Разве что жаловаться будут на то, что эти самодуры лезут в детали реализации, типа какая разница как у нас класс называется, если пользователь этого не знает. Или что запрещают инжектить сервис в сущность через конструктор, хотя это удобно.

Да, есть такое. Поэтому мы и пытались сделать лаг репликации минимальным.

Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.

Создает, но меньшую. Намного меньшую.

А репликационный слот не создает нагрузки?

Операция чтения WAL идет через репликационный слот и нагрузка в таком случае будет минимальна, нежели сделать фуллскан по всем записям в таблице.

Нагрузка не может не увеличится, вы же как минимум выполняете операцию чтения WAL. Плюс сам инструментарий.

Познавательно для желающих реализовать репликацию данных. Сам писал собственный тул для реплицирования из SQLServer в PostgreSQL и Kafka на основе вычитывания данных из SQLServer Snapshot и последующим автоматическим переключением на живую SQLServer базу и считыванием изменений из CDC (LSN является ориентиром). Очень много подводных камней. Сейчас улучшаю перформанс первоначальной загрузки из snapshot и тесты показывают, что в разы вырастает скорость если считываю данные из snapshot в CSV, после через CopyIn в PostgreSQL с временным удалением индексов и primary ключей в PostgreSQL.

Решения для работы с распределёнными источниками

БД-источник может быть шардированной, как, например, Tarantool. Каждый из инструментов работает с такими БД по-разному.

— Debezium Embedded. Масштабирование выполняется по шардам и вручную, оффсеты хранятся в приёмнике для каждого шарда.
— Debezium Server. Масштабирование выполняется по шардам с помощью Kubernetes. Оффсеты хранят в файле, Kafka, Redis, приемнике для каждого шарда.
— Kafka-connect. Масштабирование выполняется по шардам с помощью тасков Kafka-connect — для каждого ReplicaSet запускается отдельный таск, который будет считывать данные. Оффсеты для каждого шарда хранятся в Kafka.

Главное из нашего опыта

— Зачастую к репликации высокие требования. Нам были важны скорость, отказоустойчивость, отсутствие дополнительной нагрузки. Исходя из этих требований мы выбрали механизм Change Data Capture, который удовлетворял всем основным критериям.
— Инструмент надо выбирать с учётом стека конечных пользователей. Наши заказчики часто работают с Java, поэтому, чтобы обеспечить совместимость решения, в качестве основы стека мы выбрали Java и Debezium.
— Монолитные приложения не всегда хороши. Debezium Embedded было сложно масштабировать и конфигурировать, поэтому мы перешли на Debezium Server. Это универсальное не монолитное решение, которое позволяет добавлять свои коннекторы и масштабироваться с помощью Kubernetes.
— Ошибки при создании инструмента для репликации неизбежны. Мы столкнулись с рядом проблем: высокий лаг, низкая отказоустойчивость, сложная архитектура. Каждый из недостатков нам пришлось устранять отдельно. Но тщательная доработка помогла нам получить инструмент, с помощью которого можно переливать данные из PostgreSQL в Tarantool с низким лагом репликации и сохранением консистентности.

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

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

Текущий мониторинг, интерпретация и улучшение данных — ещё одно неотъемлемое требование, способное превратить реактивное управление качеством данных в проактивное. Так как всё движется по замкнутому кругу, пусть это будет круг высококачественных и ценных данных.

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

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

Текущий мониторинг, интерпретация и улучшение данных — ещё одно неотъемлемое требование, способное превратить реактивное управление качеством данных в проактивное. Так как всё движется по замкнутому кругу, пусть это будет круг высококачественных и ценных данных.

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

Думаю Вам следует тщательно оценить Аврору, прежде чем рассматривать ее. Запустите экземпляр и настройте тестовый экземпляр вашего приложения и базы данных. Создайте как можно большую нагрузку. Я делал это в своей прошлой компании и обнаружил, что, несмотря на заявления Amazon о высокой производительности, Aurora потерпела сокрушительное поражение. На два порядка медленнее, чем RDS. У нашего приложения был высокий уровень трафика записи.

Наш вывод: если у вас есть вторичные индексы и высокий трафик записи, Aurora не подходит. Могу поспорить, что это хорошо для трафика только для чтения.

(Редактировать: тестирование, которое я описываю, было проведено в первом квартале 2017 года. Как и в случае с большинством сервисов AWS, я ожидаю, что Aurora со временем улучшится. У Amazon есть четкая стратегия: « Выпускать идеи на 70%, а затем повторять ». Отсюда мы должны сделать вывод, что новый продукт AWS достоин тестирования, но, вероятно, не готов к производству в течение как минимум нескольких лет после его представления).

В этой компании я рекомендовал RDS. У них не было специального персонала администратора базы данных, и автоматизация, которую RDS обеспечивает для операций с БД, таких как обновления и резервное копирование, была очень полезна. Вы жертвуете некоторой гибкостью при настройке параметров, но это не должно быть проблемой.

Худшее неудобство RDS заключается в том, что у вас не может быть пользователя MySQL с привилегией SUPER, но RDS предоставляет хранимые процедуры для большинства распространенных задач, для которых вам потребуются привилегии SUPER.

Я сравнил экземпляр RDS в нескольких зонах доступности с набором реплик экземпляров EC2, управляемых Orchestrator. Поскольку для обеспечения кворума Orchestrator требуется три узла, RDS оказался здесь явным победителем по стоимости, а также по простоте настройки и эксплуатации.

Я искал лучшие практики по настройке базы данных в облаке, но мне до сих пор не ясно, какое из следующих решений нам следует использовать?

— Amazon RDS Аврора
— Amazon RDS MySQL
— MySQL в экземплярах EC2

Я считаю, что Amazon Aurora позиционируется как лучшая альтернатива, однако после некоторых исследований кажется, что люди ее не используют. Есть ли в этом проблема?