The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Я думаю об этом с 2007 года, примерно с того времени, когда S3 была запущена Amazon. Я даже несколько раз пытался реализовать это, но терпел неудачу сразу после этапа проектирования. Я слышал о стартапе, который тоже пытался сделать это, но также провалился. Я все еще не уверен, возможно ли это сделать, но это определенно могло бы стать бестселлером на рынке управления облачными данными. Подождите, вы можете сказать, а что насчет Google Cloud SQL, AWS RDS, Microsoft Azure, Heroku PostgreSQL и многих других? Они даже близко не подходят к тому, о чем я говорю.
Позвольте мне привести вам аналогию. Предположим, вы хотите сохранить некоторые бинарные данные в облаке. У меня есть два решения для вас. Первое - это хостинговый сервер с FTP. Вы платите мне $5 в месяц, я предоставляю вам доступ к FTP на сервере с диском объемом 100 Гб. Вы можете загружать и загружать свои файлы туда. Работает прекрасно. У меня также есть второй вариант - AWS S3. Вы также можете загружать и загружать свои данные, но через их API. И вы платите за каждый запрос API, каждый байт, размещенный и переданный, вместо ежемесячной платы. Какой бы вы выбрали?
Очевидно, вы выбрали бы S3. Почему? В чем фундаментальная разница между этими двумя? Основное отличие заключается в их SLA: первый с FTP - это сервер, второй - сервис.
Поставщик FTP-сервера гарантирует доступность вычислительных ресурсов (ЦП, диск, пропускная способность и т. д.), в то время как S3 гарантирует доступность данных. Если диск на FTP-сервере выйдет из строя, он будет заменен вовремя, но данные будут потеряны. Если диск наполнится, вы сможете заказать дополнительный сервер, но ваша обязанность не забыть. Если место на диске не используется, вы все равно платите $5 в месяц. И так далее.
AWS S3 была таким прорывом на рынке более десяти лет назад именно из-за этой разницы. Они добавили новый уровень сервиса поверх доброго старого веб-хостинга, к которому мы все привыкли. Идея осталась той же - это все еще данные в облаке, которые мы загружаем и загружаем, но SLA было другим. Нам больше не нужно было беспокоиться о переполнении диска, переплате за неиспользуемое пространство, регулярных резервных копиях, SSH-терминалах и многих других вещах. Они просто дали нам простой API и обещание, что данные там и они в безопасности.
Сейчас 2019 год, и у нас все еще нет такого же решения для реляционных данных. Неважно, какого провайдера вы выберете, все они просто предоставляют вам машину (или кластер) с установленными MySQL или PostgreSQL (или собственной версией) и взимают плату за час работы. Они все еще предлагают “хороший старый FTP” без дополнительного уровня сервиса.
Вот каким я бы ожидал условия SLA для настоящих реляционных данных в облаке:
Плата за данные. Заставьте нас платить за каждый SQL запрос, каждый байт хранения и каждый переданный байт. Сколько серверов и дисков требуется для хостинга всего этого - это не должно беспокоить нас.
Ограниченный SQL. Большинство команд в диалектах MySQL или PostgreSQL не требуются для большинства проектов. Просто дайте нам
INSERT,SELECT,UPDATEиDELETE, и считайте дело сделанным.Индексы. Создавайте их автоматически, используя статистику SQL-запросов, которые мы выполняем.
Версионирование схемы. Обеспечить возможность обновления схемы с помощью чего-то подобного Liquibase: мы создаем новый сценарий
ALTER TABLEилиCREATE TABLE, и он применяется к существующей базе данных.Снимки и откаты. Позволяют создавать снимок данных, применять новую версию схемы, а затем откатываться к одному из ранее созданных снимков, если что-то идет не так.
На самом деле, настолько трудно это внедрить?
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:06
