Яка резервна база даних підходить для реалізації IoT

Я повинен надати послугу IoT для свого клієнта. Компоненти MQTT, Kafka та Rest Services будуть використовуватися для передачі даних із пристроїв у базу даних. Мені потрібно зробити деяку аналітику над даними в бекенді. Розмір даних склав би 135 байт / пристрій і 6000 пристрою / секунду. Я поділився архітектурою тут, щоб зрозуміти вимоги та компоненти.

Я досліджував сховища даних (MongoDB, Postgresql (TimescaleDB), Redis, Neo4j, Cassandra), і кожен постачальник довів, що їх база даних підходить для використання в Інтернеті. Я заплутався у використанні перевіреної / найнадійнішої / масштабованої бази даних для IoT.

Що може бути найкращою базою даних для поглинання такої кількості даних та проведення аналітики?

Чи є перевірений орієнтир для відповідної бази даних для IoT?

Будь ласка, дайте свої думки та пропозиції.

Ви обмежені або базами даних NoSQL, тому що будь-яка база даних SQL не дозволяє вам 6K TPS безпосередньо на сервері, і ви не можете використовувати будь-яку хмарну службу SaaS або платформу, яка вже спеціалізується на таких операціях - наприклад, отримувати телематичні дані через MQTT / Kafka, розділіть його та зберігайте для цих 6000 пристроїв та надайте простий REST API для доступу до даних телеметрії. Як флеспі чи щось подібне.

Дані IoT - це майже багато часових рядів. Там є кілька TSDB: InfluxDB, OpenTSDB, GridDB і т. Д. Усі вони мають версію спільноти / oss, щоб ви могли побачити, чи відповідає вона вашим потребам. InfluxDB є популярним, але зауважте, що кластеризація доступна лише для платних версій. OpenTSD є чистою косою, і GridDB констатує, що вона орієнтована на IoT та швидша, ніж InfluxDB. Залежно від ваших потреб, можливо, ви хочете шукати той, який швидко вживається.

Timescaledb, розширення postgres, налаштоване для наборів даних тимчасових журналів, працює дуже добре. І ви отримуєте звичайні функції реляційних баз даних, використання SQL, надійність, індекси, масштабованість.

Питання є широким, точної відповіді не можна дати, але ці посилання можуть допомогти:

http://outlyer.com/blog/top10-open-source-time-series-databases/

Продовження роботи з орієнтирами: http://outlyer.com/blog/time-series-database-benchmarks/

Інше порівняння: https://gist.github.com/sacreman/00a85cf09251147175241d334aafa798

Я встановив деякі правила, щоб спробувати обмежити сферу застосування, інакше цей блог ніколи не закінчиться.

Порівняно лише бази вільних та відкритих джерел тимчасових рядів та їх особливості. Тому хтось запитує: "ви пробували Kdb + та Informix?", Відповідь буде "ні". Вони, мабуть, дивовижні, хоча.

Список буде містити лише бази даних, які або класифікують себе у своєму маркетинговому матеріалі як часові ряди, або про них написано в блозі прохолодною компанією як щось, що вони використовують для даних часових рядів.

Що було зроблено - це читання офіційних документів, читання StackOverflow, перегляд проблем і кодів Github і взагалі взломання інформації разом. Зважаючи на це, деякі факти можуть бути помилковими.

Якщо хтось помітить щось фактично неправильне, будь ласка, дайте мені знати, і я оновлю блог.

Бенчмаркінг ґрунтувався на маркетингових претензіях та оцінці. Чому? Тому що бенчмаркінг - це значна частина роботи та схильна до помилок. Ви завжди отримуєте "ви повинні були налаштувати цю спеціальну бездокументовану настройку". Перераховані номери дуже сприятливі для більшості баз даних. Це або номери, про які блогували, або заявлені у Twitter на певний час у минулому. Якщо ви вважаєте, що будь-які цифри помиляються, повідомте мене, і я оновлю їх.

Окрім попередніх відповідей, рекомендую також переглянути Tarantool , ClickHouse та ScyllaDB . Цих рішень більш ніж достатньо для більшості випадків.

За винятком того, що в деяких ситуаціях, особливо для вбудовування, MDBX (або щось подібне) може бути корисним.