Комментарии 2
Сердцем любого backend являются данные. Существует два сценария использования данных. В одном из них данные изменяются редко, но при этом активно используются в сыром или агрегированном виде и применяются для целей аналитики в реальном времени (такие системы принято называть OLAP). В других системах важно обеспечить сохранение с высокой скоростью большого количество неструктурированных или полуструктурированных объектов, поступающих от устройств Интернета вещей, из источников произвольных событий, наблюдений за активностью пользователя (такие системы называются OLTP - Online Transaction Processing, ориентированные на большое количество транзакций с минимальной задержкой обработки). Для таких систем важно обеспечить надежность хранения данных, поддержку распределенного хранения на нескольких серверах и/или дата-центрах и сохранение консистентности распределенного хранилища.
Какое мощное спорное обобщающее введение.
Это всё хорошо, до тех пор пока не захочешь читать из кассандры агрегаты по датчиками (а именно они и нужны бизнесу). Там и выяснится, что пишется в нее быстро, а читается быстро только точечно.
Мульти дц и в постгре решается через реплики (можно еще в TimescaleDB попробовать) и по объёмам очень большие ограничения. Можно еще пошардировать датчики на несколько кластеров пг.
Ну и не забываем про кликхаус, который из коробки это все (горизонтальное масштабирование) умеет и читает гораздо быстрее.
Система сбора распределенной телеметрии на Cassandra и Kotlin Spring