В настоящее время я создаю приложение API, которое должно отслеживать статистику в реальном времени. Это включает в себя статистику для самого API, например, счетчики запросов, а также статистику, связанную с вариантами использования, такую как история элементов и отслеживание позиции. В основном, данные статистики состоят из целых чисел, которые очень быстро подсчитываются вверх и вниз. Иногда около 10-50 тысяч раз в секунду. Основная база данных - Aerospike. Я использую в пространстве имен памяти для поддержания счетчиков. Они модифицируются в реальном времени asyn c с запросами API. Это отлично работает прямо сейчас. Но мне нужно иметь историю изменений, которые вносят эти счетчики. Как снимок всех счетчиков каждые 5 минут для рисования графиков. Эти графики должны быть почти в реальном времени для клиента. Максимально возможная задержка составит около 10 минут. Моя первая попытка состояла в том, чтобы выполнить задачу над пространством имен и просто запросить все записи, объединить их в архивные записи и снова сохранить их в Aerospike. Здесь я столкнулся с проблемой, что, прежде всего, запрос всех этих записей разрушит память любого компьютера и займет слишком много времени. Поэтому теперь я пытаюсь также поддерживать архивные записи в реальном времени asyn c в запросах API. Делать это в Aerospike - слишком высокая нагрузка, в дополнение к гигантской c нагрузке для повторного запроса историй для рисования графиков и т. Д. c. Процесс архивации не заставляет придерживаться API. Это также может быть автономное приложение, которое взаимодействует с самой базой данных.
Я погуглил и обнаружил, что, вероятно, база данных временного ряда подойдет лучше всего. Но существует довольно большое количество таких баз данных, и я довольно новичок во временных рядах, поэтому я хотел бы спросить несколько советов относительно системы баз данных здесь. У кого-нибудь есть опыт решения подобных задач? Прямо сейчас, я думаю, что графит был бы возможным кандидатом, но я не уверен относительно его коэффициента масштабирования. Как я понял, у него там довольно много проблем. Мне нужно отслеживать историю временных рядов около 500 миллиардов записей в базе данных. Вероятно, на счетчиках в реальном времени это будет примерно от 200 до 500 тысяч записей в секунду. Что касается емкости хранилища, то, вероятно, это будет около 20–200 ТБ необработанных производственных данных.
У меня нет никаких требований относительно того, как взаимодействовать с базой данных архивирования. Я предпочитаю Node, Go или Java в качестве языка на стороне клиента, но я там гибок. Единственный фактор, который важен для меня, - это масштабирование и производительность базы данных.
Также, если у вас есть какие-либо сомнения по поводу моего вышеупомянутого процесса проектирования, я хотел бы знать о них. Это первый раз, когда мне приходится собирать статистику в таком размере, так что, возможно, есть лучшие способы решить эту проблему.
Заранее благодарим за любые советы или мнения по этому поводу.