Исходное сообщение
"Выпуск СУБД TimescaleDB 2.0" Отправлено Аноним, 25-Дек-20 10:00
> Поэтому лучше использовать VictoriaMetrics Насчёт плюсов и минусов Вы правы (ну, почти). Только насчёт "лучше использовать мою разработку" - спорное утверждение. TimesclaeDB для малых и средних компаний обойдётся дешевле в поддержке (человекочасы как минимум) и развёртывании, аиспользовать VictoriaMetrics - оверинжиниринг, развёртывание ради развёртывания (или закладывание на годы/десятилетия, на случай роста). Не у всех есть DBA, но у всех есть бэкендер и фронтендер или хотя бы один фуллстек, а учить и прикручивать интеграции фуллстеку - ну такое, у заказчика всегда есть задачи посрочнее, чем трата времени на ещё одну технологию, у которой своя экасистема и свои потребности в изучении, развёртывании и обслуживании, бизнесу далеко не всегда такое объяснишь с первого раза. А если у компании есть объёмы больше терабайта, то да - Ваш продукт именно в этом сценарии лучше. То есть у компании при таких объёмах и доступных ресурсов должно быть больше (а не полтора разраба, как это часто бывает). > быстро выполнять запросы по недавно вставленным данным для всяких алертов В приведённых Вами статьях не использовались Continuous Aggregates, что показывает, что вы даже не разбирвались в тестируемом продукте, ибо это упоминается на главной же (даже не документации) странице TimescleDB. То есть Вы сделали тест ради тестов, зная как пользоваться только своей разработкой, не удосужившись даже открыть документацию конкурента. Любой, кто хотя бы это сделает (в отличие от Вас) поймёт, что тесты сделаны чисто в маркетинговых целях. При этом Вы называете себя Core Developer, а не PR-менеджером.