1.1, Аноним (1), 10:51, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– |
Если бы как вариант движка для MySQL запилили - можно было бы щупать.
А так - ну, есть...
| |
|
2.2, 1 (??), 10:52, 24/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нда ...
Заплати и сделают ... Хоть к sqlite
| |
2.11, Аноним (11), 12:02, 24/12/2020 [^] [^^] [^^^] [ответить]
| +6 +/– |
> MySQL
> Time Series
Так TimeSeries это про производительность, где очень много записей на единицу времени.
Вы бы ещё спойлер для осла попросили бы - за деньги Вам сделают, но зачем, если для каждой задачи свой инструмент и нужно корректно подбирать решение под проблему.
| |
|
3.12, mos87 (ok), 12:26, 24/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
товарищ не довёл до логического гм конца - нужно не для MySQL, а на SQL Server Бызнес фор Энтерпрайзыс Идишн Экзекьютив Инсайтс фор БигДата
только тогда труЪ
| |
|
|
1.3, Omnonm (?), 10:55, 24/12/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Встречал только однажды как бд под немаленький заббикс, на замену штатному постгресу когда перевалило за полтерабайта.
Где ещё оно имеет плюсы в использовании?
| |
|
2.10, Аноним (11), 11:58, 24/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Где ещё оно имеет плюсы в использовании?
Так любой кейс, где нужны TimeSeries - данные с датчиков (очень много предметных областей), метрики (same).
| |
2.13, Виталий (??), 12:41, 24/12/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Любые данные где есть время и сами данные не должны меняться.
аудит ( когда кто что сделал)
финансовые операции (когда кто что кому перевел)
IOT (когда какой датчик что показал)
Везде где таких данных ожидается много timescaledb сильно улучшает работу PostgeSQL и облегчает DBA работу.
На небольших объемах (10 000 000 000) - очень удобно, даже на одном узле справляется,
если нужно больше - то есть кластеризация (но ее сам не пробовал, она раньше платной была,
да и у меня кейс простой, весь трафик муниципального транспорта одного региона хранить 3 месяца).
| |
2.15, valyala (?), 13:14, 24/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Главный плюс TimescaleDB - она работает поверх Postgresql. Это значит, что пользователю доступны все плюшки postgresql при работе с TimescaleDB. Дальше идут одни минусы:
- жрет disk IO быстро гробит SSD диски
- тормозит на HDD
- плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB
- тормозит на больших объемах данных
Поэтому лучше использовать VictoriaMetrics. https://valyala.medium.com/promscale-vs-victoriametrics-resource-usage-on-prod
| |
|
3.16, PetrG (ok), 14:05, 24/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
Впечатляет, но эти тесты показывают как оно работает из коробки под ваши задачи (например ACID и запросы вас не интересуют похоже).
Я бы у Promscale поспрашивал что они по этому поводу думают - мне кажется что это можно настроить. Скорее всего всё равно медленнее будет (потому что TS сжимает с задержкой) но не настолько.
| |
3.17, Виталий (??), 14:06, 24/12/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
> жрет disk IO быстро гробит SSD диски
Откуда такая информация?!
>- тормозит на HDD
Вообще-то оно ускоряет вставку в тот же postgresql
(т.е если вы пишете в postgresql без timescaledb и с timescaledb - у вас результаты будут лучше с timescaledb)
>- плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB
Опять странная информация, откуда она?
На голом postgesql у меня набор данных занимал 307GB, после сжатия стало 41GB - это очень "не плохо".
> тормозит на больших объемах данных
Он предназначен для работы в PostgreSQL - на объемах для postgresql - вообще не тормозит, на оборот, ускоряет работу PostgreSQL.
>Поэтому лучше использовать VictoriaMetrics
Чем лучше? Как там у VictoriaMetrics c Geospacial данными или хотя бы транзакциями?
PS Нету лучшей и худшей БД, нужно всегда смотреть что лучше подходит под конкретную задачу.
| |
|
4.22, valyala (?), 16:54, 24/12/2020 [^] [^^] [^^^] [ответить] | –3 +/– | Из статьи, на которую приведена ссылка в предыдущем комментарии TimescaleDB поз... большой текст свёрнут, показать | |
|
5.25, Аноним (11), 10:00, 25/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Поэтому лучше использовать VictoriaMetrics
Насчёт плюсов и минусов Вы правы (ну, почти).
Только насчёт "лучше использовать мою разработку" - спорное утверждение. TimesclaeDB для малых и средних компаний обойдётся дешевле в поддержке (человекочасы как минимум) и развёртывании, аиспользовать VictoriaMetrics - оверинжиниринг, развёртывание ради развёртывания (или закладывание на годы/десятилетия, на случай роста). Не у всех есть DBA, но у всех есть бэкендер и фронтендер или хотя бы один фуллстек, а учить и прикручивать интеграции фуллстеку - ну такое, у заказчика всегда есть задачи посрочнее, чем трата времени на ещё одну технологию, у которой своя экасистема и свои потребности в изучении, развёртывании и обслуживании, бизнесу далеко не всегда такое объяснишь с первого раза.
А если у компании есть объёмы больше терабайта, то да - Ваш продукт именно в этом сценарии лучше. То есть у компании при таких объёмах и доступных ресурсов должно быть больше (а не полтора разраба, как это часто бывает).
> быстро выполнять запросы по недавно вставленным данным для всяких алертов
В приведённых Вами статьях не использовались Continuous Aggregates, что показывает, что вы даже не разбирвались в тестируемом продукте, ибо это упоминается на главной же (даже не документации) странице TimescleDB. То есть Вы сделали тест ради тестов, зная как пользоваться только своей разработкой, не удосужившись даже открыть документацию конкурента. Любой, кто хотя бы это сделает (в отличие от Вас) поймёт, что тесты сделаны чисто в маркетинговых целях. При этом Вы называете себя Core Developer, а не PR-менеджером.
| |
|
6.29, RNZ (ok), 21:25, 25/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
"Что-ты несёшь???"
Континиус агрегаты - это как раз костыль что-бы компенсировать низкую производительность и в рантайме выполнять приращения. И чисто технически ничего не мешает разработчику victoriametrics запилить такую же функциональность в каком-нибудь из релизов на манер как это сделано для snapshot'ов
http://<victoriametrics-addr>:8428/aggregate/create
и в data правила агрегации.
| |
|
7.32, Аноним (11), 10:55, 28/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
Так раз ты PR-щик VictoriaMetrics, скажи менеджерам, чтобы разрабы реализовали. А пока, не надо фичу, которой нет у твоего продукта, называть костылём.
Или любые View и Materialized View, хранимые функции и процедуры - костыли?
Если так, иди и скажи это миру РСУБД.
| |
|
8.35, RNZ (ok), 18:41, 28/12/2020 [^] [^^] [^^^] [ответить] | +/– | Никакого отношения к victoriametrics не имею Так что мимо И как не называй, ко... текст свёрнут, показать | |
|
|
|
5.28, Yilativs (?), 20:30, 25/12/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>> жрет disk IO быстро гробит SSD диски
>> Откуда такая информация?!
>Из статьи, на которую приведена ссылка в предыдущем комментарии.
Там нет никакой информации о том, как был настроен postgresql -
Вы верите статье на статьям производителя о конкурентах?
А сами не пробовали тест воспроизвести?
Может они как timescaledb - еще и тесты в github выкладывают, что бы можно было на своем железе потестить?
>Geo-spatial функции пока планируются.
Тогда в огромном классе задач связаных с IoT и позиционированием они бесполезны.
>Транзакции для типичных задач, решаемых с помощью time series БД, не нужны
Учет финансовых операций - типичная задача для time series баз данных и они часто ходят парой, т.е с одного счета списали, на другой записали.
Расскажите, как это сделать бес транзакций?
>Типичные требования под задачи для TSDB:
> записывать постоянный поток данных со скоростями в миллионы строк в секунду
Сотни или миллиарды уже не TS?
Опеределение TS - вообще не связано с объемом.
> быстро выполнять запросы по определенным рядам на определенных интервалах времени для построения всяких дашбордов в Grafana
TS вообще ничего не знают про Grafana- картинки, это частный случай.
TS базы данных - это базы, которые сохраняют данные в которых присутствует время, при этом данные не меняются после записи(append only) и добавляются в конец (recent).
Классы задач под это:
Аудит, мониторинг, финансовые транзакции, geo tracking
Меньше верьте рекламным статьям, Сэр )
| |
|
6.30, RNZ (ok), 21:34, 25/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
>>Geo-spatial функции пока планируются.
>Тогда в огромном классе задач связаных с IoT и позиционированием они бесполезны.
Да ладно? Посчитать на apps религия не позволяет? И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis.
| |
|
7.31, Аноним (11), 10:53, 28/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
> И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis.
Вот ведь открытие! Так об этом и речь, что обычными SQL-запросами можно и TimeSeries, и GeoSpatial сохранять/обрабатывать/считывать. И никакого DSL не нужно, никаких сторонних библиотек, никакого допиливания драйвров/коннекторов.
То есть Вы даже не спрашиваете, в каких случая и и как будет применяться инструмент, а просто набрасываетесь на аргументы? Просто потому что VictoraMetrics не умеет?
Что, у VictoriaMetrics настолько плохо с маркетингом?
| |
|
8.36, RNZ (ok), 18:49, 28/12/2020 [^] [^^] [^^^] [ответить] | +/– | У кого-то воображение разыгралось Я не набрасывался на аргументы, а возразил на... текст свёрнут, показать | |
|
7.33, Аноним (11), 10:59, 28/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
1. Вы когда-нибудь бэкенд-разработкой занимались?
2. Вы когда-нибудь высоконагруженный сервис поддерживали?
Если ответ на оба вопроса - да, то расскажите, пожалуйста, в каких случаях расчёты TimeSeries и GeoSpatial происходят "на apps"? А то мы, бедненькие бэкендеры, оказывается, не знаем как правильно, следим за потреблением памяти приложения, чтобы оно за гигабайты не сильно выходило, а вон оно как - надо базугнать в приложение и уже там ворочать данными, SQL не нужен, GeoSpatial не нужен, материалиованные представления не нужны, всё надо в памяти при каждом запросе считать.
| |
|
8.37, RNZ (ok), 19:37, 28/12/2020 [^] [^^] [^^^] [ответить] | +/– | Да 80G-100G в сутки с realtime детектированием пересечения геолокаций и 180млн ... текст свёрнут, показать | |
|
9.38, Аноним (11), 09:26, 29/12/2020 [^] [^^] [^^^] [ответить] | +/– | Вы не ответили на вопрос - в каких случаях 1 При запросах 2000 в секунду - как... текст свёрнут, показать | |
|
10.40, RNZ (ok), 16:41, 29/12/2020 [^] [^^] [^^^] [ответить] | +/– | А я не стремился приводить все случаи, одного примера достаточно При минимуме и... текст свёрнут, показать | |
|
9.39, Аноним (11), 09:30, 29/12/2020 [^] [^^] [^^^] [ответить] | +/– | А, тогда выступите с докладом на Highload , там Вы хоть от вопросов не увернёте... текст свёрнут, показать | |
|
10.41, RNZ (ok), 16:45, 29/12/2020 [^] [^^] [^^^] [ответить] | +/– | Ну во первых выступление мне не нужно нет такой потребности , во вторых утвержд... текст свёрнут, показать | |
|
|
|
|
6.34, Аноним (11), 11:06, 28/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Меньше верьте рекламным статьям, Сэр )
Так он их и пишет, вот и продвигает свой продукт - он PR-менеджер.
А судя по его аргументам, использовать оба продукта под реальной нагрузкой на проде никогда не пробовал.
| |
|
|
|
|
|
|
2.9, Аноним (11), 11:56, 24/12/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Чем оно лучше rrdtool?
Тем, что не нужно учить очередной DSL.
Плюс нет нужды в написании или поиске отдельного драйвера для своего ЯП - любую нормальную ORM можно использовать для запросов к Time-series данным, что позволяет вообще писать на своём бекенд языке (речь не о JavaScript).
Другие преимущества в этой новости перечислены, читайте внимательнее)
| |
2.24, Аноним (24), 08:40, 25/12/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Один из явных минусов rrdtool это GPLv2. И не надо ляля про локалхост-поделки.
| |
|
|
2.21, Аноним (11), 15:34, 24/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не в каждой компании есть время и ресурсы, чтобы учить дополнительные DSL и развёртывать дополнительные сервисы с накручиванием дополниьтельной интеграции.
TimescaleDB хорош как раз для случаев малых и средних компаний - не нужно искать/писать дополнительный драйвер (все полноценные ORM дружат с TimeScaleDB), не надо тратить время на изучение как с этим общаться, как развёртывать и как поддерживать ещё один сервис докучи - тот же Postgres, только немного по-другому обрабатывающий определённую табличку. Ничего от него не ломается, все джоины и прочие запросы могут выполняться между time-series и обычными данными.
А так, для крупных предприятий с многомиллионными бюджетами на человекочасы, лицензии и железо - да, InfluxDB и ClickHouse.
| |
2.27, йо (?), 18:40, 25/12/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Clickhouse не конкурент, не самое лучшее решение для timeseries (хотя идеальное для эвентов и логов). Influx конкурент, да, но, во-первых, не open source, поэтому оффтопик на этом сайте, во-вторых жрет памяти в 10 раз больше, и диска в 2 раза больше, в третьих -- язык запросов не PromQL с расширениями, как у Victoria metrics.
| |
|
|