metaclass (metaclass) wrote,
metaclass
metaclass

Попробую объяснить еще раз

Мне регулярно дают советы "перейти на postgresql" или "перейти на оракл" или "поставить кафку/кролика/activemq" и прочее такое.
Советы эти (особенно первый), вообще говоря - правильные. Если бы речь шла о разработке продуктов с нуля и если бы не существовало уже использующихся сотен инсталляций этих продуктов.

На данный момент, реализация любого из этих советов означает следующее:
1) Выкинуть 70% кода продуктов и писать их заново. По той причине, что большая часть бизнес-логики реализована на SQL или связана с ней.
2) Отложить проект который надо сдать в этом году еще на год.
3) Переучить заново 5 человек, которые за 7 лет хоть как-то осилили тонкости работы с Firebird, т.е. разработка и обслуживание.
4) Переписать все внутренние сервисные инструменты - обновление, бэкапы, мониторинг жизнеспособности серверов и прочее такое.
5) Сделать автоматический мигратор баз данных размерами по 10-50 гиг из одной БД в другую.
6) Некоторым из клиентов придется помогать переделывать интеграцию их внутреннего софта, который забирает данные из нашей БД.

Это имеет смысл делать в таком виде только в том случае, если оно принесет заметное упрощение работы или стабильно увеличит доходы. Ни того ни другого на данный момент оно не даст.

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

Возможности же клиентов в плане железа и инфраструктуры в РБ нередко ограничены, т.к. в стране нет бабла. Поэтому коммерческие софты или софты, рассчитанные на тяжелое железо, тут не всегда пригодны.
Отдавать же клиентов конкурентам, очевидно, смысла нет, т.к. тут работает нелинейный эффект - чем больше клиентов у одного поставщика, тем более вероятность, что следующие клиенты придут к нему же.


PS: И еще одна, чисто техническая, тонкость: использовать в качестве ядра проекта(хранилище, конфигурация, IPC, очереди, итд) реляционные СУБД это практически идеальный вариант до какого-то уровня нагрузки, потому что все остальное по сравнению с БД нихера не умеет и отказаться от СУБД - это фактически закат солнца вручную.
Но есть некоторые куски задач, которые лучше укладываются в полноценные очереди, in-memory хранилища и прочую хипсторятину. Но пользоваться оными - боль, потому что хипсторы плохо умеют в математику и в процессе отрицания реляционных моделей углубляются в злые костыли.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 46 comments