Дизайн схемы InfluxDB (длинный и тонкий против короткого и толстого?
Я планирую схему для базы данных. Работает ли InfluxDB лучше с «короткими и толстыми» или «длинными и тонкими».
Я предпочитаю длинные и тонкие, так как их легче масштабировать и они, по всей видимости, более стабильны?
Кто-нибудь может предложить здесь больше информации?
Спасибо
Отредактируйте, чтобы показать Юрию данные:
Предлагаемый дизайн схемы:
Этот дизайн хорошо масштабируется - он обрабатывает статические данные, то есть интервал 0, интервальные данные и другие будущие источники, которые я буду добавлять. Я не уверен в том, должен ли я стремиться уместить все в единую базу данных и если может быть лучше разбить данные на несколько баз данных?
Однако это немного контрастирует с подобными проектами (источник: https://medium.com/coinograph/storing-and-processing-billions-of-cryptocurrency-market-data-using-influxdb-f9f670b50bbd)
Спасибо, Юрий!
Ответы 1
Перво-наперво: в Influx есть такая вещь, как «схема», как вы, возможно, знаете из мира РСУБД.
потому что это не какая-либо база данных SQL - по сути, это ключ-значение с определенным ключом на определенный момент времени и сложным значением, состоящим из комбинации индексированных пар kv с низкой мощностью и фактических серий именованных значений с высокой мощностью .
Следовательно, он масштабируется и настраивается иначе, чем способы, которым вы научились в РСУБД.
И сама «схема» там довольно подвижна, она не жесткая.
Итак, я предлагаю вам полагаться исключительно на свои потребности: как ваши данные (или должны быть) сформированы и что вы предполагаете с ними делать.
Если вы дадите мне образец этого - я, вероятно, смогу дать вам пример того, как лучше всего справиться с этим в Influx.
Продолжая ... Я думаю, что проблема с этим дизайном в том, что он хорош в том смысле, что он может масштабироваться до нескольких наборов данных. Я теряю часть функциональности с функциями в Influxdb. например если я хочу масштабировать данные минутного интервала до ежедневных данных, с этим текущим дизайном будет сложнее.