Ответ 1
Я считаю, что буквально все основные базы данных NoSQL будут поддерживать это требование, особенно если на самом деле у вас нет большого объема данных (что вызывает вопрос, почему NoSQL?).
Тем не менее, я должен был недавно разработать и работать с базой данных NoSQL для данных временных рядов, поэтому может дать некоторый вклад в этот проект, который затем может быть экстраполирован для всех остальных.
Наша выбранная база данных была Cassandra, и наш дизайн был следующим:
- Единое пространство клавиш для всех символов
- Каждый символ был новой строкой
- Каждый элемент времени был новым столбцом для соответствующей строки
- Каждое значение (может быть больше одного значения) было частью значения записи времени
Это позволяет вам достичь всего, что вы просили, в первую очередь, для чтения данных для одного символа и при необходимости использовать диапазон (вызовы диапазона столбцов). Хотя вы сказали, что производительность не имеет решающего значения, это было для нас, и это было довольно впечатляюще - все данные для любого одного символа сортируются по определению (сортировка столбцов) и всегда сохраняются на одном и том же node (без перекрестного node связь для простых запросов). Наконец, этот проект хорошо переносится на другие базы данных NoSQL, которые имеют динамические столбцы.
В дополнение к этому, здесь содержится некоторая информация об использовании MongoDB (и закрытых коллекций, если необходимо) для хранилища временных рядов: MongoDB как база данных временных рядов
Наконец, здесь обсуждается SQL vs NoSQL для временных рядов: https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Я могу добавить к обсуждению следующее:
- Кривая обучения для NoSQL будет выше, вы не получите дополнительной гибкости и функциональности бесплатно с точки зрения "мягких затрат". Кто будет оперативно поддерживать эту базу данных?
- Если вы ожидаете, что эта функциональность будет расти в будущем (либо добавьте больше полей для каждой записи времени, либо гораздо большую емкость с точки зрения количества символов или размера временных рядов символов), тогда обязательно перейдите в NoSQL. Преимущества гибкости огромны, а масштабируемость, которую вы получаете (с приведенным выше дизайном) на основе "на символ" и "количество символов", почти неограничена (я говорю, что почти неограниченно - максимальные столбцы на строку составляют миллиарды, максимум строки на одно ключевое пространство неограниченны, я считаю).