The new company’s first product will be a cloud version of M3 to help reduce some of the complexity associated with managing an M3 project. “M3 itself is a fairly complex piece of technology to run. It is solving a fairly complex problem at large scale, and running it actually requires a decent amount of investment to run at large scale, so the first thing we’re doing is taking care of that management,” Mao said.

а, увидел

они будут пилить СааС на основе их базы данных - звучит разумно (только она памяти много жрет)

Да, я так и понял из тогл что выше скинули

уже можно - см. https://medium.com/@valyala/speeding-up-backups-for-big-time-series-databases-533c1a927883

Еще вариант для long-term storage без бэкапов - persistent replicated durable disks вроде gcp disks - см. https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565 . Под капотом они используют те же технологии, что и GCS с S3.

Добавить больше локального места, когда его станет мало. Вон gcp диски можно расширять до 64ТБ без остановки VM - https://cloud.google.com/compute/docs/disks/add-persistent-disk#resize_pd . Стоят они всего лишь в 2 раза дороже, чем s3 ($40/TB вместо $20/TB), зато предлагают взамен лучшую и консистентую производительность, интеграцию с os page cache (чтобы недавние данные читать напрямую из RAM) и отсутсвие сетевых ошибок при работе со стореджем.

в вм эта оптимизация была с самого начала - см. https://github.com/VictoriaMetrics/VictoriaMetrics/blob/3e6786267678067d4a8e651256c8d6690801f4ff/lib/storage/tag_filters.go#L421

классно потроллил Брайана :)

это в какой момент?)

Это же, вроде, все равно сетевые диски. Потому сетевые ошибки все равно могут быть, просто они скрыты от пользователя за залипанием io и ошибками ввода-вывода. И, если худо-бедно, но от сети адекватные разработчики уже не ждут 100% надежности и делают обработку ошибок и таймауты, то вот проблемы с блочными устройствами заставляют софт поголовно падать лапками к верху.

давайте про надёжность и ненадёжность дисков в клауде куда-нибудь в другой чят, если нет метрик для обсуждения

самый надежный способ - сделать запрос к /api/v1/series/count. Он вернет суммарное количество метрик за все время. count(name) не учитывает метрики, по которым уже перестали приходить данные на выбранном интервале. Например, в базе может быть сто миллионов метрик, но за последние сутки данные пришли только по миллиону метрик, т.к. остальные 99 миллионов прекратили свое существование из-за churn rate. Например, задеплоили новый релиз в кубер - и автоматически создались новые метрики, а по старым перестали приходить данные.

@Andorka в контексте работы стораджа метрик, надеюсь, можно?

@valyala не, ну, если, конечно, вы в виктории проверяете успешность любого ввода-вывода и регулярно тестируете ее работу на dm-flakey, dm-delay и dm-error, то респект и уважуха. Но большинство, просто, таким не заморачивается, считая блочный сторадж априори надежным.

в твоём сообщении вообще ничего про этот контекст не было

кто кого

lightning talk'ом про ВМ :)

Мне просто казалось, что он был изначально, когда я влез в разговор.

там ответочка тут же прилетела. жопная

А ну норм;)