Как стать автором
Обновить

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

Время на прочтение 10 мин
Количество просмотров 4.6K
Всего голосов 9: ↑7 и ↓2 +5
Комментарии 17

Комментарии 17

Я работаю с java-программистом, который такой подход исповедует. Ужасно. База данных никем толком не контролируется (есть чуть-чуть в flyway и всё), софт не способен работать с базами разных версий.


Рядом есть openstack, который прекрасно умеет работать в режиме sliding window между разными версиями схем базы данных. Насколько я понимаю, у них там sqlalchemy, и там код определяет структуру БД, и код же поддерживает несколько версий схем вместе с точно известным migration path.

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

проблема синхронизации версий клиентской и серверной части всегда может быть и на любом уровне. Тут вопрос в организации тех.процесса — мы например клиентские модули храним в самой БД (динамические библиотеки) и загружаем их при подключении к ней. Там образом не может быть ситуации когда структура БД не синхронизована с клиентской частью, т.к. обновления охватывают сразу и клиентскую часть и серверную. Надо поработать со старой версией БД — берёшь её, а там и клиентские модули старой версии, своместимые с этой версией БД — всё работает. Конкретно в нашем случае нам этого достаточно, не претендую на универсальность.
Что касается темы — то если дальше развивать мысль, то нужно переносить часть бизнес-логики в уровень sql-сервера чтобы обеспечить максимальную производительность работы с большими объёмами данных. Буду с нетерпением ждать продолжения этой битвы ))
Что касается темы — то если дальше развивать мысль, то нужно переносить часть бизнес-логики в уровень sql-сервера чтобы обеспечить максимальную производительность работы с большими объёмами данных. Буду с нетерпением ждать продолжения этой битвы ))

Так все так или иначе часть задач делают с помощью sql. :)))
А те, кто так не делает, рассказывают на хабре, как они героически на сервере с офигенным количеством ядер считают раз в сутки 800 миллионов цифр

Я работаю с java-программистом, который такой подход исповедует.

Вы подход-то не поняли, вот в чём проблема.

Статья на примерах для неких миддлов, то есть знакомых с базовыми принципами, терминологией и имеющим практический опыт людей, поясняет архитектурный принцип, который и на уровне сеньора многие не понимают. То есть недостаточно качественно подан материал. И вообще качественно его подать, это как книгу по высшей математике написать для школьников. Так обычно почти ни у кого не получается. Ну и у автора не получилось.

Автор довольно длинно, из-за желания всё разжевать миддлам (хотя он сам наверняка считает, что пишет для новичков, при этом сам весьма вероятно являясь не очень далёким от миддла разработчиком), наливает много воды, плюс использует лексикон не совсем из той оперы. Например просто глаз режет, когда он заявляет про «истины» которые по его мнению что-то там реализует. Нет на этом уровне никаких истин, есть только удачные или неудачные шаблоны, а новички же, купив рекламируемую книжку, будут считать это именно истиной, чем затуманят свой мозг и накапают на мозги другим разработчикам.

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

К сожалению, массовый рынок образовательных услуг, включая вот такие книжки, получает львиную долю прибыли от начинающих, слегка разбавленных миддлами. Поэтому рынок опускается до уровня молодёжи и выдаёт «священные писания» (вспомним всяких Фаулеров и прочих «святых») в которых сомневаться — страшный грех (ибо мало опыта у читателя, да и продажи ведь упадут!). Ну и далее находится бездна желающих получить гонорар за излияние своего (часто примитивного) видения вот в таком виде, который вроде бы должен объяснять глубины, но на самом деле из-за отсутствия опыта у читателя скорее уводит его от пути действительно истинного.

Поэтому ваш знакомый вами и воспринимается со словами типа «ужасно». Правда как уже отметили выше — это лишь ваше личное восприятие одного единственного случая, из чего вы делаете весьма далеко идущие (и неправильные) обобщения.

И кстати, по разным версиям БД. Вам зачем много версий? Отпускаем резвиться одну команду, которая куролесит свои изменения, внедряет их в отрыве от потребностей всей конторы, потом так же отпускаем другую команду, потом вообще все куролесят что захотят, но зато все героически отстаивают необходимость работы с БД разных версий. Примерно так у вас было? И я вам подскажу — потом каждый выберет свой язык программирования, любимую ОС, тучу вспомогательных инструментов, и всё это заставит изучать толпу тестировщиков, администраторов, технических писателей и прочая, и прочая, и прочая. Верной дорогой идёте, товарищи!

Ох уж обесценили так обесценили. Что ж вы так, раз уж взяли обесценивать, так обесценивайте всё, а то какая-то непонятная неполнота. Ну, другого я от вас и не ждал.


В нашем случае поддержка нескольких версий от приложения требуется для возможности двигать версию приложения не меняя схему базы. Зачем двигать версию приложения? Для откатов. Почему не откатывать версию схемы? Потому что у новой схемы уже есть пользователи.


В openstack же поддержка sliding window сделана для возможности постепенного апгрейда, когда разные сервера работают на разных версиях ПО — и атомарный апгрейд схемы не ломает ничего.

Ох уж обесценили так обесценили

Ну вы что, я лишь прокомментировал :)
В нашем случае поддержка нескольких версий от приложения требуется для возможности двигать версию приложения не меняя схему базы. Зачем двигать версию приложения? Для откатов. Почему не откатывать версию схемы? Потому что у новой схемы уже есть пользователи.

Я не исключаю логичности в ваших действиях, но всё же при смене версии приложения на мобильных устройствах вполне удавалось менять и схему данных. Откатывать же приложение назад не позволяет (по простому), например маркетплейс. Поэтому в итоге все пользователи когда-то обновляются и новая версия меняет схему БД до нужной именно ей. Проблемы возможны разве что с синхронизацией пользователей с разными схемами, но это довольно узкая тема, далеко не всем оно надо. Да и с сервером синхронизация разноверсионных клиентов относительно легко выполняется через диспетчерирующую прокладку.

Если же речь идёт о серверах в различных подразделениях, то обычно обкатывают новое на отдельных подразделениях (поэтапное внедрение, оно важно не только из-за софтовых косяков, но в первую очередь — из-за организационых), если там что-то идёт не так, тогда откатывают и версию БД и версию приложения. Скрипты для этого (в обе стороны) заранее готовят.

Поддержка каких-то промежуточных сочетаний «версия схемы»-«версия ПО» есть задача очень опасная из-за комбинаторного роста сложности. Не знаю, что такое openstack, но комбинаторику он не отменяет никак.

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

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


Насчёт того, что это "так сложно, что комбинаторный взрыв" — в java, может быть. В более приличных ORM'ах (я про sqlalchemy) существует простая полиси добавления, удаления и изменения полей, которая позволяет не плодить комбинаторный взрыв и при этом уметь работать с окне поддерживаемых схем базы данных, причём делать это без героических усилий со стороны программистов.

Вы не поверите, но возможность писать разные части системы под разными ОС, на разных языках с разными базами данных или другими хранилищами считается одним из основных преимуществ сервисной или микросервисной архитектуры

… при этом если они все будут шариться в одной базе, это будет скорее антипаттерн, чем успех.

"с разными базами данных" упустили видимо..

Если мы имеем сервис "со своей базой" то всё хорошо, до тех пор, пока у этого сервиса не появляются rolling updates. Микросервисные товарищи любят приводить в пример "неважные микросервисы" (виджет погоды и т.д.), но есть сервисы важные и ничего с этим не сделаешь. Им нужен высокий аптайм, высокий аптайм означает rolling update или blue-green деплой, причём против одной и той же базы данных (у stateless сервисов без зависимости от данных всё просто, у но где-то по стеку снизу есть кто-то с зависимостью — и мы про него). И тут нам всё равно приходится иметь несколько версий приложения, работающих с одной и той же базой данных.


Либо мы заявляем бизнесу что "так невозможно, и каждую пятницу в 6 вечера мы выключаем google.com на два часа на апдейты" и слушаем реакцию бизнеса на это.

По-моему, ситуации "несколько версий одного приложения/сервиса относительно небольшое время работают с одной базой данных" и "разные приложения/сервисы постоянно работают с одной базой данных" хоть и схожи формально, но практические подходы очень сильно различаются. В посте описана скорее вторая ситуация.

Хорошо написанное приложение эти сценарии не должно различать. Могут быть Большие Причины, почему rolling update может застрять на пол-года в полувыкаченном состояниии. И оно должно продолжать работать не хуже, чем было до начала апгрейда.

А как по мне, то должно. Одно дело, когда базой владеют разные версии одного приложения и база никуда не экспортируется, других клиентов кроме этого приложения у базы нет. И совсем другое, если у базы 100500 "владельцев", и каждое изменение схемы у всех со всеми надо согласовывать. Тут сама база становится приложением/сервисом по сути, а остальные приложения/сервисы её клиенты

Опять громкое название и незаметный дисклеймер в конце статьи. Систему нельзя проектировать исходя из устройства базы данных. Апи к базе данных — возможно.

Мог бы написать множество статей "Почему систему нужно проектировать, исходя из ...", например, "из предметной области", "из сценариев использования", "из требований к стоимости, срокам, окупаемости". И даже все они будут правдивыми, даже если будут противоречить друг другу.


Есть простой принцип: нет единого принципа, применимого во всех ситуациях. Как проектировать систему исходя из устройства базы данных, если на этапе проектирования мы не знаем какая база данных будет нам доступна?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий