[3/3] What Goes Around Comes Around... And Around... (Рубрика Data)

В продолжение рассказа (1 и 2) про эту статью 2024 стоит закончить про разные подходы к системной архитектуре, а дальше рассказать про прощальные комментарии авторов, что повторяют частично предостережения из 2005 годов, когда вышла первая статья "What Goes Around Comes Around"

Архитектуры 5. Аппаратные ускорители Этот подход предполагает использование специализированного оборудования (например, GPU или FPGA) для ускорения выполнения запросов. Подход выглядит работоспособным только для cloud вендоров из-за стоимости разработки кастомного железа и написания кастомного софта. Кроме того, обычно это не дает кратного роста эффективности. 6. Базы данных на основе блокчейна Блокчейн обещал гарантии неизменяемости данных и прозрачности транзакций. Но такие системы остаются нишевыми из-за ограничений производительности и сложности интеграции с традиционными приложениями.

Выводы относительно архитектур баз данных Авторы статьи отмечают, что многие из этих архитектур либо заняли нишевые рынки, либо постепенно интегрируются в реляционные СУБД

• Колоночные системы теперь являются стандартом для аналитики.
• Облачные базы данных доминируют благодаря удобству управления.
• NewSQL-системы становятся мостом между традиционными реляционными базами и масштабируемыми NoSQL-подходами.
• Эти изменения демонстрируют адаптацию СУБД к современным требованиям приложений и аппаратным инновациям.

Прощальные комментарии - Никогда не недооценивайте значение хорошего маркетинга для плохих продуктов: как было с Oracle в 1980х, MySQL в 2000х, MongoDB в 2010х:) Последние 2 примера я видел своими глазами - Опасайтесь DBMSs от крупных вендоров не из рынка DBMS. Крупные технологические компании часто пишут свои базы данных in-house, а дальше отпускают их на волю (в мир open source). У некоторых bigtech компаний так получаются крутые продукты: Apache Hive, Presto, Apache Cassandra, RocksDB или Apache Kafka, Apache Pinot, Voldemort, а у других нет. Авторы делают предположение, что система промоушенов внутри таких компаний приветствует создание новых технологий внутри, а не использование готовых инструментов. Так на свет появляется куча уродцев от команд, которые не имеют опыта в создании баз данных - Не игнорируйте первое впечатление пользователя при с вашей базой (out-of-box experience). Важно, чтобы продуктом было удобно пользоваться новичкам (иначе они пойдут крутить данные с помощью Python notebooks) - Разработчикам все еще надо иногда делать запросы к базам данных напрямую, несмотря на старания создателей ORM:) - Влияние AI/ML на базы данных будет значительным. Скорее всего запросы на естественном языке не заменят SQL для OLTP типов запросов, но вот для OLAP - это может быть делом ближайшего будущего. Внутри корпораций для принятия решений используются данные, но LLMs не так просто будет помочь с этим. Есть проблема с тем, чтобы объяснить их результаты людям, а также с количеством данных, которые требуются для обучения. А эти данные так просто не отправишь для генерации в крауд системы. Отдельно авторы отмечают направление исследований об оптимизации работы самих DBMSs при помощи ML/AI. И даже если в этом результаты будут получены, то они не избавят от потребности в выскокачественной системной инженерии.

В заключении авторы грозятся через 20 лет написать статью продолжение

We caution developers to learn from history. In other words, stand on the shoulders of those who came before and not on their toes. One of us will likely still be alive and out on bail in two decades, and thus fully expects to write a follow-up to this paper in 2044. #Architecture #Software #DistributedSystems