Как стать автором
Обновить

Комментарии 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 тебе придется самому писать эти классы. Ну а потом уже можно эти сообщения уже гонять по сети в компактном формате или класть в кеш, или даже сохранять в базу данных.
Я не уверен, что вы поняли о чем речь. Речь о JSON схеме. А она как раз позволяет описывать данные гораздо более точно. Скажем, для Int задавать граничные значения. Ну и конечно существуют библиотеки, чтобы генерить классы из схемы или и json.
НЛО прилетело и опубликовало эту надпись здесь

Тоже столкнулись с проблемой DynamoDB и "горячих" ключей и поставили Редис перед ним, полет нормальный :)

Сдаётся мне, постановка кеша перед Бд является вполне распространённым решением этой проблемы :)

Тут дело в том, что DDB позициноруется как "очено быстрое" KV хранилище, что по факту оказывается немного не так, и если среднее время доступа довольно приемлимо (~20ms у нас), то пики очень раздражают.


Хотя они сейчас придумали DAX, кеш перед DDB, но стоимость у него нехилая

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории