Данные — это фундамент большинства систем. Они эволюционируют вместе с кодом и архитектурой: происходит развитие способов хранения и работы с данными. Миграция данных всегда сопряжена с риском их потери и нарушения работоспособности системы. А если речь заходит о смене БД, риски и сложность миграции возрастают на несколько порядков.
В том числе по этой причине многие основательно подходят к выбору БД: фундамент должен быть прочным, его должно хватить надолго, он должен выдерживать нагрузку с хорошим запасом. Поскольку кривая эволюции может увести далеко от начальных архитектурных предположений, большинство делают выбор в пользу универсального и проверенного решения — реляционного хранилища. Чаще всего это монолитные реляционные базы вроде PostgreSQL или MySQL/MariaDB. Откровенно говоря, я не поддерживаю идею выбора хранилища на основе принципа "проверенное — значит подходящее". Выбор следует делать осознанно, учитывая требования к системе, возможности хранилища, результаты прикладных экспериментов и тестов.
Ясно, что принести на сопровождение подходящее, но никому неизвестное решение — это зачастую совсем не вариант, особенно на ранних этапах развития продукта. Но это один из возможных вариантов, который нужно отвергать обоснованно. Возможно, что миграция данных в будущем обойдётся дороже, чем освоение нового инструмента на старте.
Так или иначе, оказавшись в ситуации, когда хранилище перестает отвечать требованиям, начинается процесс усложнения решения. С одной стороны, это нормально. Усложнение можно списать на эволюцию и зрелость. С другой стороны, усложнение может являться предвестником того, что достигнут некоторый предел возможностей, и его преодоление возможно лишь за счет "неестественных надстроек". Например, недавно рассматривал, что может пойти не так с PostgreSQL и как можно с этим ужиться. Бесспорно, иногда это достойный компромисс вместо того, чтобы менять БД.
О каких усложнениях идет речь? Основные усилия направлены на обеспечение согласованности данных (saga, 2PC, inbox/outbox patterns), в том числе по той причине, что часть данных переносят в отдельное (NoSQL) хранилище и/или микросервис. В таких случаях инфраструктурного кода становится на порядок больше кода с бизнес-логикой. Возрастает вероятность возникновения ошибок, порог входа в проект и требования к специалистам для его поддержания и развития.
Чтобы однажды не дойти до предела возможностей БД и не начать городить огород раньше времени, лучше воспользоваться следующим чек-листом:
- Предвидится большой размер базы данных.
- Необходимо горизонтальное масштабирование.
- Необходимы высокие гарантии отказоустойчивости.
- Необходимы гарантии высокой доступности.
Если хотя бы на один вопрос ответ "да", то следует смотреть в сторону распределенных (SQL-) баз данных. С одной стороны, это гораздо более сложное решение, чем какой-нибудь легковесный монолитный PostgreSQL, с другой стороны, это позволит существенно упростить код приложения, оставив в нём место только для бизнес-логики. Все вопросы согласованности делегируются хранилищу, и кажется, что это очень хорошо и правильно. Может, действительно, не стоит изобретать велосипед?!
В качестве распределенных SQL-баз мне показались интересными следующие решения:
По активности развития и зрелости этих решений можно сказать, что они пользуются большим спросом. И не случайно, ведь можно получить лучшую версию удобного и универсального SQL-хранилища со всеми преимуществами масштабирования, которые многие почему-то до сих пор приписывают только NoSQL.
P.s. Если вам интересна данная тематика, присоединяйтесь к моему каналу "Архитектоника в ИТ" в Telegram или Дзен. Буду рад поделиться опытом. ;-)