Comments 17
Такой жестокий vendor lock, что даже страшно думать о том, что будет, если они все-таки решат с амазона слезть (например из-за его цены :)).
"Мы используем Protocol Buffers для схем данных (и правил изменения схем) чтобы держать все слои распределённой системы синхронизированными, включая мобильные приложения, веб-сервисы и хранилище данных. Мы аннотируем схемы деталями конфигурации, такими как имена талиц и индексов, правилами валидации записей, такими как максимальная длина строк или допустимые диапазоны значений чисел."
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
Видимо описывают в proto-файлах схему и связи, да. А потом валидируют данные с их помощью.
Хм, может я что-то пропускаю, но насколько я понимаю, протобуф — это способ серилизации данных. Как на нем можно описывать связи, индексы?
Автор в оригинальном посте не раскрывает этот вопрос, но Protocol Buffers — это ещё и формат (язык) описания данных. Кроме этого, насколько мне помнится protoc, средствами которого описание транслируется в реализацию на конкретном языке, поддерживает плагины, так что можно предположить, что в том числе за их счёт это и реализовано. Впрочем, это только предположения.
Ну так этот язык ведь заточен под конкретную цель — эффективно упаковывать-распаковывать данные.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
Так то оно так, но там еще есть описательная часть. Так что в принципе, можно описывать данные на protobuf, но не для серилизации, а для валидации. Вот, например, либа для nodejs, которая ничего не серилизует и не упаковывает, а просто валидирует схемы: https://www.npmjs.com/package/protobuf-validator
А JSON схема чем плоха? Но дело даже не в этом. Я не понимаю мотивации в описании схемы БД в терминах протобуф IDL. Может есть какой-то годный фреймворк, позволющий удобно все эти описания переводить в DDL?
Да кто его знает зачем они так делают)) Мы в одном проекте тоже активно используем схему protobuf для валидации данных из API, но лишь потому что мы им же и пакуем для передачи следующему компоненту системы. Своеобразное http api -> protobuf api. Зачем это делает Medium не знаю.
Protobuf немного более гибкий чем Json. Например в нем есть разные типы данных чисел. (int, float, int32). Можешь задать тип сообщения, то есть все сообщения будут соответствовать определенному формату.
Плюс, ты описываешь какие-то данные и protobuf сгенерит набор классов для конкретного языка для работы с этими данными. В Json тебе придется самому писать эти классы. Ну а потом уже можно эти сообщения уже гонять по сети в компактном формате или класть в кеш, или даже сохранять в базу данных.
Плюс, ты описываешь какие-то данные и protobuf сгенерит набор классов для конкретного языка для работы с этими данными. В Json тебе придется самому писать эти классы. Ну а потом уже можно эти сообщения уже гонять по сети в компактном формате или класть в кеш, или даже сохранять в базу данных.
UFO just landed and posted this here
Тоже столкнулись с проблемой DynamoDB и "горячих" ключей и поставили Редис перед ним, полет нормальный :)
Sign up to leave a comment.
Стек, который позволил Medium обеспечить чтение на 2.6 тысячелетия