С реляционными базами данных я знаком очень давно, с конца 90-х. Мои первые шаги в мире компьютеров и программирования связанны именно с ними. Реляционным БД было отведено особое место в моей образовательной программе и стажировке на инженера-программиста. Они преследовали меня на протяжении всей моей карьеры. Я буквально провалился на самое дно кроличьей норы реляционных систем управления базами данных (РСУБД) – и до сих пор люблю их.
За годы работы я испробовал практически все РСУБД, а их попадалось мне немало: MySQL, Postgres, Oracle, Microsoft SQL Server, DBase, Access, SQLite, DB2, MariaDB, AWS RDS, Azure SQL, Google Cloud SQL. Нельзя любить РСУБД, если не любишь SQL, а это отдельная вселенная. И не все SQL одинаковы. Есть MySQL со своим собственным жаргоном, есть T-SQL от Microsoft и всемирно известный PL/SQL от Oracle. Наверное, не стоит упоминать, что все они несовместимы друг с другом.
Реляционные базы данных: они повсюду
Поверьте, они поистине вездесущи: финансы, транспорт, гостиничный бизнес, соцсети, стриминговые сервисы и т.д. Какую сферу ни возьми, обязательно наткнешься на реляционную базу данных. Кажется, весь мир только на них и работает, наполняя карманы в первую очередь Oracle, IBM и Microsoft. Если вам нужно что-то большое, прямо-таки огромное, вы обратитесь именно к ним. Разве что в финансовом секторе ваши специфические запросы могут привести вас к SAP. И так было во все времена.
Считается, что первые РСУБД появились еще в начале 1970-х гг., когда был изобретен «структурированный английский язык запросов» (SEQUEL, позже сокращенный до SQL). В 1979 г. Oracle выпустила свою первую базу данных, а за три года до этого, в 1976 г., компания Honeywell представила Multics Relational Data Store. Считается, что это была первая в мире реляционная база данных. Не за горами 50-летие РСУБД как явления. Неудивительно, что они стали основой современного общества и экономики. Буквально каждый человек, если только он не живет в лесу, засветился хотя бы в одной базе данных.
Данные социального страхования, паспорт, полицейские записи, свидетельства о рождении – все это прекрасно хранится в массивных государственных реляционных базах данных, скорее всего, от Microsoft, IBM, SAP или Oracle. Хотите в отпуск? Билеты, брони – все находится в реляционных базах данных. Любая информация, переданная любой большой компании, вероятнее всего окажется в реляционной базе данных.
Большинство реализаций БД просты
Самые популярные СУБД в мире — это MySQL для PHP-приложений и Microsoft Access для VBA. Как правило, речь идет о скромных приложениях, которые используют БД для хранения своих данных. Для многих из них РСУБД – непомерное излишество. Но популярность реляционных баз данных заставила разработчиков их использовать. Университеты, школы, курсы программирования – везде изучают SQL и РСУБД. И большинство разработчиков имеют склонность использовать реляционные базы данных.
На примере этих баз данных видно, что основная масса разработчиков программного обеспечения не являются хорошими спецами по БД. Чаще всего это происходит из-за некомпетентности, вызванной тем, что на свете не так много качественных обучающих ресурсов по грамотной реализации реляционных баз данных. Большинство университетов, школ, книг и курсов сосредоточены на SQL, нормализации и транзакциях.
«Приложение вообще не должно знать, что у него есть таблицы» – опытный администратор БД, ушедший на пенсию в 2012 г. и пожелавший остаться неизвестным.
Среднестатистический разработчик будет шокирован этим заявлением. А для опытных инженеров баз данных считается нормой прятать всю структуру БД за представлениями и хранимыми процедурами.
Монструозные базы данных стали незаменимы
В 1980-х гг. уже все организации перешли на реляционные базы данных. Под «всеми» я действительно имею в виду «всех». Возможно, если достаточно долго искать, найдется какая-нибудь правительственная компания, которая их не использует. Но там, скорее всего, и не будет современных компьютеров. Часто такие организации используют базы данных, созданные на заказ. Десятилетиями они крутятся на мэйнфреймах, наращивая объем данных и требуя дорогой поддержки со стороны производителей или поставщиков.
Эти кастомные базы данных содержат десятки связанных таблиц, невидимых для внешнего мира. Бесконечное количество триггеров, функций, процедур и представлений должны не просто организовывать хранение данных, но и осуществлять все бизнес-процессы компании. Приложения на прикладном уровне обеспечивают интерфейс для работы обычного пользователя с базой данных.
Поскольку специалисты по базам данных из 80-х ушли на пенсию еще несколько десятилетий назад, большинство из созданных ими на заказ систем так и живут, управляемые SQL-приложениями, которые в массе своей уже не поддерживаются. Для многих крупных организаций эти приложения превратились в эдакие «черные ящики». Совершенно не понятно, что они делают и как именно работают, не говоря уже о том, как их следует обслуживать. Тем не менее предприятия чрезвычайно зависят от этих приложений. Реверс-инжиниринг и тотальная переделка архитектуры – единственный выход из этой ситуации. Проекты по переносу легаси-БД часто обходятся в нелепо большие суммы, исчисляемые несколькими миллионами долларов.
Представьте себе страховую компанию, которая не понимает, как на их мэйнфрейме рассчитывается степень риска по договорам. Они даже не в курсе, какой будет страховая премия по конкретному страховому случаю. От осознания количества организаций, которые не имеют ни малейшего представления о том, как программное обеспечение управляет их бизнесом, становится и смешно, и страшно одновременно. Особенно дико, когда ты и есть клиент, чьи данные хранятся в подобном «черном ящике».
В чем проблема реляционных баз данных?
Я лично сталкивался с компаниями, где каждый запрос на изменение, затрагивающее централизованную реляционную базу данных, становился задачей всего ИТ-отдела не на пару дней, а на долгие месяцы. Крайними при этом выставлялись или Oracle, или DB2. Централизованная база данных превратилась в единую точку отказа. Маркетинговые акции останавливались, когда база данных вдруг переставала работать, а успешное добавление столбца в таблицу требовало вознесения регулярных молитв. О производительности запросов вообще лучше промолчать.
В чем проблема? Сами принципы построения РСУБД подталкивают к централизации данных внутри этой базы. База данных растет вместе с бизнесом, но вместе с тем увеличивается объем «мусорных» данных. В конце концов бизнес будет экономически неспособен отойти от реляционной базы данных.
Можно бесконечно цитировать сообщения СМИ о том, как реляционные базы данных разрушили бизнес или сломали привычный ход вещей. Велика новость!
Вот несколько примеров.
«Внезапный сбой в работе системы бронирования авиабилетов», 2000 г. (Airline Reservation System Crashes Briefly);
«Почему компьютерные системы авиакомпаний так часто выходят из строя?», 2016 г. (Why airlines' computer systems crashs so often);
«Постыдный секрет: что стоит за масштабным сбоем в компьютерной системе Southwest Airlines?», 2022г. (The Shameful Open Secret Behind Southwest's Failure).
«TSB Bank оштрафовали почти на 50 млн. фунтов стерлингов после неудачной модернизации компьютера», 2018 г. (TSB Bank fined nearly £50m after botched computer upgrade).
«6 лет, 60 млн. евро – 0 результата. Как биржа труда осталась без программного обеспечения», 2017 г. (Six years, 60 million euros – but no software for the employment agency).
Реляционные базы данных из прошлого
РСУБД были изобретены в ту эпоху, когда компьютеры выглядели совсем иначе. Сферы их использования были совершенно другими, а объем данных, с которым приходилось иметь дело этим системам, сегодня уместится в любом смартфоне.
Настоятельно рекомендую ознакомиться с работами Рика Хулихана, его презентациями о базах данных и размышлениями о будущем этой технологи. Обязательно стоит поискать видео с ним на YouTube: Rick Houlihan on YouTube. Ниже я приведу фрагмент интервью, которое он дал журналу Software Engineering Daily.
Джефф Мейерсон (основатель Software Engineering Daily):
Существует несколько объяснений того, почему NoSQL обрел популярность в самый расцвет SQL. Мы рассматривали некоторые из этих теорий в наших выпусках. Расскажи нам свою версию истории популярности NoSQL.
Рик Хулихан (MongoDB, бывший сотрудник AWS):
С удовольствием. На самом деле все сводится к тому, что, когда люди начали обрабатывать большие объемы данных, оказалось, что реляционные базы данных, которыми они пользовались столько лет, не так хорошо масштабируются. Это перекликается с тем, почему были изобретены реляционные базы данных: объем данных рос, стоимость обработки данных от него не отставала и мешала развиваться. РСУБД уменьшали давление на системы хранения, потому что нормализация позволяла дедуплицировать данные и таким образом освободить, так сказать, хранилище – а это было действительно самым дорогим ресурсом в дата центрах еще 3-4 года назад.
Но время летит, и теперь мы платим сущие копейки за гигабайты хранилища и время работы процессора. Теперь процессор – не просто фиксированный актив, которому простительно работать вхолостую. Это ценный ресурс, который мы можем использовать для других задач. Так что объединение данных и выполнение сложных запросов – это не то, на что мы хотели бы тратить свои деньги.
Во многих случаях, таких как стриминг, игры, соцсети, поиск в Интернете и др., нужны не согласованность и атомарность, а скорость и производительность.
Поисковой системе не нужно выдавать каждому пользователю свежайшие результаты. Плюс, нужна индивидуальная выдача с учетом истории, интересов и т.п. Следовательно, требования ACID здесь совершенно не актуальны. Никто в здравом уме не станет использовать РСУБД для крупного интернет-поисковика или социальной сети.
Каково решение? Специализированные системы
Очевидно, что некая база данных общего назначения, «для всех», вряд ли станет успешной. Попытка использовать РСУБД для транзакций, поиска, аналитики, скорее всего, никогда не даст оптимального результата. Тут уже и ежу станет понятно, что необходимы специализированные решения. Это могут быть даже базы данных, и даже реляционные, но помимо них требуются и особые системы узкого назначения.
Подход с использованием специально созданных систем управления данными работает только если придерживаться микросервисной архитектуры и избегать создания «микросервисных монолитов». Часто можно встретить микросервисную архитектуру, работающую в паре с монолитными базами данных, что делает микросервисный подход совершенно бесполезным.
Базы данных: объектно- и документно-ориентированные, «ключ-значение»
В первую очередь для хранения данных следует выбирать из основных вариантов key-value, таких как приложения Apache Cassandra, AWS DynamoDB, Google Cloud Spanner или Azure Cosmos DB. Они легко масштабируются, долговечны, просты и подходят для всех базовых сценариев использования, где нужно просто разместить данные и получить к ним доступ с помощью нескольких ключей.
Если работа с данными требует выполнения сложных запросов, например, поисковых или аналитических, всегда можно перейти на специализированную поисковую или аналитическую систему, передав данные из своего хранилища в другую систему. Если вообще не нужны запросы и требуется просто хранить данные, то оптимальным вариантом будет использование объектно-ориентированной БД, например, AWS S3, Azure Blob Storage или Google Cloud Storage.
Документно-ориентированные базы данных, такие как MongoDB или AWS DocumentDB, пытаются стать альтернативой реляционным базам данных, хотя зачастую они работают по тем же принципам. Несмотря на переход от таблиц к документам, можно столкнуться с теми же самыми проблемами.
Специализированные или кастомные поисковые системы
Распространенным вариантом использования реляционных баз данных является поиск. Правда, для этого варианта использования реляционные базы данных далеко не идеальны. Поисковый функционал в большинстве случаев вообще не требует соблюдения требований ACID. Специально построенные поисковые системы, такие как Lucene, Solr, OpenSearch или ElasticSearch, обеспечивают значительно большую производительность и дешевле в эксплуатации. Кому-то могут подойти и уже существующие предложения от облачных провайдеров, например, Google Cloud Search.
Если ничего из этого не подходит под ваши требования, значит, нужно создать свое специализированное программное обеспечение. Учитывая скорость разработки, доступную с такими языками, как Go, это уже не выглядит так страшно. Безусловно, стоит подумать о последствиях своего выбора.
Транзакционные базы данных или блокчейн
Обработка транзакций – вотчина реляционных баз данных. Но сейчас их потеснили системы баз данных на основе блокчейна, например, Amazon QLDB.
Я сам развернул Amazon QLDB в продакшн и уже не хочу возвращаться к реляционным базам данных. Преимущества криптографически проверяемого хранилища для транзакций позволяют добиться гораздо большей проверяемости. Для обработки финансовых транзакций QLDB, на мой взгляд, – оптимальный вариант. Однако все зависит от сценария использования, быть может вам вообще не нужна никакая криптографическая проверка.
Бросая вызов статус-кво
Мне нравится писать на SQL ????️ с его хранимыми процедурами, функциями, триггерами и представлениями. Проектирование реляционных баз данных в MySQL Workbench доставляет мне огромное удовольствие. Новейшие возможности MySQL 8 – это что-то потрясающее. В реляционных базах данных можно сделать очень многое – и все это в едином пространстве. Честно говоря, я иногда скучаю по временам, когда можно было просто написать все свое бизнес-приложение в MySQL, Oracle или SQL Server. Но я должен быть честен с самим собой: это было приемлемо в 80-е, но не теперь. Мы живем в 2023-ем, вычислительные системы и системы хранения данных изменились, как и дата-центры и приложения.
Вместе с появлением огромного разнообразия в области СУБД, хранилищ, технологий поиска и языков программирования прошли те времена, когда ты десятилетиями носился с одной и той же базой данных. Больше не будет бесконечных споров о том, что выбрать: MySQL, MSSQL, Oracle или Postgres. Сегодня вопрос о базах данных и хранилищах решается индивидуально. И вот уже я сам пишу небольшие пользовательские стратегии хранения данных, основанные на объектных хранилищах или хранилищах «ключ-значение».
Сегодня, прежде чем внедрить программу или систему, я думаю о том, какие данные будут храниться и как к ним будет осуществляться доступ. Затем я трачу многие часы на поиск правильного подхода к хранению данных. И если честно, реляционные БД я выбираю редко. Слишком уж часто я видел, к чему приводит долгосрочное использование централизованных реляционных баз данных.
Комментарии (41)
saboteur_kiev
10.10.2023 23:47+11самая лучшая sql база - sqlite, идеальная для мелких вещей, скриптов и так далее, что не планируется сильно масштабироваться.
me21
10.10.2023 23:47Поддерживаю. У меня в неё складываются результаты измерений в одной управляющей плате, делающей одну глупую железку - умной.
И ещё одно локальное веб-приложение на ней бегает.
Удобно, разворачивать намного проще, чем клиент-серверные СУБД.
MAXH0
10.10.2023 23:47+2Вы подразумеваете, что если не укладываешься в sqlite по размеру, то современным верным решением будет отказаться от SQL в пользу чего-то нового?
saboteur_kiev
10.10.2023 23:47+4Я подразумеваю, что идея sqlite - божественна, ибо не требует запуска отдельного сервиса-базы-данных, чем сейчас страдает множество людей, когда для хранения пары килобайт данных запускают отдельную базу, для нее ставят докер, для него ставят какой-нить оркестратор и считают что они сэкономили на настройке инфраструктуры, потому что она занимает пару строк в хелм чарте.
А под капотом потрачено дохрена лишних мегабайт и гигабайт данных как в оперативке, так и на диске.
Вместо пары килобайт .cvs или .db sqlite файла.
p.s. я отлично понимаю, что доступ к файлу лочит файл, и в случае масштабируемости, это не то. Я именно про простые вещи, которые усложнятели превращают в бред
TimsTims
10.10.2023 23:47С какого количества МБ нужно начинать задумываться о смене sqlite?
Pinkbyte
10.10.2023 23:47+1Тут скорее надо задавать вопрос о конкурентном доступе на запись - у sqlite с этим в силу архитектуры не может быть хорошо. Но для ситуации - "1 клиент в 1 базу данных" sqlite перебить чем-то сложно
saboteur_kiev
10.10.2023 23:47С какого количества МБ нужно начинать задумываться о смене sqlite?
Я думаю где-то в районе лимита максимального размера файла для вашей файловой системы.
Дело же не в размере базы данных, а в том что и кто с ней делает.
Если нужно параллельный доступ нескольким процессом, то сразу.
Если перформанс - не факт, что просто смена одной базы на другую возьмет и перформанс поменяет само по себе. sqlite вполне себе быстрый.
Вот то, что другую базу, со своим сервером можно поставить на другую машину - это простой способ распределить нагрузку на CPU/memory, но это очевидно.
Vindicar
10.10.2023 23:47+2Ровно до тех пор, пока не появляется необходимость обращаться к ней из двух процессов одновременно (скажем, по крону и по запросу пользователя). Сценарий, увы, не такой уж редкий - даже в малых проектах.
aleks_raiden
10.10.2023 23:47-1Это вполне работает, если использовать WAL, в крайнем случае можно сделать самому через процесс-координатор
Vindicar
10.10.2023 23:47+4сделать самому через процесс-координатор
Ну это вариант, но по сути, это уже будет СУБД сервер, только маленький и самодельный . =)
pavelsc
10.10.2023 23:47+3Ну придется развернуть в Minikube какую-нибудь систему очередей RabbitMicro или NanoKafka.
Это ирония и стёб если что. SQLite чисто для десктоп или мобайл приложений, не больше
jobber_man
10.10.2023 23:47+1Ирония в том, что изначально SQLite разрабатывалась для весьма серьезных задач, для управления конфигурацией эскадренных миноносцев.
Для случаев, когда запись редка, особенно конкурентная, а чтений много и объем данных относительно небольшой, SQLite неплохо справляется. Например, для каких-нибудь развесистых конфигов.
saboteur_kiev
10.10.2023 23:47Это ирония и стёб если что. SQLite чисто для десктоп или мобайл приложений, не больше
Вы видимо плохо представляете себе варианты использования и ваше понимание "очень серьезных приложений" не совсем верное.
PastorGL
10.10.2023 23:47+16Какой-то странный у автора взгляд. SQL != RDBMS уж тыщу лет как, и даже NoSQL хранилища мутировали в NewSQL.
Эх, жаль оригинал за пэйволом, а то б неплохо было потыкать его на предмет а чё ж он сказать-то хотел.
Kwisatz
10.10.2023 23:47+10Тоже не понял. Тезис "я видел плохо спроектированные бд, поэтому они зло" как то слабоват и тем более не увидел ответа, почему же смена типа базы данных от этого избавит.
igor_suhorukov
10.10.2023 23:47Согласен! Раньше все гордились отсутсвием SQL в очередной базе данных, но рынок и предпочтения разработчиков расставили все по местам. Декларативность VS Императивность запросов, стоимость поддержки кода запросов/разработки новой функциональности в проекте, количества людей на рынке с нужными знаниями.
kinall
10.10.2023 23:47+4За годы работы я испробовал практически все РСУБД, а их попадалось мне немало
Просто наблюдение: если в первых же строках статьи есть упоминание о долгой кропотливой работе, то 99%, что наверху стоит плашка "Перевод". Хм.
dyadyaSerezha
10.10.2023 23:47+8Очень спорная статья.
И не все SQL одинаковы
В типа, все NoSQL одинаковы и совместимы друг с другом. Бред.
Не понял кол-во процентов в первой табличкиюе распространения БД. Там какие цифры по Y внизу и вверху?
Про заказнын БД - дорогая поддержка "после официальной поддержи", это верно вообще для любых заказных решений. БД тут вовсе не исключение, а правило.
Мало кто мог мог правильно проектировать крупные сложные системы на десятилетия. Никак не связано в БД.
Можно бесконечно цитировать сообщения СМИ о том, как реляционные базы данных разрушили бизнес
Можно так же бесконечно цитировать сбои по любым другим причинам.
и теперь мы платим сущие копейки за гигабайты хранилища и время работы процессора. Теперь процессор – не просто фиксированный актив, которому простительно работать вхолостую. Это ценный ресурс
Противоречие внутри одной мысли (левый перевод?) в начале - копейки за время CPU, а сразу следом - ценный ресурс.
Итого - теперь разных БД много и для каждой задачи лучше какая-то БД из множества предложений.
IvanGo82
10.10.2023 23:47Этот человек явно не понимает что он пишет. без субд сей час ни куда. что бы ты не делал для работы с данными ты сделаешь субд.
Mapar
10.10.2023 23:47+1Мне кажется, что автор скорее критикует монолит, чем базы за ним.
Отдельная история, что говоря о новомодных базах, автор опускает тему надежности.
gybson_63
10.10.2023 23:47+2"Реляционные системы управления базами данных" =))) Прям с самого начала не задался перевод. Это БД реляционные, а не системы управления.
pfffffffffffff
10.10.2023 23:47Странно, а я часто видел аббревиатуру РСУБД
gybson_63
10.10.2023 23:47+1В оригинале это "relational database management system". Но Вы правы
Довольно часто пишут странную, но устоявшуюся конструкцию "Реляционная СУБД (или РСУБД) - система управления реляционными БД".
Вот даже у MS
Что такое система управления реляционной базой данных? | Microsoft Azure
"Что такое реляционная система управления базами данных?
Системы управления реляционных баз данных помогают управлять данными масштабируемым способом."Опять же смотришь статью на английском, там будет "An object–relational database (ORD), or object–relational database management system (ORDBMS)", а на русском будет перевод в лоб "Объектно-реляционная СУБД".
Бесит =)
akardapolov
10.10.2023 23:47-4Проблема реляционных баз данных - плохая горизонтальная масштабируемость и дороговизна. Такие монолиты-комбайны, когда все в одном и работает на сервере-мэйнфрейме.
Собственно поэтому и возник NoSql, как решение проблемы, со своими ограничениями (CAP теорема). Пример - MongoDB который хорошо работал с большими объемами данных.
Потом появились системы которые закрывали задачи, например по обработке данных в памяти, In-memory базы данных, для решения задач кэширования данных, Redis.
Для полнотекстового поиска ElasticSearch, и его конкуренты. Для аналитической обработки ClickHouse, для обмена сообщений RabbitMQ и Kafka. Это все NoSql и есть, но не в части хранения данных, а их обработки. Произошел такой распил монолита функциональности классических RDMBS.
Сейчас видно что архитектурно RDBMS из топа списка не могут предложить масштабируемую конфигурацию за вменяемые деньги. Появляются системы NewSql, YaDb как пример - заявляет поддержку транзакций, аналитической и потоковой обработки и это все на commodity hardware с горизонтальной масштабируемостью.
Ant80
10.10.2023 23:47+3ИМХО на начальном этапе развития большинства проектов реляционные базы - решение по умолчанию в силу универсальности и распространённости. дальше уже можно искать пути оптимизации, если надо. а сложная бизнес-логика + десятилетия легаси без рефакторинга создадут проблемы хоть с реляционной базой, хоть с чем угодно.
duke_alba
10.10.2023 23:47+1В общем, гвозди надо забивать молотком, а вытаскивать клещами, и никак не наоборот. Да, согласен. :-)
Batalmv
10.10.2023 23:47+5Какой-то набор лозунгов на пол статьи. Все плохо, потому что плохо. Поэтому давайте так не делать.
В итоге:
Если кто-то сделал из базы single point of failure - дело не во внутренностях базы. Просто так сделали :)
Если кто-то не может неделю поменять что-то в базе - проблема скорее в долгой истории, и отчасти в ДНК конкретных людей
блокчейн спасет мир "транзакций", при этом упор не на транзакционность (я допускаю, что автор просто увлекся и забыл не мгновение, что такое транзакция), а на проверяемость.
В реале же, каждой базе свою нишу и назначение. Да, сейчас есть много вариантов и это круто. Очень много. Облака дают возможность реально каждому сервису выдать наилучшую БД, в теории.
На практике все проще.
Многие задачи не настолько эпичны, чтобы реально париться границами возможного для отдельно взятой платформы. Я б даже сказал - почти все.
Для многих задач точно важно время и стоимость разработки решения, а тащить в проект кучу технологий только потому, что она в теории лучше где-то там - значит потратить кучу времени, чтобы научить людей с ними работать. Я прям себе представляю, мы начинаем что-то писать, и тут я говорю - у нас будет 5 разных баз. Команда может не понять и собравшись на сходку, вернуться с "черной" меткой :)
Многие узкоспециализированные базы на то и узко-специализированные, а потому смотри предыдущие пункты
---------------
То, что реально важно:
стоимость, и только в случае, если реально разница существенна. Рубиться за 10 ... 100 ... (возможно) 1000 долларов в месяц - вообще не имеет смысла
минимизация зоопарка, так как накладные расходы на его поддержку будут точно велики
---------------
По статье, мне кажется автор взял слишком серьезный фокус "реляционные базы - отстой", хотя в реале просто есть много нишевых альтернатив
MaxKitsch
10.10.2023 23:47Есть мысль, что автор попутал transaction, в смысле «банковский перевод» и transaction в смысле «атомарная операция»
SSukharev
10.10.2023 23:47+3Боже мой, какой феерический поток бредовых мыслей.
Akina
10.10.2023 23:47Вот тоже - читал, и с самого начала никак не мог отделаться от мысли "Ну что за бред!". По стилю и даже по содержанию то ли заказуха, то ли просто для "плюсадин" в публикации. Подходящее? берём. Не подходящее? не упоминаем. Более-менее подходящее? описываем только то, что подходит. Вообще не по делу, но похожее? притянем за уши, авось не оторвутся.
Имхо не надо было переводить.. не стоило оно того.
vagon333
10.10.2023 23:47В первую очередь для хранения данных следует выбирать из основных вариантов key-value, таких как приложения Apache Cassandra, AWS DynamoDB, Google Cloud Spanner или Azure Cosmos DB. Они легко масштабируются, долговечны ...
Из 4х баз приведены 3 облачные базы.
Облачные базы и долговечность противоречат друг-другу.
Долговечность требует предсказуемость и полный контроль.
А когда cloud provider deprecate services (Google), то в здравом уме я не построю продукт, основанный на облачных базах.
olku
10.10.2023 23:47Автору, похоже, так и не удалось разобраться в вопросе. Мешанина какая-то, приправленная лозунгами. Даже OpenSearch с ElasticSearch и библиотека Lucene указаны раздельно.
kaichou
10.10.2023 23:47Реляционные системы управления базами данных становятся проблемой. Что с этим делать?
Перестать писать идиотские заголовки и понять, что для каждой задачи нужен свой инструмент.
Если для каких-то задач РСУБД подходят не очень, это не значит, что они являются проблемой.
gybson_63
10.10.2023 23:47"База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)[5]"
База данных — Википедия (wikipedia.org)
Не подходит вам реляционная модель данных и ради Бога. Вот вам файловая система, википедия и миллион других способов организовать данные. Вы главное определитесь для чего. Что мы должны получить, за какое время, какие требования к хранению и т.д. и т.п. Самая популярная БД это Excel, наверное до сих пор. С сомнительной реляционностью. Вставил картинку в таблицу и вот тебе уже объектно-ориентированный nosql =)
Git, кстати, хорошая БД для своих целей.
asatost
10.10.2023 23:47Поскольку специалисты по базам данных из 80-х ушли на пенсию еще несколько десятилетий назад, большинство из созданных ими на заказ систем так и живут, управляемые SQL-приложениями, которые в массе своей уже не поддерживаются. Для многих крупных организаций эти приложения превратились в эдакие «черные ящики».
Т.е. автор хочет сказать, что проблема РСУБД - в высокой надёжности и квалификации разработчиков? Такой, что построенное может работать десятилетиями без вмешательства человека вообще?!
И это РСУБД захватили руководство компанией и разработали процедуру увольнения сотрудников без какой-либо их замены? Слава
роботамреляционным базам данных!
pavelsc
10.10.2023 23:47+1>Среднестатистический разработчик будет шокирован этим заявлением. А для опытных инженеров баз данных считается нормой прятать всю структуру БД за представлениями и хранимыми процедурами.
Это зависит не от способностей разработчика. Есть бигтех и есть все остальное. Во всем остальном нет таких вакансий как разработчик БД, а в бигтех тебе даже простой селект запрос помимо хранимых функций не дадут вкорячить, не спустив по регламенту через отдел БДшников и не получив аппрув.
Добиться плохой работы приложения на Oracle или Postgres при грамотной инфраструктуре довольно сложно. Как правило проблемы начинаются на аналитических запросах при паре терабайт записи на таблицу в месяц. Тогда берут другой тип БД, который заточен на чтение, и может даже не иметь update функционала в себе, т.к. это вызовет тяжёлые процедуры перестроения индекса, и подключают готовые CDC решения к журналу. SQL прекрасен и для большинства ситуаций его с избытком. Проблема проявляется исключительно при гигантских объемах генерируемых пользователями данных. А так даже огромный маркетплейс уютно будет себя чувствовать с SQL решениями.
Fafhrd
10.10.2023 23:47+1Ой, а у нас свалила команда, разрабатывавшая микросервис по расчёту бонусов. Они использовали потрясающие современные средства: язык малбогл, перпендикулярно-ориентированную ropesoapdb и протокол nanobin с патчами от beegle&bugle. Всё так здорово, что полтора года не можем найти новую команду с этими компетенциями.
glazko
10.10.2023 23:47Рекомендую по теме статью «Вьетная компьютерной науки, Тед Ньюард, 2006».
Получается что даже с появлением NoSQL глобально ничего не изменилось и РСУБД продолжают доминировать. Думаю что в ближайшие 20 лет тоже мало что изменится, потому что архитектура РСУБД гораздо ближе к архитектуре ЭВМ
glazko
10.10.2023 23:47Рекомендую по теме статью «Вьетная компьютерной науки, Тед Ньюард, 2006».
Получается что даже с появлением NoSQL глобально ничего не изменилось и РСУБД продолжают доминировать. Думаю что в ближайшие 20 лет тоже мало что изменится, потому что архитектура РСУБД гораздо ближе к архитектуре ЭВМ
denis-isaev
MSSQL для C#, а Oracle для JavaScript :)