Comments 8
2) Open source – это не то решение, которое подойдет для любой компании.
В 99% случаев как раз для любой компании. Вспоминая стоимость коммерческих гигантов (оракл например), вам хватит денег на DBA который в любом случае нужен если проект крупный и даже на внезапную правку базы под ваши нужды если припрет. А сэкономленные деньги можно вложить в бизнес или в обвязку под базу — бэкапы и т.п.
Представим что у вас внезапно закончились деньги на коммерческую поддержку вашей коммерческой базы данных и вы пролетаете мимо патчей.
Современные open source решения баз данных уже давно созрели, надежны и используются в крупных коммерческих проектах (тот же яндекс сьехал с оракла с большим счастьем).
А интеграторы выкатывают красивые графики стоимости владения для финансистов, которые на самом деле является рисованием вилами на воде.
Один из интеграторов напрямую заявляет что решения предлагает напрямую финансистам и не затрагивает ит отдел, который уже узнает по факту от финансистов что «внедряем, это выгодно».
И маркетологи того же оракла и майкрософта понимают момент с их не особой нужностью и рисками распространения и поэтому не закручивают гайки на установку баз данных. Если закрутят — народ живо ломанется на opensource, а так многие пользуются в обход лицензий, привыкают, делают обвязку и потом возможно когда-нибудь уже ее купят.
PostgreSQL, MySQL, MariaDB, MongoDB, SQLite… На рынке очень много вполне готовых и зрелых бесплатных решений, о каких вообще лицензиях на СУБД может идти речь? Могу понять покупку тех. поддержки, но лицензии ни как не вписываются в мое мировозрение.
СУБД не только движок хранения данных. В коммерческих иногда присутствует еще и достаточно мощная IDE/формошлепалка для этой БД (но не всегда)
При всей моей любви и уважению к PostgreSQL и Open Source в целом, PostgreSQL уступает Oracle DB по ряду параметров. Если ваш случай — это хранение пары сотен тысяч строк преимущественно плоских данных, то конечно вы особой разницы не увидите.
У Oracle DB гораздо лучше ситуация с кластеризацией и горизонтальным масштабированием вообще. Если вы используете оракловый стек ПО, то интеграция всего этого добра с базой легче, плюс вы можете получить дополнительные плюшки.
У Oracle DB гораздо лучше ситуация с кластеризацией и горизонтальным масштабированием вообще. Если вы используете оракловый стек ПО, то интеграция всего этого добра с базой легче, плюс вы можете получить дополнительные плюшки.
Если бы при своей цене, Oracle была бы еще и хуже… Хотя, для простых сценариев использование Postgres зачастую оказывается приятнее. Просто потому, что создавалась она гораздо позже и не тащит с собой «исторически сложившееся» наследие из прошлого века.
Вполне возможно, что в каких-то особенных случаях тот же Oracle будет превосходить PostgreSQL, но и Postgres не стоит на месте. А на счет плоских данных, можно же выбрать не только Postgres, хотя и в нем существует поддержка JSON/GIS данных на очень приличном уровне. Да и не одним Posgtres'ом живет мир Open Source.
Из моего опыта, на Oracle пишут полностью бизнес логику приложений, хотя я и приверженец того, чтобы база данных была в основном хранилищем данных, а обрабатывать их стоит на чем-нибудь более специализированным, но вполне понимаю и такой путь. Но как-то не готов платить за лицензию Oracle.
У меня уже был печальный опыт поддержки продукта, основанного на Orcale и с истекшей лицензией на продукт. Поверьте, это очень неприятно, когда нужно исправить продукт под изменившееся законодательство или добавить небольшую фичу, а ты не можешь вообще ничего изменить ни в структуре данных, ни в самом продукте. Приходилось писать костыли, которые могли работать с продуктом только в режиме чтения данных, а если нужно было что-то сохранить, то для этого использовалась уже сторонняя база. Очень часто получалось так, что моя программа что-то вычисляла, о операторы уже вручную вносили необходимы правки через интерфейс продукта, либо мое приложение генерировало готовый отчет.
Второй случай работы с Oracle, когда приходилось часами ожидать отчета от приложения, в котором бизнес логика была написана полностью внутри Oracle, так вот, приложение, написанное на Delphi, считало этот же отчет за минуты, считывая тоже самы данные из Oracle. Я конечно понимаю, что тут дело скорей всего было не в Oracle, а в гениальном умении программиста, криво написавшего процедуры, но осадок все-равно остался.
Так же был и опыт оптимизации кривых процедур написанных для Postgres, но там уже обошелся просто переписываниям самих процедур и все осталось в рамках Postgres.
Из моего опыта, на Oracle пишут полностью бизнес логику приложений, хотя я и приверженец того, чтобы база данных была в основном хранилищем данных, а обрабатывать их стоит на чем-нибудь более специализированным, но вполне понимаю и такой путь. Но как-то не готов платить за лицензию Oracle.
У меня уже был печальный опыт поддержки продукта, основанного на Orcale и с истекшей лицензией на продукт. Поверьте, это очень неприятно, когда нужно исправить продукт под изменившееся законодательство или добавить небольшую фичу, а ты не можешь вообще ничего изменить ни в структуре данных, ни в самом продукте. Приходилось писать костыли, которые могли работать с продуктом только в режиме чтения данных, а если нужно было что-то сохранить, то для этого использовалась уже сторонняя база. Очень часто получалось так, что моя программа что-то вычисляла, о операторы уже вручную вносили необходимы правки через интерфейс продукта, либо мое приложение генерировало готовый отчет.
Второй случай работы с Oracle, когда приходилось часами ожидать отчета от приложения, в котором бизнес логика была написана полностью внутри Oracle, так вот, приложение, написанное на Delphi, считало этот же отчет за минуты, считывая тоже самы данные из Oracle. Я конечно понимаю, что тут дело скорей всего было не в Oracle, а в гениальном умении программиста, криво написавшего процедуры, но осадок все-равно остался.
Так же был и опыт оптимизации кривых процедур написанных для Postgres, но там уже обошелся просто переписываниям самих процедур и все осталось в рамках Postgres.
Напишу я о своих ощущениях, которые, в общем, ничем не могу доказать.
Если речь идёт о небольших объёмах данных — таблицы в сотни тысяч или несколько миллионов записей (и их, грубо говоря, не очень много, хотя на самом деле критерий значительно сложнее), то я бы стал смотреть в сторону MySQL или Postgres, причем не отдельно на сервере или кластере, а в облаке — AWS, GCP… — как управляемая услуга.
Если данных действительно много — Redshift AWS, BigQuery GCP.
Если нужно для операционной работы, а не отчётов — Spanner. Но тут нужно иметь много денег.
Еще есть много всяких разных GCP — BigTable, DataStore — но это несколько другая история…
И как бы не остаётся широкой ниши для Oracle. Хотя работать с ним, разрабатывать под него очень приятно. А может просто более привычно. В итоге появляется ниша для продуктов типа DBVisit, Attunity Replicate и так далее — которые позволяют сползти с Oracle с минимальными осложнениями, и не очень торопясь…
Если речь идёт о небольших объёмах данных — таблицы в сотни тысяч или несколько миллионов записей (и их, грубо говоря, не очень много, хотя на самом деле критерий значительно сложнее), то я бы стал смотреть в сторону MySQL или Postgres, причем не отдельно на сервере или кластере, а в облаке — AWS, GCP… — как управляемая услуга.
Если данных действительно много — Redshift AWS, BigQuery GCP.
Если нужно для операционной работы, а не отчётов — Spanner. Но тут нужно иметь много денег.
Еще есть много всяких разных GCP — BigTable, DataStore — но это несколько другая история…
И как бы не остаётся широкой ниши для Oracle. Хотя работать с ним, разрабатывать под него очень приятно. А может просто более привычно. В итоге появляется ниша для продуктов типа DBVisit, Attunity Replicate и так далее — которые позволяют сползти с Oracle с минимальными осложнениями, и не очень торопясь…
Sign up to leave a comment.
Плачу и плачу: Как не переплачивать за лицензии на СУБД?